With the Product Committee moving forward on an OpenLMIS Mobile app, it’s time we start evaluating (again - see 2018) the tech stack that we would want to deliver with.
In addition to the community principles, there are a few architecture considerations I propose we highlight:
- We need to sustain it - our web UI is at present a bit north of 35k LOC, much of it on the soon to be unsupported 1.x line of AngularJS. This includes our time to make it work of course, and our time to keep it updated and performant.
- We will surely need an OpenLMIS branded demo version, though it will also surely end-up as a white-label application also. We’ll need to plan for this, just as we have with the reference UI.
- It will surely need to support mobile interaction (more limited screen size, touch, etc), as well as hardware. Using the camera to scan barcodes will certainly be a need at some point, for example.
- It needs to be deployable when there is only OpenLMIS, and where the implementation’s deployment toolbox is wider than just supply chain. Or put another way, it’ll be asked to participate in “health” sorts of things, in addition to LMIS sorts of things. An example would be collecting health programmatic metrics (e.g. how many kids were immunized today/week/month), or enabling community health worker processes, while also performing supply chain workflows.
As usual that’ll be balancing act we need to carry out, just as we’ve done for the rest of the v3 architecture with a small team. i.e. enabling the wider community to do more without forking, and being mindful of YAGNI.
To this end there are a couple enabling technologies I think we should evaluate, before we get started:
Community Health Toolkit - core
- Core project based off of PouchDb, Angular and NgRx, similar to our current stack.
- Could help us deliver with a smaller team, white-label and OpenLMIS branded versions, and provide a space for other teams to add workflows that aren’t LMIS. Also has potential to expand into SMS oriented workflows (e.g. tracer product inventory), and similar to our own stack has RapidPro integration.
- We’ve discussed this one extensively a few years ago, and it was seen then as: to be useful, we should migrate away from Angular, to React, maybe using a bridge library like react, and along with that leverage ReactNative.
- While we have people with experience in React/ReactNative, OpenLMIS to my knowledge hasn’t made any progress with the Angular to React bridges.
- XForms and ODK
- We’ve had past discussions on this quite extensively. Supporting XForms gives us a certain flexibility to allow other teams to build in other data collection needs - programmatic health data.
- Recent ODK versions have even built-in capabilities for edit/review workflows, which aren’t too far off off from a Physical Inventory or Requisition type document.
- Community Health Toolkit above is built in a similar vain here with XForms, Enketo, etc.
We’d like this to culminate in a Technical Committee call in the next 1-2 weeks where we make an initial decision on what Tech Stack to start with. How can the team support this evaluation? And does anyone feel strongly about adding more to what we evaluate?