 Hi everyone. Welcome to this session on building custom web applications with the DHS2 app platform. Looks like maybe most of you were here for the last session where we talked a lot about the DHS2 innovation ecosystem and how we're enabling that in a number of different ways. This session will be a little bit more technical about how we're enabling that innovation on the web app front for DHS2 applications that are built into the core for our own University of Oslo core team to use that application platform as well as for third-party developers who are building customizations to DHS2 using that same platform. So we'll talk a little bit more about that, about where we've come in the last year of development of that application platform. Some of this may be review if you've been to sessions that I've done in the past about the app platform, but some of it may be new as well. So please bear with me if you've heard some of it before. Okay, so first I'm just going to introduce the the app platform for about 45 minutes, then I'll open it up to questions. So hopefully if you have any questions, please post them at the community of practice. There is a or there should be a topic for building custom web apps with the DHS2 app platform. I believe Simona will post that in the chat here on zoom as well. If you post your questions there, we'll take a look at them in the last 15 minutes of this session to answer them live here as well. So feel free to ask any questions that you have along the way there. Just want to reiterate posted this in the last session as well but we have a great resource for all of your application development needs developers at DHS2.org. We have a lot of announcements from the core team upcoming events such as the Academy that we hosted in June and August of this of 2020 and hopefully we'll have another one at the beginning of 2021. As well as documentation guides learning materials you can view the recordings and the slides from all of the sessions and the academies that have happened in the past as well. So there's a lot of good material there. And finally, there is a link from developers at DHS2.org to a category on the community of practice specifically for application development. So if you have any questions for myself or the core team on how to do something or a feature request for the application platform. If you're a use case for something that you're trying to develop on the DHS2 platform, please post your questions there and we take a look at that pretty regularly. So where are we now. This is kind of the history of the DHS2 application platform over the last year, and a little bit about where we're going. I didn't get into all of the features that we've added to the application platform since it was first released. It was covered in this in this later in this presentation, but this is more about what we've what we've accomplished and where the where the project as a whole has has has gone over the last year. So I first introduced the application platform at the conference annual conference last year in 2019. And that at that time it was, it was in development, but it was not fully released yet in August of 2019 released version one of that application platform and shortly thereafter reported the first core application to use the platform in the 233 release in October of We then ported four more applications to the platform in 234 release earlier in 2020 and then we're able to host a number of webinars with all the learnings that we had accumulated and the features that we had developed in the platform. Through porting those application or our own applications the core applications to that platform, we're able to host a two webinars and two online workshops for external developers in June to August of 2020. And more than 120 people were at each of the webinars that were hosted in June and there were about 30 participants for the, the two day and the four day workshops that were made up the developer Academy over June and August as well. In the upcoming release in just a couple weeks of DHS to 235. We have five more core applications that have been ported to the platform, including several of the large ones like the dashboards application is now on the platform as well so this is a big accomplishment for us and it's been kind of a pleasant surprise for the core developers to see the ease with which those applications can be ported and that they can really increase the velocity and the maintainability of those applications and there's still a lot to improve and a lot of long ways to go there, but that's been a been a great learning I think so far, and we're hoping to get a total of 15 to 20 of the core apps ported to the app platform in the 236 release. We also now have the ability to do continuous application delivery which means that some of our applications can bundled applications that are in the war file of DHS to 235 can be overwritten or overloaded with a new version installed from the DHS to app hub on apps that DHS to .org so we can actually release some of these applications more quickly, but that being said we're still bundling the core applications with the DHS to core so in the 236 core bundle, we hope to have a number more core applications ported over and some of the ones that we've already ported migrated to the most recent version of that platform as well. And then in the first half of 2021 we're also hoping to have nothing specific planned yet but an Android SDK and web app developer academies maybe combining those together but definitely some more learning opportunities either online or in person depending on how things go probably online at this point for the first half of 2021. So if that's something that you're interested in please feel free to reach out and just let us know that you're interested so that we know that there's people out there who want to come to these academies or workshops. So now I'm going to talk a little bit about what a DHS to app entails. I mentioned this in the last session so I'm not going to go over it too much here today but there are various layers of complexity or not necessarily complexity of generality of DHS to so at the core you have the most general and robust section of DHS to which is the the server the DHS to core which has an API has the metadata model as all of the resources for DHS to to function as a data store and around that we have the bundled applications that the University of Oslo develops. Beyond that you have more locally adapted custom applications that are developed by developers not at the University of Oslo they might be used in only one instance or shared through the app hub with other DHS to implementations to to basically adapt DHS to for a particular use case or particular context. And then beyond that you also have the inter operation with different services and softwares. So other other tools for analyzing data or other health information systems can be inter interoperable with DHS to again today we're going to talk about applications specifically web applications and focus on both bundled apps so the applications that University of Oslo develops and maintains as well as what we call periphery apps or third party applications that are developed by probably many people on this call but developers that are not at the at the University of Oslo on the core team and applications that are not bundled in the war file that is deployed or released every six months by DHS to again this is the same diagram from the last presentation but wanted to emphasize that we use the same platform for our bundled applications that we expose to other other other developers to build their applications on so this is relatively new in the DHS to world with this introduction of this platform is that everything that is available to the core web applications bundled web applications should also be accessible to third party apps. We still have a long ways to go to get there but that's that's kind of the goal of this project. So here is a picture of a single DHS to application in this case it's the data visualizer app it's actually an older screenshot of the data visualizer application. But there's a lot of a lot of pieces a lot of things going on here. And this is just an example of what what I mean when I say DHS to web app so you have the application selector in the top right when you open your DHS to instance, there are each of those are one of these applications or web apps. We just looked at the data visualizer application there's also the pivot tables or the maps of the dashboard application, which are all analytics apps. You also have capture tracker capture data entry which are applications for collecting data and injecting it into the system, as well as some maintenance or core applications like the maintenance app, the schedule application system settings application things like that. So there's a lot of different apps that are in DHS to many, most of the ones that you see here, so all the ones that you see here are core bundled applications but there are also third party applications that are installed to DHS to So what's inside each one of those applications. There's a lot that's going on in each one of those I'm going to go through it very quickly but for each and every application we need to include the header bar which has the name of the application the name of the instance the logo of the instance, the ability to switch to other applications, the ability to log in and log out and see and navigate to your profile and see the number of messages that the currently logged in user has seen. We also need the ability to do error handling and to navigate through saved objects with a file menu for instance to ability to show dialogues for different user interface or user user user experience user experiences for instance if you say file open it should open a dialogue box. It shows you the available objects that you can open. In addition we have a number of things within the app itself that need to are fairly common so oftentimes you'll have routing within an application to be able to navigate through the URL to a specific page in that app or to navigate to a particular saved object for instance the ability to show alerts when something goes wrong or when when something has happened, the ability to translate all of the English text or all of the text in your application to Swahili or French or Arabic or any other language that DHS to supports the ability to show loading and error indicators when something goes wrong in a particular part of your application or when something is in the process of being loaded because sometimes that can take some time when you're on a slower network connection for instance. And then there's a number of other common UI components that are very basic things like buttons and text boxes that need to be have the follow the look and feel of the DHS to design system which we'll get into in a little bit, but you need to address that for each of those individual small components in each application that are developed. Additionally, there are a few things that are specific to the application that you're developing in this particular instance so if we're talking about the data visualizer application the ability to render a chart from a or select a set of dimensions for a visualization is specific to the data visualizer and needs to be done there in that app as well. You have the interface for selecting different dimensions and dragging and dropping them to rows or columns for a pivot table to be able to manage the state of the application so that you know whether you've edited something and need to click the update button in your data visualizer application or your pivot table application. For instance, that's going to be specific for to each individual app and what its target is what it's what its intent is, but it needs to be it needs to be implemented in that application. And then under the hood there are a number of things that these apps need to do as well they need to fetch read and write data they need to get metadata schemas from the particular instance that they're talking to they needed to figure out where that server lives, you need to do some data caching and offline supports that they're not fetching data every single time that it's requested. They need to be able to authenticate a user and show and hide different parts of the the application if they don't if that user doesn't have the information to see them also needs to look through all of the source code of your application to find all of the English strings so that they can be translated needs to generate a manifest needs to be able to run some tests and compile against a set of browsers that are supported by the DHS to system. And finally it needs to be able to build publish and release the application to the DHS to app hub, or to install it directly to a DHS to instance. And I've said all of this before in previous sessions but the the gist is that there's a lot going on. And a lot of it is very common to all of the different applications that are in DHS to get very complicated. I sent this said this in the last session but it gets very complicated when you have lots of different applications so we maintain 34 applications, six libraries, four versions of those of those applications three of those are supported released versions and one of those is the version that we're developing next. So that's about 160 different code bases that we need to maintain as the University of Oslo to make DHS to function. So why do we build a framework. This is basically it's to address this problem. But on a more general level it's to make easy things easy and hard things possible. That's a quote, not a direct quote but the quote on the screen is easy things should be easy hard things should be possible. I'm going to quote it from Larry wall the creator of the programming language pearl. And basically what we want to do is we want to make it as easy and as cost efficient and developer efficient as possible to build high quality and maintainable applications on DHS to. So a lot of those details that we talk about in the DHS to in a DHS to application that that you need to think about or handle when you're when you're building building that up from scratch. So for instance, here are five different applications and just looking at the title bar in the browser. There's a lot of differences here. That's because each of these applications was developed from scratch and each one had a different way to define what the name of that application was in the title bar, what the icon was for that application as well. So you can see that these are all different. And it gets you even more complex and confusing when you have lots of different applications so some of these are third party applications most of these are are bundled core apps. But something as small as the title and the, the icon for these individual apps shouldn't shouldn't be something that a developer needs to worry about to make a quality DHS to application should be done out of the box for them. And that's what the framework is for is to get rid of as many of those details as possible so that you can focus on what you actually care about which is making the application do what you want to do. And you might say that the title the way the title is formatted or the the icon that is used shouldn't matter to it's small enough that it doesn't matter but it but it does matter and the reason it matters is that quality and consistency is important. It makes a user more comfortable and familiar with the software that they're using and it also allows it also could be something that's small like the format of the text here, but it has a more serious impact for instance it might be text that isn't translated to a different language. And that's something that would have real impact on users of that system. So even though a detail is small it doesn't mean it's not important. These are again just a few more examples of different applications and how different they can be so if you take a look at just the header bar for each of these applications you'll see that they're each very different and this is still the case. These were screenshots were taken before the application platform was starting to be implemented in a lot of these apps, but it's still the case in several apps in DHS to and this is what we're trying to address by moving all of our applications to this platform as well as to move more and more third party applications to the platforms as well. So you'll see that there's a big difference in the the header bar here at the top of the screen between these three different or four different applications. This third one doesn't even have a header bar. This is the pivot tables application, which is now deprecated in favor of the data visualizer app, which supports pivot tables. And that is using application platform. But there's it's confusing to a user and it's hard to train a user to use a system that changes every time you move to a new app in that system. Here's a fourth one that is a third party application that's using different types of buttons, as well as different different header bar. So why do we build this framework, why do we build the application platform from the perspective of implementers users and funders. Again, it's to make easy things easy and hard things possible. So from for applications that are built into DHS to or that are developed on this platform and deployed to DHS to you have more consistency across applications which as I said helps with training it also helps with Yeah, professional. Yeah, how professional the the software is presented to the user base. You get the latest features faster. This is a really big one, especially with the introduction of continuous application delivery in 235 Because we can move much more quickly as the core development team at the University of Oslo, we can build more features into those applications we can make sure that those features are bug free and fix any bugs very quickly and release that to people that are on not necessarily just the latest version of the DHS to core release, but also previous versions as well. And if you're on the latest version, you don't have to wait six months until the next major release to get the latest features or bug fixes of an application. So everything should be much more streamlined and much more easier to innovate and much more agile in the development process. So that you can upgrade apps when you want and not before which means less retraining so in this case, when you upload an application or when you update an application, sometimes you need to retrain all of your users of that application, and that might be a big undertaking if there's a lot of changes in that So by decoupling the platform from the core, we're able to allow applications to be uploaded only when at the time that you're able to make that investment in training. This is this is obviously we want to make sure that people are able to update and get the latest features and latest bug fixes but sometimes that's not practical for an implementer or a user of a system. It also in a more general sense allows simplification of DHS to come customization, which means that you can build these applications that extend DHS to much more simply much more cost effectively, and without a lot of investment or effort on on the part of the local And finally and I think this is the most important one but it's at the end is you we will be able to foster a community of more high quality applications so by really kind of taking the details that are general and general purpose across all of DHS to applications and doing those the right way and providing those in the platform out of the box. The number and the quality of the community applications on the app hub and that are shared by the community will go up and we're already seeing that significantly through our academies and the applications that are being developed on the using these tools. So why does it matter for developers. I imagine there are a number of developers on the call here today. Basically, what the app platform is is create react app for DHS to it means that you get a out of the box application that you've create from scratch that has Modern UI components using the DHS to UI library has updated security and a real bus data data engine to be able to fetch and manage data from your DHS to instance. And it allows you to develop apps which are decoupled from DHS to versions using the version toggling functionality that we're introducing soon and worry about what rather than how so instead of worrying about how do I build a DHS to application. And you should be worried with the goal is to make the challenge be what DHS to application should I build. So the how should be self evident and easy to easy to figure out using the building blocks that we provide at the at the as the core DHS to development team, but also through outreach programs like the academies that we're working on and the University of Oslo design DHS to design lab which Magnus is running and has been talking or it will be talking about tomorrow for about an hour. So what is the goal of this DHS to application platform from a technical perspective now. I said this earlier as well but you we want to make it cheap fast and easy to build custom web applications which customize the functionality of DHS to I'll add to that that we also want to make it. Easy and cost effective to maintain those applications over time. So once you develop it, it should continue to work. And if it doesn't continue to work, then it should be straightforward to figure out what's gone wrong and how to fix it. For instance, if you're trying to work with a new version of DHS to their the ability to switch between multiple back end versions of DHS to within the same application will make that maintenance cost and maintenance burden much lower. And it'll also allow us to yeah kind of take things off the plate of the application developer and provide them in the platform in a way that will be maintained over time. The second piece of this is as I mentioned DHS to core applications and third party applications are on the same playing field so everything that we can do as the UIO core development team can also in the in the near future should be able to be done by the the community as well. So when we build a core application that's powerful and generic the adaptation of that same application to a local context should be easy and straightforward using the building blocks that we provide out of the box. How do we achieve this with the app platform. I'm going to go through this fairly quickly because I've covered it on on previous sessions and there's a number of materials on developers that teaches to that org that you can find to learn about this yourself. But I'm going to go through each of the components of the app platform and then I'll do a couple demos as well. So inversion of control is the main principle of the app platform talked about this previously in the other section but there's a lot of different things that go on in an app. And the the piece that's actually specific to the app that you're developing is very small so relatively small so it's this this middle section here everything else is common across all DHS to applications. We call that the app shell which is a common wrapper around around the the application specific components. And this means that we're redefining what an app is so instead of an app being a standalone web application that just happens to talk to DHS to a DHS to app is a DHS to app so it actually is a smaller component that lives in this platform in the shell that is provided by DHS to And we can do this in in a robust and scalable way because we as the DHS to community control the development ecosystem which is the platform these build processes and libraries that we provide the delivery mechanism which is that should be app hub apologize, which is the app hub and the installation of app hub applications into the DHS to core and the data access layer which is the DHS to core API and the app runtime, which I'll get into in a minute. This allows us to slot in both core apps and third party apps to a the DHS to app platform shell. So we can much more easily swap out the the custom secret sauce of a particular application within the common shell or wrapper of the app platform. We also have unified build tooling, which basically means that we have a common build script for all DHS to applications that does everything that you need in terms of transpiling your code, making sure that it runs against certain browsers, generating translation strings and injecting those into the application and putting that application into the shell wrapper that will actually create the full full blown web application at the end. What does this actually look like so this is an abbreviated version of a package that Jason file for a DHS to core application. I took out all of the things that are specific to this particular app which happens to be the maps application but this these are just the basically the dependencies that were are replaced by the platform. So instead of all of this and a lot of complexity that we then have to multiply by 34 times times for for different supported versions so we have 160 versions of all of this dependency mess. We have this so this is the same, more or less the same functionality as was in this giant mess of a package of Jason file in just to effectively two or three dependencies so we still have react, but we also have the the build tools, the common runtime and the UI library that allows us to have modern and standardized components, and I'll get into what each of these pieces do in just a minute. So the the app scripts which is that standard build tooling allows you to run a development server of your application. It allows you to build a production version of that application that allows you to run tests on your application. It also allows you to from the command line deploy directly to a DHS to instance so you can run the build script and then the deploy script, and I'll demonstrate this in a in a couple minutes and that will immediately deploy it to a running DHS to instance somewhere in the world. This is a lot more time efficient and a lot is also much more friendly to continuous integration environments to be able to develop your application and immediately deploy it to a running DHS to instance. And soon we'll be having will be adding the ability to publish to the DHS to app hub from the command line as well so you can automate the end and kind of streamline the the process that your application goes through to get to the app hub. This app scripts does a lot of other things as well that we've mentioned in the past in that big diagram of the different pieces of an application and I've listed them here as well. We also have a new configuration file which is configuration specific to DHS to the name at the top here is becomes the URL where your application is hosted in a DHS to instance. And so you will end up having your application installed at the your your base URL for your DHS to instance slash API slash apps slash simple dash app. The title that will then show up in the both the application menu. As well as in the header bar when you open that application will be what's defined as title here so simple example app and then the description will show up in various places in the UI as well. The final thing that we configure here is the the entry point of this application which is just an exported react component. So there's no need to have any web pack or babble build scripts or do any any magic around figuring out where a DHS to server is located or anything like that. This is a fairly simple configuration file. There are some other configuration options that you can use as well for more advanced use cases but I won't get into those today. And then the second piece here. We talked about unified build tooling and the scripts that are exposed by the platform. Now we'll talk about the runtime that is exposed by the platform. So this are services and features of DHS to that you can access while your application is running. This is the app runtime dependency it's published on npm and it has a number of different things that are included here. The UI primitives at the top there that actually comes from the second dependency here which is DHS to slash UI that is not included in app runtime, but the rest of these are cut out of the box provided by the platform. You have data fetching translations configuration server discovery and authentication and soon we'll be having some very cool new features coming along standardized loading and error handling for applications standardized routing to be able to develop history routing without having any without including any external dependencies will just be banked into the platform, alerting as well as data caching and offline support with service workers so that will be coming. Most of those will be coming in the next six months. You don't have specific dates for when those will be coming to the platform but look look for those coming soon as well. I mentioned the design system and the UI components that are exposed by this DHS to slash UI and dependency and you can learn more about that on the documentation website so you can all of this is linked from developers at DHS to.org. You have a very sophisticated design system that's developed by the DHS to designer Joe here at the University of Oslo and this has everything you would possibly want to know about how a DHS to application should look and feel everything from how much space you should put between text and a button to how you just convey the concept of depth and layering to a user when you have things like modal dialogues and alert bars and different navigation elements in a DHS to application. So that has kind of a theoretical introduction to what the rules of design in the DHS to world are. And then we have a DHS to slash UI. Oh, this is the wrong URL apologize for that. And I will fix that right now. We have a UI library as well which has exposes a number of reusable components that automatically adopt that design system so this button uses the the system that you that was designed by Joe, and it allows you to put that standardized DHS to button into your application and has many different components from things like text boxes to alert bars to the org unit tree to a transfer component for being able to select from a large set of options. For instance, that's used in the data visualizer application. There's a lot of components in this UI library and there's more and more added all the time. Finally, I'm going to talk a little bit about declarativity which I've talked about before, basically for both configuration of applications as well as flow of data in a DHS to application. We want to care about how rather than or sorry what rather than how again and that's one of the principles of the platform. So what is some what is declarative and what is the opposite of declarative. As an example of that a destination is something that's declarative. So I can give you the name of this Boulangerie in Paris, but, and the location of it, but I'm not telling you how to get there. I mean that that is the destination of where you want to go. If instead I gave you turn by turn directions of how you would walk from where you are now to that Boulangerie in Paris, then you would be I would be telling you how to get there and that's what's called imperative rather than declarative. I'm not going to get into too many of the advantages here but one of the main ones is that this application can declare what it wants so it can make a send a query to the app shell or the data engine in the in the app runtime, and that app shell or that that engine can then say, Alright, I know what you want. I'm going to figure out how to get it. So it might be that I already have fetched that information or some part of that information from the server previously in the same session. Maybe I have it stored in an offline cache. I can look that up locally and return that to you directly. Maybe I don't have it yet and I can need to actually go and send a request across the network to get that from the DJI to server. Wait for that to come back and then send it to you. So this allows the application to be built in a way that doesn't care where that data is coming from or how it's being fetched. And then you can actually decouple all of your components as well. So if you have 10 different components that need the same data, rather than needing to feed it to a central state system and then wire it down into the individual components that need it to maintain the state of that, that data in a central location, the app shell or the app platform can do that for you, and each of those components can be developed independently and then can be reused across applications as well in places that might not have that same centralized state store. Again, I'm not going to get too much into the technical details of why this is why this is good and important. But this is how we've developed our application runtime data engine, which I'll talk about here in a minute. So without the app runtime without the data engine, this is the code that you would need to write in and this is using react and using hooks so it's actually already much cleaner than if you were doing this with component based react or another, another library. But this is how you need to manage fetching data from a DHS to instance, you need to cert you need to figure out some way to get the base URL of that instance, which in this case is hard coded as local host 8080. But that's not going to be the case in when you actually deploy your application somewhere. You need to fetch the data, wait for it to come back, show a loading indicator while something is happening, show an error if an error occurs and finally render the data if it comes back correctly. This is actually abbreviated so you would actually need more if you wanted to be catch all of the different cases that might happen when you're fetching data in this way. So this is the imperative version of fetching data in react from a DHS to instance. Now we can do the exact same thing in a declarative way with the data engine and the data query. Basically, the query object here tells the engine that it wants to fetch a list of indicators are actually we want to fetch a single indicator which is defined by an ID. I'm not going to get into the details of how this works or how you pass variables to a query here. You can find a lot of information about that, particularly in the second workshop, which is on developers at DHS2.org. There's lots of recordings and slides from those sessions that you can look at, as well as some example exercises to test your knowledge and to play around with as well. But this basically just tells the data engine that it wants to get the indicator with a specific ID and doesn't care how that indicator is fetched. So the data engine then takes care of actually going and finding that information, figuring out if it's stored locally or if it needs to get fetched from across the network, sending the signal that the current state is loading or the current state is an error or the current state is success and data has been returned. And the component only needs to deal with those states and render the proper thing. So it's much simpler than the imperative version of the same thing. So I just introduced the concept of queries and mutations. It may seem a little bit strange and different. It's very similar to GraphQL, which some people might be familiar with. But we also have built a tool that specifically lets you test and explore the DHS2 API using these queries and mutations, which I didn't get into, but I'll talk about in a minute as well. So I'm going to go ahead and show that to you here. So you should see here now a website that's runtime.dhs2.nu slash playground. You can also find this by going to developers.dhs2.org, clicking on the docs page, clicking on app runtime. And then on the left here, there's a button for query playground. So we're going to go ahead and open that up. I'm going to put in the URL of a DHS2 instance that I want to test. You will have to note that this does need to be in the course whitelist of that particular instance. So if you're using the standalone hosted version of this playground, you'll need to do some configuration of your browser as well as the instance to be able to use it. But this is also this as application is also available in the app hub so you can install it directly to your, your instance. So I'm actually going to go ahead and do that. So I'm going to go to a DHS2 instance that I have running. I'm going to log in and I'm going to show you. I'm going to go to the app management app, or go to the app hub. And now if I search in here, I should see query playground. So data query playground by DHS2 and install the latest version. It's actually already installed, but I'm reinstalling it here so you can see that this installs that that playground to your local instance. And then I'm going to open that application. And this is the playground that we have provided here. So what this does is on the left side here you have a number of tabs that might be open might not be open that show different queries and the that could also be mutations. I'm going to go ahead and run this query which is fetching the me resource from the API. And then it will go ahead and fetch that from the local server. And it will show you the result result here on the right hand side. And then I go back to the hosted version. I wanted to show the one that's installed to a local instance because that's probably a better way to test against your local instance. But I'm going to show you now the standalone version because I have a number of tabs already saved that we'll, we'll see. A big shout out to my colleague, John Gerca, who added the ability to have tabs and to save these queries on the left hand side in local storage. So you'll see that I open this up and I already have three tabs open because it remembers that I had these these queries previously and I might want to use them again. And this is specific to the instance that I logged into. So if you logged into a different instance, it would have a different set of tabs saved as well. So let's go ahead and fetch. Now we're going to get the list of all the indicators in this instance. We're going to get set at a page size of 20 and we're going to get the third page so this is going to be indicators number 41 through 60 of this particular instance. We're going to get a couple fields the display name numerator denominator and the ID and display name of the user for this particular instance. I'm going to go ahead and click execute and get that result on the right hand side. So this is a really cool way to explore the API. You can run any API query on the left side here and get the results on the right. You can also again, as I said, save those queries and run them when you want to. So now we're going to get the same thing that we saw before, which is the name of the current user. We can also do a mutation. So if we saw in this, the name of this current user we have Hello World with two exclamation points as the introduction. Now I'm going to create a mutation. So I've selected mutation down at the bottom left of this playground. And I've selected the resource me. I'm going to update that resource and I'm going to tell it Hello World is no longer the introduction. Instead, I'm going to say bonjour. And I can then click execute. If I can go back to this tab with me and I execute again. You can see that the introduction was actually updated by that mutation. So this is making behind the scenes of put request or post request, depending to change that resource. There's a lot more information. Like I said, about this on developers.dhs2.org. Developers of dhs2.org in the documentation section under app runtime. There's a lot more documentation about how to use this use data query hook the different options that are available, how to construct a query. And you can also find on the events tab. If you go to the the platform or the let's go ahead and do the developer Academy workshop to you can find all of the session recordings from that workshop here. Advanced data queries would be a good one for more advanced use cases of dhs2 application runtime. Okay, getting close to the end of time here so I'm going to go back into my presentation. Again, this is the standardized life cycle of an application that we enable with this platform. So you can build your application you then publish it to the app hub and then can install it to a dhs2 production instance. But that's not all. You can also run tests on your local application. And this is this is quite powerful, I think, using the d2 CLI which is a command line interface for dhs2. You can actually create and spin up different versions of dhs2 running those locally in Docker with just single command on the local machine. And then you can test your application against that, all of those different versions of dhs2. Maybe it's only one initially but you you still want to test your application against a running version of dhs2, but you don't want to use the production version. You can go ahead and test against a local Docker instance if you have that capability. You can also run local unit tests with just automatically with the platform. There's a test command in in the scripts for the application platform as well. And then the other new line here in the bottom right is the ability to deploy directly to a production instance as I mentioned, you can create a dhs2 application run app scripts deploy, and it will install that instance directly to that application directly to a dhs2 instance. Again, find lots of resources on this developers that dhs2.org and the community practice and we continually update those. So look for more information. I'm going to go ahead and open it up for questions. I would wanted to do a quick demo of creating a new application and deploying it to an instance. I think we're running pretty short on time. So I'm going to open up for questions now and if there aren't too many questions I will do that demo. Let me see if I can find this. That's a good question from for I here. So yes, you can and this this is what I was was hoping to demonstrate. I will share actually I'm going to share a different window. So this is just a terminal where I have a let's let's say I have a local dhs2 application. So this is a local dhs2 application. I have the latest version so I'm just going to make sure that I have the latest version of this CLI app scripts application. I'm able to do this from the command line so I can build this application and then I can also deploy it directly to an application from the command line. But as for I mentioned here you can definitely you can definitely also upload that application manually. So I'll show that in a minute as well but that is also possible you can use the app management app to upload the zip file that's generated by the app platform. I'll show that in a minute while this is installing the version of the platform. The next question here is how much code of app runtime is reusable and react native. It's a very good question I have we have not actually officially supported react native at this time. There is the majority of the app runtime code is not react specific so the data engine specifically I guess so the engine itself is is not doesn't have any reactive doesn't actually have any dependencies at all it's just JavaScript so that should be able to run very easily in react native. We would need a different wrapper potentially to expose that to react native right now we only have a react wrapper for that engine. But that's definitely something that would be a good feature request if that's something that you're interested in using this for we don't have any core applications that use react native at this time. Another question was does the CLI supports TypeScript. The answer is yes it does we don't generally use that for most of our applications we use TypeScript for the app runtime specifically in a kind of narrow use case for type safety in that heavily you utilize library. And that is built with the platform as well so the CLI the platform CLI supports both building libraries and building applications, and it does support TypeScript out of the box you can also customize it with different Babel plugins if you want to use flow types for instance, which we do in one one application. Does the app runtime as presented support all API web API resources or at least all the commonly used ones. Yes it should if you find any that it does not support. We would like to make sure that it does support them. But as far as we know everyone, every endpoint, a web API endpoint should be supported by that platform, or the app runtime. I'm going to go ahead and finish up here so I've installed the latest version of the CLI Apps Scripts. And I have as I mentioned an application running locally you can see the to that config.js which has just a type of an application and points to an entry point. I can run yarn build, which under the hood does D2 Apps Scripts build as you can see there. It actually is going to now build a production artifact that is installable to a DHS to instance. It generates all of the translations for this application builds the application builds the app shell that wraps around that app with the application inside of it. And then in about 30 seconds should see actually should be faster than this but my computer is going very slowly today. It builds an archive so a dot zip file that that that you can then immediately upload to a DHS to instance so you could manually upload this zip file to the app management app in your instance for instance. So if I go to the app management app, and maybe you can't see my screen. I'm going to share just the whole desktop now. So in this app management app that you can see here, you could click upload and then select the zip file and upload that was generated by that build. Now if we look at the this so this was generated the zip file, we can also run yarn deploy. Sorry yarn yarn deploy is not defined so I actually need to put that into the scripts for my application. It is available here. But I hadn't defined it as a script. So now if I go to yarn deploy, it will run the deploy script where it will ask me for a instance URL. I'm going to put in the one that I was using before. It will ask me for a username and password for a user that is able to install applications to that instance. I apologize. I made a mistake because it is not an HTTPS should be if you're using a production instance but there's not a production instance. We need to wrap up here but I will keep doing this while I talk. And hopefully not make any more mistakes. I will go ahead and go through the I missed type the password. Apologies. But you should be able to immediately upload the application directly from this instance here. I will go through the rest of the questions that were posted on the community of practice after this session to answer them there. If you have any more questions, feel free to post them on that, that, that topic in the community of practice. And I will do this correctly this time. So now we are able to actually upload the application to d2.winged.tech. I go back here, reload the app management app and you can see that this application has been installed to this running instance from the community. So that is just a demonstration of the deploy command. We are out of time unfortunately here today. Thank you all very much again for joining me. And if you have any questions post them on the community of practice that topic that was started and I will answer them asynchronously after this. If you stay on this session, you should see the great set. A great topic by a number of my colleagues that is coming up next about scripting custom forms so looking forward to seeing that myself and thank you everyone for joining.