Extracting bahmni common code base as NPM library

Tags: #<Tag:0x00007fe2e29c1928>

Hi All,

In a recent post(Appointment Scheduling Refactoring to React), we started talking about extracting the appointment module and moving it to react. As of now, there is some common code in UI/app/common which is used by all the modules (e.g. Patient Model, Common services like patient search).

As suggested in the same thread by @snehabagri we would like to extract this common code to an NPM Module called bahmni-commons-ng. This NPM module will have each bahmni-common-module as an ESM in its own js file (e.g bahmni-patient-commons.js, bahmni-auth-commons.js, bahmni-i18n-commons.js).

We want to start small, so we are thinking of extracting just the pieces which are used by the appointments module.

EDIT: As part of this we are planning to make appointments module compatible with OpenMRS distribution (Independent of Bahmni specific modules).

Let us know your views and opinions. @angshuonline @mksrom @binduak @sravya

CC: @rrameshbtech @mksd @sukreet @premnisha

3 Likes

What would bahmni-auth-commons.js do? How does it differ from what would be needed by other distributions that are not Bahmni?

Hello @mksd,

The idea is to take these pieces out and use it in Appointment(The new one being carved out) and in Bahmni. So the bahmni-auth-commons.js is just bahmniapps/ui/app/common/authentication folder carved out as an ESM and bundled by webpack.

Another use-case we are looking at is to be able to run the new appointment without Bahmni Ecosystem (mainly bahmni-core). Later we would make changes to just this module to make it independent of Bahmni authentication.

Breaking down Bahmni Core is clearly one necessary background work and I more than welcome moving this forward.

I was wondering what this “common auth” would do exactly, and whether you could already there benefit and share from what has been done by the MF Squad.

I don’t think we can do the authentication similar to MF Squad yet. There is a lot of code Specific to Bahmni like(specific cookies) which needs to be addressed. We want to make it work in a non-bahmni environment while not breaking its compatibility with Bahmni. The first step towards that we are taking is to extract the common pieces out.

1 Like

In the PAT call yesterday(18th Sept), we discussed this topic. Below is the technical approach diagram presented in the call.

The first block in the above picture shows the Bahmni As-is having Bahmni-Core and Appointments-OMOD as server-side modules and BahmniApps as a huge UI app. BahmniApps consists of many small apps(Registration, Clinical, Appointments etc) and there is some common code which is shared by all the modules.

The second block shows the state after the first step taken as mentioned here(Appointment Scheduling Refactoring to React). The appointment module will be taken out along with the common code to improve the technology and redesign of UI. On the server-side it will still have Bahmni Core and Appointments-OMOD.

The third block shows the state, once we are able to run the appointments module independent of Bahmni(BahmniCore Omod) on a plain OpenMRS Distro. We will extract the bahmni ui common code in a separate repo and publish this to NPM as a library. The appointment module taken out in the second step will leverage this library. The appointment module itself can be another library, so it can be reused in Bahmni Ecosystem(E.g. By requiring in an app) & OpenMRS Ecosystem(E.g. By wrapping it in an OWA).

In the last state, we will also try to make the Appointments App completely independent of Bahmni-Core OMOD. If the appointment app is using any APIs from the Bahmni-Core, those will be migrated to an OpenMRS Repo Or A Bahmni-Common-Omod wherever those APIs fit.

Above is the summary of the technical approach, we discussed in the call. For other details please check out the notes from the call.

Thank You

Hello People,

We have started working on extracting the common modules and We wanted to know the versioning mechanism for a library like this. Should it be something like 0.0.1 as it is not coupled with a specific bahmni-release or should we keep it as 0.93?

Let us know your thoughts.

1 Like

There is no specific need to align with Bahmni release numbering … IMO, you can use a versioning starting from what you suggested. Lots of versioning schemes designate 0.x as alpha/beta.

What important for me is having the versioning consistency lets say … you use major.minor[.build[.revision]]

  • when will decide - its a major/minor/build version upgrade?
1 Like

Thanks @angshuonline for clarification. We can go ahead with 0.0.1. To start with we are planning to publish it with beta versions until we have tested it out.

To answer the question of when we will decide if it’s a major/minor/build:

Major Version Upgrades

  • In case we upgrade on of our major dependencies (e.g. Angular, jQuery).
  • In case, there are contract/architectural changes in APIs. E.g. Change in the contract of encounter creation, Moving modules for refactoring, separation of concerns
  • One last reason could be the addition of a major module. E.g. If we extract the dashboard display-control. To start consuming dashboard, One needs to make a major version upgrade.

Minor Version Upgrades

  • Addition of functionalities to existing modules.
  • Small module extraction.
  • Smaller refactoring

Patch/Build Version Upgrades

  • Small changes and Bug Fixes

These are some initial thoughts, we are open to any suggestions/feedback.

1 Like

Here are some updates on the work we have been doing:

  • We have pulled the bahmni-ui-common code in a different repository . We have created pipelines for these in bahmni-ci and the library is getting published on NPM.
  • We have extracted the appointments module in a different repository. As of now on a branch we have migrated it to use webpack and use bahmni-commons-ng library from NPM.

We started testing out the new appointments module on barebone OpenMRS to find out possible problems in integrations. These have been out findings as of now:

  • The bahmni appointment app expects certain cookies to be set after bahmni login. Since we will be bypassing bahmni login, we will have to populate these cookies on initialization of the app. Card for this.

  • There are certain APIs defined in Bahmnicore, which are being used by the appointments module. Since we don’t want to deploy bahmni-core omod, we will take these APIs in a common module, opnemrs-module-bahmnicommons. Card for this.

  • We had to remove the openmrs appointment scheduling module because there were few conflicts with the bahmni appointments module. This leads to OpenMRS not being able to start “Reference Metadata Module, Reference Demo Data Module & Chart Search Module”. We need to figure out if it will be possible to replace the existing appointments module with the new one (Extracted from Bahmni).