I just want to call attention to some higher-priority gaps I’m seeing in our 3.x default modules approach, and see what folks think about these other module suggestions.
Background: Since we’re setting up our new 3.x Demo environment at o3.openmrs.org, and since we’re thinking about what modules need to be included in new packages like OHRI, I’ve done a gap analysis across 3 different places to try and check if our new default 3.x modules list is adequate. I compared:
The main gaps I’m curious about are where these modules are included in both the SPA and OHRI environments, but aren’t included in the 3.x distro.properties convention. (I’m not saying all of these should be included in our new 3.x distro.properties list. I know we want to keep the list short. Just wondering if some of these should be included.)
Reporting
Reporting REST
Single Page Application (isn’t this a no-brainer for 3.x…?)
These will probably be moved into at least the dev environment in the near future. Currently, they are mostly used for features under-developement rather than any features in the 3.x RefApp. With them, we’ll also need:
Serialization Xstream
HTML Widgets (though it might be nice to separate out the legacy ui from the “core” bits of the reporting framework)
Calculation
Oddly, no! The SPA is served from a simple static server separate from the OpenMRS server. Ultimately, we probably should have a couple of sample “reference deployments”, e.g., on that uses module-spa and one configured like the current setup.
These are essentially the modules that make up the 2.x frontend. I’m agnostic on whether we want them in there are not.
Another one I’m agnostic on. With this one, though, it’s worth considering that the HTML Form Entry views that most people are working with now are those rendered through HTML Form Entry UI, i.e., using the 2.x RefApp UI. To leverage this, we’d need to install all of the 2.x UI modules as well as emrapi.
I fully agree with @ibacher overall. The difference is that I would like to stick to the absolute minimum list required. So for those where @ibacher is agnostic I tend to rather say no. Always under my own rule that says that a module should go if it isn’t absolutely required.
I’m even ok to revert back to the legacy UI experience for the OpenMRS admin UI, rather than pulling in all that Admin UI requires (including presumably the OWA module.)
Porting the admin UI to MFs was supposed to be happening this last GSoC, and didn’t, but should remain on our radar as some UI debt to handle.
And yes, unintuitively, the SPA module is not required and should be rather considered as a practice to avoid if possible when it comes to serving ESMs.
It needs to exist though, especially for hybrid setups (like those of PIH presumably and the ICRC), but isn’t required for pure O3 setups.
I was just going to mention, we’re considering adding a REST endpoint to the SPA module which would allow the implementer tools to save config directly to the server. This would be useful for test servers, demo servers, and orgs using OpenMRS without version control (small clinics not well integrated with the OpenMRS community, etc). CC @grace@jdick
Because it breaks the separation of concerns frontend vs backend as independent services. By serving frontend assets through the OpenMRS backend this module creates a hard dependency with the OpenMRS backend that never needed to exist. For instance our frontend should be launched and served even if the backend is down (that would allow for a “system is under maintenance” app layer.)
I understand that this module is useful though, and we intend to use it for hybrid setups as well. But for those implementations that are pure O3, no.
While I like the approach for the clean 3.x properties with a clean “new slim” OpenMRS, however I would suggest the creation of a 3.x-legacy for those who may decide to go with a mix of micro-frontends & the old legacy HTML form entry plus 2.x modules
This means there is a bridge between the two worlds, a brand new clean “modern” package & a legacy supported package, to ease the adoption bridge since not all new distributions will move to the 3.x only
Managing backwards compatibility is a key requirement to ease the migration pains for implementors who have different skillsets & needs
Thanks @ssmusoke this is a really interesting thought. Are you imagining that this 3.x-legacy distro would include all the ~42 RefApp 2.x modules listed here?
Or could it be a slightly trimmer version, so just including some of the HTML modules mentioned above?
Or, could we even have a sub-kit of the other legacy modules - so there’s only 1 shared RefApp 3.x distro that folks use, but if they want a simple way to add the other legacy modules, they could just add that folder?
Rather than introducing a 3.x-legacy we could start making the Ref App 2.x hybrid on its own branch from 2.13 or whenever appropriate. Very much in the same way than when OWAs where introduced and that some of the UI was served that way.
@mksd The legacy has to be a living mainstream version otherwise it will be forgotten in the graveyard and no resources allocated to modernizing it
IMO the current developments are great for developers, but not so much for implementers which is the path that made OpenMRS lose its way in the first place
Why make the old Reference Application where the majority of implementations are an odd child why pushing the new models - which in experience will also be obsolete in the next 18 or so months. I am both a developer and supporting a large implementation with 4-5 custom distributions on top supported by different teams
That is why there is Legacy UI, GSPs, OWAs, now micro-frontends… The legacy UI will not die until all the functionality has been moved elsewhere which will not happen in this lifetime.
IMO the 2 distributions - 3.x Reference Application & 3.x Microfront-ends should be first class citizens at the same level receiving the same amount of love resources
The more things change the more they remain the same
@ssmusoke the idea would be that at some point in the future the current master branch becomes 2.x and the 3.x branch becomes the new master.
I guess what I am trying to say is that there is no “3.x Reference Application & 3.x Microfront-ends”, there is
OpenMRS 3.0 (on master)
OpenMRS Ref App 2.x (on 2.x)
What I was suggesting is that from a certain point (maybe 2.13) this Ref App 2.x would have 3.0 features backported to it under the hybrid model setup. That means microfrontends served through the SPA module, and the distro still running through the current deployment architecture supported by the SDK… etc.
The kind of LTS that will exist for this 2.x branch is a very important question to tackle and this conversation needs to happen indeed. Cc @burke