Not long ago we kickstarted the conversation of moving Bahmni codebase from AngularJS to React. While React is a decent choice to keep it modern and attract more contributions, but at the same time it is “yet another framework” and at some point it will suffer a deprecation (just like AngularJS); perhaps there’s simply no long term strategy for frontend frameworks as of now, “unfortunately”. Our initial thoughts were to make the overall rewrite framework agnostic - while still using React i.e.
Slice the UI into cleanly componentize microfrontends (React)
Put the components in a custom element for composition in the page (Web Componenets)
Create a layer that works with import maps similarily as webpack works with module federation (Pure JS and HTML)
This will limit the blast zone, and allow more independent rewrites of critical components in the future, rather then having to rewrite the application as a whole again.
We also evaluated the amazing OpenMRS 3.0 MF work that happened in past few years and seems it went though similar journey. So instead of duplicating the efforts and (future) problems, our proposal for Bahmni would be to piggiback on overall decisions and frameworks used for OpenMRS 3.0 MF and extend features on top it.
I would also be against rewriting any component of bahmni from Angular to React. I would rather concentrate on bahmni’s contributing to the OpenMRS 3 architecture to make it as flexible as it can, to accomodate components, not written in react, but that have been comfortably used in production, for years. After all, when i proposed the Micro Frontends Architecture to OpenMRS, one of my arguments was that we need an architecture which accommodates the investments already made by different groups in various technologies. Of course am not saying that we should just mix languages because the architecture allows us to, but simply accomodate them, when we find ourselves in such situations.
Firstly, I don’t think the focus here @mksd is to Reactify the code to make it look current/modern. Neither the current code state is ugly that it could be solved with just refactoring to make it read better. The rationale for slicing was to uplift the overall fronted architecture and technically speaking - just pure slicing of current codebase for MF is possible but I wouldn’t underestimate the efforts and I would challenge on the value it would provide as-is with current stack?
While Joel Spolksy 20 years old essay is still fair to indicate that “Rewriting the code to keep the same functionality is the worst strategic mistake that an organization can make” - But at the same time there are situations where attempting an incremental rewrite is comparatively a better approach. Here are few important question (which are inter-related) that would justify a rewrite and should eventually pay off for software that is planned to be maintained for dozens of years like Bahmni…
Is the original technology unsupported?
Is the capability rapidly diminishing in the industry?
Is the original technology choice preventing you or constraining you from making improvements?
With no emotions attached to React, for me is just one of the current mainstream frontend frameworks with a larger community and perhaps its more of piggybacking OpenMRS to have consistency for contributors. One of the thought was to make Bahmni completely framework independent e.g. using a web standard like web components, however to use it productively we might still need to use a framework - hence, have the same issues. And no-matter whatever we use now, we may land-up in the same situation as you rightly called out @dkayiwa, i.e. the current mainstream would suffer depreciation sooner than we can estimate.
This is where want to take the opprotunity to rethink about Bahmni frontend and decouple the overall architecture with the value proposition of
Uplift the user experience of Bahmni as we rewrite
Cleanly componentize UI so that we can deal with obsoleting frontend frameworks more gracefully and incrementally
Reuse OpenMRS 3.0 Frontend and not reinvent the square wheel to duplicate future problems
Lastly I would argue on having too may frontend stack to be supported @dkayiwa. Perhaps micro frontend anarchy would be a maintenance disasters if there aren’t any plans for standardization and consistent approaches. I know @dkayiwa you intent was more towards wrapping currently invested codebase to be used in the new Architecture - I just wanted to call out the future consequences.
These are some of the great pointers for us to discuss in the PAT call tomorrow.
Hi @n0man,
Thanks so much for your review & demo on the PAT call today. It’s clear you’ve put a lot of thought into this and you’ve really taken the time to review the existing 3.x frontend infrastructure. It was really exciting to see this as well as the prototype you set up!
I have 3 follow-up questions to clarify:
What does “uplift the UX of Bahmni” mean? The notes from the PAT call say “New UI of Bahmni will use OMRS 3.0” - does this mean that Bahmni would adopt the same UX & Carbon Design System that OMRS is using? (Sorry to be dense here, just wanted to confirm )
At the risk of sounding blunt or downright oblivious… I was under the impression that Bahmni-core created substantial barriers to adopting the 3.x architecture. So I thought that substantial re-work of Bahmni/Bahmni-core was needed before 3.x was even an option for the Bahmni platform. I guess this is not the case?
Any thoughts on the first functional or feature areas you’d want to tackle using the 3.x framework? (E.g. I know of several orgs who hoped to leverage Bahmni Appointments along with 3.x but they ran into some roadblocks that I think could be dealt with if we joined forces.) Maybe it’s too early to really talk about this yet. Just curious.
Thanks so much. Looking forward to further discussions on this!
(cc @angshuonline@gsluthra)
I think this is a different issue, one could certainly use our frontend framework and Bahmni Core. It’s just that for Bahmni most or all ESMs would state that Bahmni Core is a required backend dependency, thereby making them unlikely to ever be used on “the OpenMRS side” (so to say); and that’s because in O3 the stance is FHIR first + backend as thin as possible.
@grace yes, eventually we would require assimilation on the backend side, but as @mksd mentioned to leverage frontend f/w, its not mandatory.
I think in a meeting with @ibacher we talked (and demistified) about Bahmni core backend module - reasoning and needs. If you remember, we also discussed about us thinking
about a coarser gained API containing fhir payloads, that aren’t so granular and at broader clinical record level (for example here - that would potentially be a replacement for Bahmni’s abstraction over EMR API
We also talked about standardizing API for terminology definitions over FHIR and potentially OMRS serving as TS
I had also talked about need for FHIR IG to assist the ecosystem
Also about need to broaden OMRS model as its seriously lacking any comprehensive FHIR model mapping and support for client systems (I do not believe that one size fits all, and more in favor for context appropriate apps)
Now IMHO, all of them are needed (and alignment amongst broader groups) to effectively move together and collaborate on shared/re-usable features/functions, forming consensus (if not anything but on principles). Whether we can tackle all of them, I have no clue, but we are happy to try!
I would even settle to use OMRS or Bahmni REST APIs to start with, while we figure out a path to “perfect-ness” - if each component clearly says out dependencies and if these dependencies are manageable enough - its still a win. Eventually birds of same feather will flock together
Sorry I missed the meeting about this. I don’t check Talk often and so just saw this thread. Glad we got to talk about it at the conference. This is a really exciting project and I hope we can find synergistic approaches.
)