Speculating on the future of OpenMRS development, with OWA

Development
1

Continuing the discussion from Developers Forum 2016-01-05: Topic Fest, and using OWA to build standalone HTML/JS OpenMRS Apps:

@mksd there is no straightforward answer to the question you ask.

My opinions/predictions:

  • The existing OpenMRS application is valuable, and it will continue to be used, developed, and supported. Technologies like HTML Form Entry and XForms have big install bases and lots of real-world proven value.

  • Most OpenMRS development effort is going to be conservative, and wait to see tech approaches be proven before adopting them. (Existing implementations are biased to prefer incremental improvements over than revolutionary change; we care a lot about supporting them and lots of devs come from those implementations)

  • Lots of exciting stuff is happening in new Distributions, volunteer spikes, and implementations, and new approaches get wide adoption in OpenMRS after having proven themselves here.

  • The current OpenMRS tech stack has tended to slow down this experimentation. HTML+JS+REST+OWA will let it happen faster, so the pace of “new stuff” is going to increase from now on. We were already committed to doing more with REST (and putting more dev effort into the REST module), and the existence of OWA will speed this up.

  • In the long run, client-side apps built on HTML+JS will take over the OpenMRS world.

  • How fast this happens is unclear, and the way the transition plays out depends a lot on how effectively we are able to mix OWA-packaged code with the existing Reference Application. (Nobody has shown any examples of this yet, and experimentation is welcome.)

  • Today the overwhelming OpenMRS favorite JS tech is AngularJS. At some point WebComponents may take over (@sunbiz definitely thinks so).

  • OWA will quickly become the go-to approach for use cases like dashboards and standalone apps that don’t actually interact with the rest of the application.

  • OMODs will be around forever: we will always need server-side code (new domain objects, REST services, etc) and we will never move away from Java for this.

Having said all that, it’s important to take a step back and say that this is all micro-level tech stuff. In the broader context, while OpenMRS has been wildly successful viewed from the perspective of its initial founding, the market penetration of OpenMRS (or any EHR system) across the developing world is still tiny. And ultimately this is more a technology delivery problem than a technology problem.

The truly transformational change will be a well-packaged distribution of OpenMRS that can go to vast scale (compared to the current install base), and be configured/maintained/upgraded with tiny marginal technologist effort per-installation. As a trend this will eclipse everything I wrote above: ease of packaging, deployment, and maintenance will win, regardless of what’s inside the box.

2

Like Darius said, omods are appropriate for Java services. Infact, we should assemble omods of omods and think of ways in which they will start in order to enable distributions. OWAs are supposed to be packaged together if they are UIs that work with RESTful services. Since the 1.0 release of the module, the 
/src/main/webapp content from any omod will be moved to the appdataowa location, if it finds the manifest.webapp in the root. This functionality already works and is tested. In 1.3 release we plan to make all the UI for managing apps/settings an open web app itself that will be packaged in the omod.

I think this is a common misconception about webcomponents. One can write components in any framework, including AngularJS. Its just surrounding your existing HTML in a <template> tag. So it is perfectly complementary and that is the strength of the standard. With ES6 modules, webcomponents are perfectly timed. I think as a community, and builders of platforms, we should develop components (in AngularJS, ReactJS, JQuery and what have you) and allow non-devs to combine them on pages and create their own workflows.

Instead of “a” distribution, would be nicer if this was distribution of components that people could assemble like lego blocks. I give the lego analogy because it has to be so simple that pieces can be put together by anyone.

2 Likes