In my startup, we are trying to provide some public good services using DHIS2 and also do DHIS2 as a service to help in local implementation in Health, Agriculture and Education.
However, I want to find out, how do I deploy DHIS2 without coupling it with the app platform or better still if I want to customize the app platform to provide additional solution?
Hi @jetisco4u
This is an interesting discussion. Would be interesting to know more about the use case and why’d you need to send DHIS2 to the backend? As you know that the platform is quite flexible and customizable; however, it’s important to consider the software updates and developer roadmap. To answer your first question whether it’d possible to use DHIS2 in the backend which is very close to the question about having public portals, I think technically it is possible using the API, right? You can initiate API requests to get, create, or update the data.
If you mean by the app platform as the UI then certainly the API has many helpful functionalities that could allow you to almost not have to use the UI. The Android Capture app is an example of an app that doesn’t customize nor couples the platform but makes an excellent use of the platform.
Would still be great to hear about the use case @jetisco4u! Thanks!
We are trying to use all the API functionality when building the Docker image. But would like to host the app using a custom platform-app that utilize a React Meta framework we build. I am looking at the possibility of hosting the app without building the dhis-web/pom.xml
@Gassim thanks for your comprehensive reply. I just review it now. So far, I updated all the dependencies and devDependencies of the app-platform, cli tools, app-runtime, ui (including the UI Header), core apps, and React. I am trying to create new cli tool to make it easy to bootstrap say a CRA or Vite app on Javascript or Typescript. This way it will be easy to rebrand some of our existing apps to integrate with DHIS2.
But the current challenge is that if I build the apps like this, and I update the apps it will reload the ones in the app-hub which mostly used the old dependencies and CRA only. So what I plan to do now is to create a custom app hub to upload apps and possibly extend it to accept plugins.
I will also limit the core apps to bundle in the dhis2-core to just a view. To handle update and feature addition to dhis2, I am writing a script to automatically handle about 90% of the upgrade. I will share any challenge or request I have.
But I will like to ask a question. I saw that the core apps to bundle are loaded from github when building the dhis-web jar. Which of the apps is stored in the app-hub, is it only the ones uploaded with App Management app or including the ones loaded and renamed when building the docker image?
Hi @jet - I’m not sure I understand your use-case fully… can you explain what you’re trying to do? Do you just want to have a custom headerbar in all core DHIS2 apps, or are you creating all new apps / web interfaces yourself for everything DHIS2 can do?
I want a custom header bar in all core DHIS2
Thanks for the reply @jetisco4u ! Currently that needs to be accomplished by forking all core apps and updating the header bar, then you can install new versions of those apps directly into the DHIS2 instance through the App Management App “Manual Install” tab.
In the next major release (v42, expected May 2025) we plan to introduce a feature called “global shell” which makes the headerbar universal and would allow you to update it in only one place without forking any other apps. If we add that feature it will hopefully make make your task much easier!
That is surely a great way t do it but I am undertaking a different approach. I am using my custom build tool from my DOMS Cross-Platform Fullstack Runtime Server suite of library called doms-kitup to replace the cli and have build a doms-dhis2-shell, doms-dhis2-adapter, doms-dhis2-client to bootstrap DHIS2 Applications. Next now I am working on a forked version of the core to support modern web tools while keep the core Java features.
By the way I am actually forking all the apps and customizing them to align with our design principles according to the DataOrb OpenApi Metadata Specification (DOMS).