 Okay, hello everyone. Once again, my name is Austin McGee. I have been working at the HS to for coming up on three years now and and have been leading the effort to develop an application platform, which I'll talk about today. And many of you will recognize some of the slides that I'll give and some of the points that I'll make in this in this presentation because it's going to be an overview of what it means to develop applications for DHS to and what it the tools that we provide as the DHS to core team to make that easier and more robust. What what those look like and how you can use them. And we'll get into more details about how specifically to use some of the those tools in the next couple days as well as in the workshop in May. And but I'll also cover a little bit about some of the the upcoming features that are expected to be released in in the application platform that will I think be quite powerful and useful for development of applications. And so I hope that you find this interesting. So what is a DHS to application, probably everyone here knows what DHS to is. And, but if you don't it stands for district information system. Number two version two, and DHS to is used in something like 70 countries around the world. There's not only for health information systems but there's a number of other use cases as well. And things like logistics and education are burgeoning use cases for DHS to as a software. All over the world. And, but it's built as a kind of a global good and open source software that's free for anyone to download and use. That's built coordinated by the University of Oslo and a core team of developers there but also open source and available for everyone else to contribute as well. So it's a global good and a software on the global scale. It's not going to meet the needs of everyone in all of those 70 plus countries where it's used extensively. And because of that, we develop DHS to as a platform so it is a platform meaning that it can be extended and used in many different contexts. And it doesn't need to be kind of restricted to that what the global software provides. And so we have a concept of applications within DHS to which are effectively many web applications that talk to the DHS to API and are able to tailor the DHS to data model and interface for a particular use case or a particular set of use cases that someone might be trying to address. In general a DHS to application is a web application so under the hood it's just HTML and JavaScript and CSS that runs in your browser. It can be anything but we do to tailor our tools for a smaller set of technologies particularly targeted at react I'll get into that in a minute. This DHS to web application communicates with a server that's sitting usually in a ministry or maybe in the cloud and in Amazon web services something like that, which is the DHS to server and that has a rest API which allows you to access data about the particular DHS to instance that you are communicating with. The application is available it's installed into the server itself so it's available to authenticated DHS to users. And that also means that you can restrict the functionality of your application based on the user that's accessing it, which is something that is a little bit harder to do if you are building a web application just by yourself. And in general this is just a kind of a general rule of thumb for how what applications do is they allow a user to do something with their DHS to metadata and data and particularly that user to how to work with that data in a particular way so that might be a an application for someone at a health clinic to register someone with COVID-19 or it might be an application for a contact tracer to look at a case of COVID-19 and all of their contacts and their contacts contacts and then track the progression of a disease like COVID-19 or Ebola or another communicable disease such as that. Or it might be something more kind of low level that allows a an administrator of a DHS to instance to configure DHS to for logistics or education or another use case. There are a number of applications that come built in with DHS to when it's installed. Currently that number is 26 but they're give or take a few that are that are smaller applications. There are a number of other applications that are also developed by the DHS to core team at UIO, which a university is the University of Oslo, which are not necessarily bundled but deployed through the app hub, which I'll get into in a minute as well. What do we provide for application development and there are two sort of types of tools that we provide on the left you have build time developer tools, which means these are things that you as an application developer will use on your local machine to make it easier to create and maintain and build DHS to applications. And then we also have runtime libraries so library. These are things that are running in the browser with your application as it's deployed to the user of that application. Within each of those categories we have a few different tools. The main ones on the left is what we call the app platform but it's really a set of build scripts. And this is very similar to create react app if you're familiar with that. It's also vaguely similar to next JS and some other build tooling, build tooling that wraps things like webpack and other other web technologies. And then we also have CLI where we won't talk too much about the various functionalities of that today or tomorrow I don't think we will get into it a little bit but basically this has a number of utilities that allow you to, for instance, create a DHS to instance or run a DHS to on your local machine. And that's very useful especially when you're building an application that might target multiple versions of DHS to because you can spin up multiple versions of that server DHS to server to test your application. You can also run it with various databases and database configurations that you might have. There are a number of other utilities as well for things like using writing Cyprus tests writing and running Cyprus tests interacting with the DHS to API from the command line things like that that you can investigate as well if you're if you're interested in this. On the right side we have some runtime libraries so we have the app runtime, which basically provides a set of tools for communicating with DHS to the DHS to API, as well as for doing standard things in a DHS to application. The main one that we'll talk about probably not tomorrow but but in the next workshop is alerts. And so that means that any component or any application can create an alert that shows up as a snack bar in your in your application. And a standardized way without needing to implement it yourself. There's a number of other things coming along the coming down the line in the app runtime library as well. Right now you can use it to access basically query data from DHS to as well as perform mutations to to modify data in DHS to similarly to similar to how you would interact with the rest API today. And we'll get into more about the rest API tomorrow. It can also in the near future do things like data caching and providing better interfaces for in internationalization or localization as well. And we'll get into that somewhere. We also have an extensive UI library which Joe and Kai will demonstrate a little bit later today. And this has a lot of standard components to make your DHS to application look and feel like a DHS to application so it's, it's very familiar to users of the system. And it's also easy for you as developers to build in this standardized and professional professional way. Finally, we have the app shell and the app adapter and these are providing some things out of the box for a web application that makes it a fully functioning DHS to app. Like the header bar, the ability to log in with a login dialogue, things like that authentication, all of that is provided under the hood by the app shell and the app adapter. But you don't really need to worry about those because they are provided for you by the by the build script the app platform so all your application really needs to get to worry about is what the what that app is good at what it does. Moving on to the next one here. I mentioned the technology stack and we do require react for use of our tools at least for the moment. This is to help us kind of tailor narrow narrow the scope of the the the amount that of tools that we need to maintain, but it also allows much more easy sharing of components and code and application examples between members of the DHS to developer community. So we we've, we've standardized on using react in the application run or in the runtime of DHS to apps. And we may in the future extend some pieces of the the platform or the runtime to be accessible from other view frameworks like view JS or Angular, but for now react is is required for use of these tools. We also require yarn and node for the build tooling. And so that's just two requirements on your local machine to be able to run these applications, or these these tools locally. And we also use get extensively. So if you're not familiar with get, we do use that and GitHub as well. What does the app platform do. We've seen this, many of you have probably seen this diagram before. Basically it takes your source code. It takes some dependencies for your application, and it takes a few other things in this case I'm just using translation strings as an example. You run a script on your local machine that will basically build that application into a set of files of HTML JavaScript and CSS files. That can then be run independently and can also be installed into DHS to as an application. So I'm going to need to plug in my computer so I will be right back. I'm going to get this next step here. We have here the set of steps that you take when you are building building your application on the left, we have that same diagram. But what happens after that so you you build your application, and then you get a set of files, and actually the build script will also automatically create the zip file that you need and generate the manifest that you need to install a DHS to application into your DHS to instance. From there you can go to the app management app in DHS to and upload the zip file and manually install your application. You can also use the D2 app scripts deploy command, which is on the bottom row here, and that will allow you to basically from the command line deploy your application to a running DHS to instance. And then it will ask you for username and password for the for that instance, and then it will automatically do the installation and the upload of that application, and it will open it in your web browser. So that's a nice way to test out a production deployment or a staging deployment of your application to a DHS to instance. So that the recommended way, at least for generic applications is to publish your application to the app hub so we have what we call the DHS to app hub, which is a kind of like the app store for iPhone or the play store for Android. It's where a bunch of applications live where various developers have made them. And then they can be installed into any DHS to instance. And it has some additional requirements on the application to be generic and usable in any DHS to instance. But it really helps to grow the community as well as to grow the exposure of your, your, your applications that you have developed. Martin you're raising it means it means that there's a there's there's an unlimited number of DHS to instances there that are that goes off into the distance on the right but thank you for pointing it out. So, yeah, the app hub is basically a place where these generic applications live and can be uploaded and published by application developers, and then can be installed into all these various DHS to instances. So very soon we will have a publish command that lets you also from the command line publish directly to the app hub. We have a team of developers at DHS to core team and at the University of Oslo, who review those applications as they're submitted and provide feedback on things like security and gender, whether they're suitably generic to be able to run in different DHS to instances. And that's also a very good way to get feedback on your application when it's when it's a generic one that and you would like to share it with other people. So that the publish command on the command line with the app scripts is coming very soon. And that will allow you from the command line to automatically publish your application as well as deploy it to a DHS to instance directly. So why do we need these tools and we need these tools because it's a lot of work to build a web application in general, and when DHS to core team is building 27 or 34 if you count the ones that are deployed on the app hub of those applications. It's, it's a lot of work. And it's a lot of work for every developer that's building an app in DHS to as well. So we built these tools in order to make it easier and less kind of repeated work to build an application that's powerful and useful for the DHS to community, because there are a lot of things that are the same in every application. And we're trying to make that make it as easy as possible to, yeah, to build to build those applications in a standardized way. It also allows a lot of the common functionality of all those apps to be automatically included, rather than needing to be duplicated or reinvented in every application. It provides standard as look and feel for DHS to users, which is very important because when, especially with DHS to instances there might be thousands of users that are using these applications. And it takes a lot of effort to train them on what type of button to expect when you are submitting a form or it sounds like very something very simple but there's a lot of training and familiarity that is necessary to make the usability as as as high as possible. It also less work to maintain those applications and keep them up to date with new versions of DHS to as well as new versions of the library that comes out with the libraries that we that we develop so things like new versions of the header bar or the or unit tree component in the UI library, or even the new versions of the platform. It makes it much much easier to stay up to date than if you were building a web application from scratch and including a bunch of libraries. It's also and I think this is very important and something we're excited to see growing in the community is it makes it easier to share and collaborate on those applications and those use cases with other developers in the community. And especially as the DHS to is a huge global presence in in many different countries, and a lot of the use cases are they might not be exactly the same but they're very similar in a lot of those different countries. So it makes sense for developers and and implementers of DHS to in those different places to work together to build one application rather than each building their own and then having kind of multiple implementations of the same thing. A lot of wasted effort and and probably each of those is not as good as it could be if they worked together. By providing this common set of tools, we make it easier to share and collaborate between members of the developer community. And we're really looking forward to seeing how those tools are used to enhance that collaboration. If you are working or are using these tools to collaborate, we'd really like to hear from you as well to see how we can improve the ability of the community to to work together. And this is I'm going to go through this fairly quickly because most of you have seen or many of you may have seen these slides before. There's a general overview of what the application platform or the app shell concept is, and why it exists. And there's a Larry wall is the creator of Pearl, and he has a quote that I like which says easy things should be easy, and hard things should be possible. And this is the goal of the application platform basically if you're doing something easy, it should be very easy to do. All DHS to applications need to be able to authenticate with the HS to they need to have the header bar. They need to translate some things. Those should be easy things to do. And so the goal is to make them easy to develop. And then just like DHS to in general. Hard things should be possible meaning that there are very complex and sophisticated use cases for these applications, which the platform shouldn't prevent you from using from doing from from accessing. And so those things should still be possible and maybe even easier when using these tools that we're providing. And this is a representation of a lot of the things that exist within a DHS to application. I'm not going to go through all of them, but there are mentioned the header bar there also might be translations 18 and alerts loading indicators, common UI components routing that are able to fetch and write data to the DHS to API access to the schema of metadata for a for a DHS to instance authentication caching generation of a manifest which tells DHS to the name of your application and what resources it requires the ability to publish and release as I mentioned we saw in that previous slide. The application to a DHS to instance or to the app hub. There's lots of things in a DHS to application and most of those things are the same or very similar across all those applications. So that's why we've built this tooling and when you multiply that by 34 core applications and said 27 or so are bundled into DHS to and then there are several that are developed by the core the same core team but are deployed through the app hub. Add add in several libraries that we also maintain. That's a lot of code bases, and especially when we then multiply it by the number of supported DHS to versions, because before feature toggling we didn't really have the ability to have a single application to multiple versions of DHS to and that's one of the goals of the platform as well. So again we have all of these things that are within a an application, but the things that make that app actually unique and specific to do to our use case are are a very small portion of those, all those things that that you need to think about when you're building that application. And so we have extracted those things into what we call an app shell, or a common wrapper that is provided for you by the application platform, and is standard across all the apps in a system. And then be basically the same app shell can be available to all apps in DHS to and then you can swap out the individual pieces of the component or the component, which is the application itself. And that makes the amount that you need to develop to build an application much much smaller, easier to maintain and more consistent across different applications. As Deborah mentioned, we're going to learn a few things in this workshop this week today and tomorrow. This is a very high level overview of what those will be how to create a new app with the app platform how to use the build tools to build your applications and develop them. We'll also learn about the UI components and how to interact with the documentation that we've developed that allows you to explore those components and use them in your applications. And then tomorrow we'll learn more about how to communicate with the DHS to API using the app runtime. We have concept of queries and mutations. And we'll also learn a little bit about what what the API provides what the different sections of that API are and how to use them in your app. So next workshop. There's a lot that will be in the next workshop it will be four days instead of two, it will be focused on more advanced topics. So to the, the goal of the workshop today and tomorrow is to give a baseline for how to build applications, but there's a lot that we won't be able to get to in just two days. So next workshop in May, we will be covering things like the alert service ability to do translations in an application, how to use the data store to configure and store saved objects in your application. How to secure your app, which is very, very important we're seeing more and more important importance put on how secure an application is and how what what is being done in the application source code to make sure that that security is is guaranteed. And so we'll talk about how to store credentials if you need to, ideally you don't how what what you shouldn't be doing in your application in order to make sure that they stay secure. And that's very important because there's potentially millions of people's information is stored in DHS to so it's quite critical that applications are built in a secure way. We'll also talk about app hub publication workflows, and several other things that are upcoming. And I'll talk about some of the things that are coming soon for the app platform as a whole. And, and many of those I hope will, or several of those I hope will be available to teach in May at that next workshop as well so that will is quite exciting. And if there are other things that aren't on this list, or that you know that you would like to interact with the core team on or to learn more about, please let us know so in Slack or via email directly to myself or to Deborah. Let us know what you want to learn about and what maybe isn't clear or also what you would like to see from the community as a whole. So please give us your feedback, especially for this workshop in May on what you would like to see to what we what you would like to learn and how would you would like to get to learn it and what what you'd like to see. These are some things that are coming soon to the app platform. I would just kind of tease these a little bit and these are all for the most part all in progress. The last two are coming soon not not quite in progress yet. But you should be seeing these coming down the line quite soon. And the first, which is quite exciting is called dynamic modules. Basically another another word for this is micro front ends if you're familiar with that term. Basically this allows a running DHS to application to incorporate components or plugins from other running applications on a DHS to instance. So for things like the app shell this is very powerful because it allows every app to share the same header bar and login configuration and things like that. Like the org unit tree, even if the application hasn't been built in some time so that those those modules are loaded at runtime in the browser, rather than at build time, which allows them to stay up to date and stay consistent for users. Feature toggling allows you to talk to multiple different server versions data caching allows multiple components to request the same data from DHS to and the app runtime will know to only make one request across the network instead of to which can significantly help to reduce the amount of traffic that you will see from your application in particularly low bandwidth settings for those applications. So DWA support also very useful for those low bandwidth or no internet situations, which will allow an application to very easily go into offline mode and store not only all of the static resources like HTML CSS and JavaScript offline, but also store a set of data for the use cases offline and be able to access that information when there's no internet and routing as an out of the box functionality probably similar to next JS which has you basically just create a file in a particular place and that will give you automatically a routing in your single page application. And that is something that you can expect to see in DHS to at some point in the future as well. And then the big one that's coming, hopefully in 237 for web hooks server side extensions, either 237 238 more likely 238, basically this allows you to not only write client side code but also some server side extensions. I think, like functions as a service lambda functions that type of thing, but running on a DHS to server to be able to perform more sophisticated data workflows in in a DHS to server. Again, we would love to hear your feedback on what else you want to see from these tools what's missing. We build these for our own applications and as well as for third party applications. So we are very very excited and looking forward to see what what else you would like like us to build so please don't be shy about about sharing that. I'm on the couple minutes late apologies but that is just a quick overview of what it means to be a DHS to application developer and to build the applications for DHS to instances and the tools that we provide to make that easier and more robust.