Continuing the discussion from An amazing future for OpenMRS:
A pretty wild idea, crazy too, but since OpenMRS is moving to a REST/FHIR based API with micro-front ends, is this the time to consider a language with less overhead than Java - maybe Python running Django with DRF or even PHP running API Platform?
This reduces developer overhead and speeds up integration with multiple databases even NoSQL for some aspects of the platform…
Anyone up for a sprint for a POC?
To move a modern back end from JAVA to PHP, no wonder you called it a pretty wild and crazy idea!!! That would be a dead instead of amazing future. 
@dkayiwa you said nothing about Python Django with DRF?
On PHP - Facebook, US Government (Drupal/Wordpress), Wikipedia, MailChimp, Spotify cannot be wrong
But either way, I think Java has grown long in the tooth, and its time to consider replacing it with something more developer friendly that is less resource intensive too
@dkayiwa a dead future is also Amazing ofcourse
probably Python is more promising
I have no practical experience with the Django REST Framework (DRF). But i would not dedicate our scarce resources to evaluating it when the ThoughtWorks technology radar has not been able to move it from the TRIAL stage, since 2015 https://www.thoughtworks.com/radar/languages-and-frameworks/django-rest
Surely they cannot not be wrong when dealing with a different use case from ours. 
Switching from Java to a totally new language is such a huge investment that we would need a very compelling and practically tested case for diverting our already not enough resources, from delivering new features. For dealing with the resource intensive issue, we would need to confirm that it has nothing to do with our application design or architecture. Anyway, i would first evaluate less disruptive frameworks like Micronaut, before thinking of the language switch. Platforms | Object Computing, Inc.
The ThoughtWorks technology radar puts it in the Assess stage: Micronaut | Technology Radar | Thoughtworks
I would rather invest in refactoring our backend so that it can work with Spring Boot (and all the amazing stuff that comes with it).
A Java backend is a comfortable situation in many ways, one of them is that resources are not scarce, there’s oceans of Java devs out there.
+100 
+1000
There’s Many Man hours of Java API Code powering OpenMRS !! It is like rebuilding the whole Linux Kernel using Java .
I’d vote this for new projects , it’s rather an astronomical investment to venture into refactoring Core and module code Base , and i don’t think there’s available Dev resource to do the terrific work already done.
Which language is more developer friendly than Java
Considering the robustness and ecosystem of Java, it just makes sense to build the core in Java and expose the REST interface for any developer to implement
What is the advantage of OpenMRS over, say, a FHIR server that can now be spun up using Azure? https://azure.microsoft.com/en-us/services/azure-api-for-fhir/
If there is global health specific functionality that is currently not captured in the FHIR standard, wouldn’t it be worth investing in contributing to it?
Implementation language of choice seems secondary.
What would be the investment in this case, do you have any ideas of how big the refactoring would be?
Most EMR implementations require data to be stored in country, and probably within the health facility (Internet connectivity is not as reliable), so would have to be local, but it is an excellent idea too as the FHIR squad is making progress in this area
@ibacher thoughts?
I’ve got a lot of them, especially here, but certainly the move towards representing as much of the OpenMRS data model as we can via FHIR is a goal of the FHIR squad that we are actively working towards and when we get to a point where the data that we need to power OpenMRS can be gathered from a FHIR API, it might make sense to just move (some of) the backing data to a FHIR store.
It’s important to realise, though, that there are limitations to FHIR. It’s not intended as a general purpose data model for EHRs. Some key things will never be possible to completely migrate to FHIR. For instance, representing users and their privileges has routinely be ruled out-of-scope for FHIR. Other things are less mature in FHIR than we might like. For example, there is work being done on representing things like OpenMRS forms (what FHIR calls Questionnaires)—and some of this work is very impressive (there are a number of condition-specific tools that have been built using this, including things like a tool for recommendations around alcohol use and tools for screening for COVID-19), but the standards around this haven’t quite reached the point where they can serve as a general-purpose form tool. Similarly, FHIR itself is a moving target with each new release bringing about at least some major changes. In fact, the most recent release (R4—released a few months after the initial question) is the first release to feature “normative” content, which just means that certain resources have been widely used and are unlikely to change, at least in major ways. But even then, the “normative content” covers only a small part of the FHIR specification, and there are certainly major changes under way for the next releases (R5, the next major version, is currently targetted at Q2 2022; however, there is a quite large update currently called R4B that is expected to be finalised in Q2 2021).
Finally, the reality of it is that while FHIR has seen some great adoption and a wide array of use-cases, it’s still under-used for use-cases that might be expected. For example, the OpenMRS FHIR Squad and I-TECH have worked on what might be the first FHIR-based integration between an EHR and a LIS. Certainly, we had a hard time finding other examples out there. The reality is that current EHR platforms in high-income countries are still relying on pre-existing technologies and while I know both the NHS in the UK and ONC in the USA are pushing FHIR-based solutions, we’re still a bit away from that becoming ubiquitous (and, in the US context in particular, the push towards FHIR is actually a push towards enabling patients to have electronic access to their medical records stored in EHRs).
If I’ve sounded a bit down on FHIR, I’m not really. I think there’s actually exciting opportunities for the global health informatics community to get involved with FHIR and push it in directions to meet the needs and challenges faced with providing health care outside of rich countries. Moreover, I think that FHIR provides a great building-block to enable richer data sharing among electronic health care systems. But it’s certainly not a simple drop-in solution.
I actually pinned your response for myself here @ibacher. Such rich insight.