Mobile tech stack

Hi all,

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  • ReactNative
    • 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?



I think we should also consider PWA (Progressive Web Apps). Progressive Web Apps are web apps that use web browser APIs and features along with traditional progressive enhancement strategy to bring a native app-like user experience to cross-platform web applications.
You can read more about it here: PWA vs Native App: Which Suits You Better? - SimiCart

Best Regards,

Thanks @pmuchowski , the installation w/ avoiding the app store could be really handy for an implementer and end-users (e.g. complicated store relationships, changing requirements, user account management w/ ministry). The current hardware access is a bit concerning - especially on the bluetooth side if we want to use external barcode scanners (workaround: keyboard emulation - HID) and/or bluetooth printers for barcode/qr code printing (can a PWA print through the OS?) though.

I looked into this and it should work with the Bluetooth LE devices (BLE). Here you can see the current status web-bluetooth/ at main · WebBluetoothCG/web-bluetooth · GitHub
Also here are a few examples of apps using PWA 12 Best Examples of Progressive Web Apps (PWAs) in 2021

Thank you again everyone for participating on today’s Technical Committee call (notes).

We didn’t have time to discuss everything we’d like to have, and that’s okay - we’ll pick up the topic again on another call in the next week or two.

First I think we should learn more: on the call there was a fair amount of interest on a Progressive Web App - a hybrid approach. Avoiding the app store and leveraging the same code for dual use between the desktop web and the mobile were both attractive. Hardware support and building a good mobile experience gave us concern. Overall we’ll need to answer the question: with this technology, can we deliver within a release cycle (~ 3 months / 12 sprints).

With that in mind I’d propose that our next step is to run a design sprint: the purpose of which is help us answer some of our questions, and to help us make mistakes early that we can throw away (meaning at the end of the sprint our goal is to have knowledge, not code that’s on a path toward being released).

Here are some areas I think we should focus on in that design sprint (hopefully we can do these in parallel):

  1. Can a PWA app support the sort of human interactions that work well on mobile, while also simultaneously supporting those that work well on desktops.
    • An example in physical inventory is the table data entry, which works well for desktop web with olmis, but horribly for mobile. Instead on mobile we’d need some quick way for a user to find the product they’re looking for, then the lot/expiration, enter current stock on hand, and then move into the reason for discrepancy from listed SoH. It’ll need to give the user feedback on how far along they are and what’s missing. All with a finger on a smaller phone style screen.
    • The output is stand-alone or throw-away code that’s based on physical inventory (or part of), that shows how we’d have different interaction styles (table entry on desktop vs mobile entry). This is something we can demo and showcase locally.
  2. How can we segment out the existing UI scaffolding, so that we can piecemeal upgrade/change specific areas.
    • e.g. if we only wanted to upgrade the stock management functionality, or even better, could we zero-in on the physical inventory piece.
    • Output here is throwaway code, built using the reference UI (or part of it). It must show how it can be done so that it can serve as a guide for production-level code to come w/ testing, it should help us enumerate the pieces so that we can better give estimates for the release cycle, and it’d be nice if it could get all the way to the CI/CD process (i.e. built and show on something other than a local dev box).
  3. Mock out and update our UI styleguide so that we have mobile-first interactions defined for every desktop web pattern we have in and around physical inventory (i.e. around is the journey to it, such as login and menu navigation).
    • Output here is ideally not throwaway, and may take longer than this sprint to complete. If we can start this now, it’ll help us move faster later. It should be a proposed update to the UI styleguide for interactions found in and around the Physical Inventory. Should be showcase-able and ready to be presented for approval with Product Committee.
  4. Can we use the hardware: camera for barcode, bluetooth for external barcode scanner, bluetooth for printer, cold-chain type interfaces. We can do this more with product and roadmap research rather than code.
    • Output here is an analysis document that ends in a recommendation and/or risk analysis of what’s available, how common it is, current constraints and likely future direction (e.g. Bluetooth profiles, if known)

#1 and #2 involve code, and I hope they could proceed in parallel without blocking one another, same with #3 and #4. One aspect here we haven’t decided is: what specific framework to start with, as a PWA is more a style. I presume that #1 and #2 would both choose AngularJS here, as it’s what we have already, however if someone feels strongly about another and has a strong argument that another could be adopted by the team to deliver within a release cycle is welcome to put that forth as well. I did also look at Blazor as was brought up in the call, and it looks great, but I’m presuming our current team doesn’t have any .NET experience, and that’d give the team additional pause. Is that right?

I’d propose this for the next sprint cycle, if possible, so that we can gain this knowledge before making a committee decision.



I think it’s a good idea to run a design sprint, after that we should be able to estimate how much time it will take to implement the PWA.

  1. It’s possible to make the app look good on both desktops and mobile, it’s part of responsive web design. We can display the tables (or any other components) differently depending on the device screen size or even the entire page layout can be changed.
    This will require many changes in the current application, so I think it will be good to rewrite it to React (or some other framework) as part of this.
    Also I don’t think it will take more time than creating standalone mobile application in ReactNative.
  2. It is possible to run AngularJs in the React application, so we should be able to rewrite only parts of the application (e.g. one module). We can hide some parts of the application on mobile, e.g. the modules that still use AngularJs.
  3. If we decide to rewrite part of the application to React, should there be a separate styleguide for React?
  4. There should be no issue with accessing the camera, also all Bluetooth devices that supports BLE (Bluetooth Low Energy) standard should work fine. Do we have some list of devices that should be supported (models, what Bluetooth standard they are using)?
1 Like

I’ll just clarify - with 3 months, we are talking about 6 sprints, not 12.

Does starting the work with AngularJS PWA has any implications for the future?
Is there any additional work we need to do in the AngularJS code to make PWA work?
If we have PWA working with AngularJS, does it make it more complicated to migrate to another framework, such as React, in the future (compared to migrating without PWA)?


I second that. Definitely worth learning more before we make a definitive decision, and perhaps this will help us estimate better. Overall, no matter which way we go, I worry that 3 months (now 2.5 months with the design sprint) could be too tight. We will likely know more when we dive in though.

Best regards,

To make the PWA work we will need to migrate from Grunt to Webpack. We can use it with AngularJs, but it will require a lot of work to make it responsive (and look good on mobile devices).
If we decide to do the migration to React later it will be easier, because part of it will already be done (migration to Webpack).
I think we should do the migration to React now, because it’s easier to implement a responsive UI in React and it will take less time to the the migration right now and redesigning the UI in the process, than making the AngularJs responsive and doing the migration later.
There is one more thing we need to consider, if we decide to use PWA and do the migration to React it will be quite easy to reuse the React code when implementing the standalone mobile app in ReactNative in case the bluetooth devices will not work correctly (e.g. the external barcode scanners).

Best Regards,

Agreed - do we know when we can start the design sprint?

Hi @joshzamor

The sprint has started today and ends on June, 16. Book your calendar for the sprint showcase meeting! You can view the scope of the sprint here:
The sprint goal is to answer the question of whether the PWA+React mobile approach is satisfying for us. This covers most of the points raised in this topic, with exception of styleguide and preparing mobile-first components. We scheduled research on hardware support, but it’s marked as low-priority.

At the same time, our devs will start topics here for their research findings where relevant.

Best regards,

1 Like

Thanks @Sebastian_Brudzinski and @pmuchowski.

I just sent out an tech committee invite for the Tuesday after the sprint end, so that we can review what’s been learned and hopefully make a decision. Does that time work? Will you be able to prepare to present what you’ve learned? Ideally we should have a draft design document(s) (let me know if you’d like a template) and you’ll have time to walk the group through it.

Looking forward to seeing how this works - please do remember that our priority now is to get it working enough for a piece of Stock Mgmt for the next release. I’m wary about tackling too big a challenge in that timeframe if this would be a rewrite, so when presenting please keep that in mind. Both I and the developers to follow will need good guidance on how this can be achieved if that’s going to be the proposal.

Great! And we can put off the design/styleguide elements for a sprint - I think that’s okay. In terms of the hardware support research I could help with some of that as I’ve done some of the standards research already. I’ll followup here with some links and notes later this week.

I am attaching a link to the document we discussed at the technical committee

Best Regards,

1 Like

Thanks for posting the design doc @Aleksandra_Soltys , and kudos to the team for all the new knowledge they’ve added.

After today’s call, I think I’d summarize where we are as:

  1. We’ve learned a fair amount of what we set out to learn 2 weeks ago, and even done a high-level initial estimate.
  2. We’ve shown that the PWA approach, using React and others, should be feasible with this team in the given timeline with a team of 2 or more.
  3. We didn’t fully achieve the goal for #2 - we have a lot of research but we haven’t gotten our hands dirty with a throwaway code-base. That’s a risk for our knowledge and our estimate. I’d recommend that we treat the current line items regarding #2 of the estimate carefully, until we can get a sprint in with writing some code. If we start with this approach, I’d recommend we start in this area first, to uncover hidden risk.
  4. There is an interest in mitigating our delivery date risk (time to market), with an approach we didn’t fully explore in this past design sprint, at the cost of more investment over time. This approach is to rewrite and duplicate the current functionality, so that we have more of a greenfield React project, that is separate from our current Angular code-base.

There is understandably a desire to pick a path and get moving, and to that end we’ve scheduled another call for this Thursday (6/26).

There are some possible next steps/decisions I’d recommend we focus on:

  1. We could start the next sprint, taking what we learned in this last design sprint, and start building. I’d recommend we put more focus behind what wasn’t achieved as noted above, to uncover risk possibly hiding there, as noted above. Our current estimate would have us achieving our goal with a team of at least 2, with about a sprint to spare. There’s very loose math involved in that, but it’s good enough to make me think it is a bit tight.
    • Main pro is that we get started right away, with a possible lower cost over time.
    • Main con is that we’re going down a path where we’re tightly fixing the scope side of the project management triangle.
  2. We could switch gears and explore the greenfield React approach outlined above. Since this wasn’t in our last design sprint, there are a number of things we don’t know that we should explore with another sprint just as we did in this last one: output is to uncover risk, and learn enough to build a design document. Doing that though costs us another sprint, at the end we would be down to ~ 4 sprints.
    • The main pro is that we can further mitigate our time to market risk by having more control over the scope of the project triangle.
    • The main con for this one, is that the cost over time is going to be higher.


Lets come prepared to discuss the decisions this Thursday (6/26). And congrats again to the team for this past design sprint. See you all there!


1 Like

Thank you for putting together this overview, Josh. I will not be able to join for all of the subsequent Tech Committee call tomorrow (6/24, not 6/26, right?) so I wanted to provide feedback here instead.

There are a couple of points that I think need discussed:

  • You mention that the PWA/React approach should be feasible but I am not sure how that has been determined, aside from the estimates that were shared in the last meeting. The current work plan seems very optimistic given the type of foundational additions and changes that this work will involve.
  • Point 4 of your summary is a little confusing. Are you saying that creating PWA-specific (for lack of a better term) pages is more work than adapting existing pages? I would expect that the opposite is true as there is a duplication of functionality regardless, either the current pages are adapted from Angular to React and updated to a responsive design or new pages are created using React that are dedicated to the PWA workflows. The latter seems less risky and easier to scope.
  • Lastly, I am still worried that we are drifting from the original goal for this project and will be putting a lot of time towards things that are needed at this time. Each time this concern is brought up I am told that this is not the right time for that discussion but if this isn’t the time then I am not sure when that time actually is. While I understand that the Tech Committee is responsible for determining the technical approach the product perspective needs to continue to be involved in that process. When can we have these discussions?

I second the kudos to the SolDevelo team for pulling all of this work together. Please do not think that my concerns about the direction we’re going is in any way a criticism of the work that the team has done!


1 Like

Hi @ibewes ,

Sorry, Thursday 6/24, right. Not Saturday 6/26. If anyone is missing the calendar invite (for 6/24) let me know.

You’re right this assessment of it being feasible is a summary based off the estimate which is what the team’s past design sprint gave as captured in the design doc. While the team accomplished most of the goals laid out, we didn’t get everything, so an initial estimate which was going to have implicit risk to it has some quantity more than we would have liked. I think we’ve identified this risk, and I’m proposing a mitigation effort by focusing on this area in our next sprint, learning from it, and refining our estimate as we go - following our agile process. Additionally we could also be more explicit about our milestones in the design doc, however we do have implied ones from the estimate breakdown the team has given so far. Making the milestones explicit should be the layout for the first epics and that’s a useful exercise to do, so I would recommend adding milestones for this next sprint.

Does that make sense? Do you have another recommendation?

Great question. I’m using the project management triangle model as a lens here. I’m summarizing that creating a separate greenfield React project increases cost over time (i.e. not the immediate cost lever in the model), while reducing scope and cost now, which favors our fixed time to market date. The increased cost over time comes from what happens after our end state (the short- and mid-term after the end of the mobile MVP project): we would have two copies of the same functionality split by form factor (mobile vs desktop web), we wouldn’t be addressing our aging Angular code base of which our version (1.6) has already passed EOL (the 1.x line EOL has been pushed back, but is also fast approaching) which is a factor that originally drew us to the PWA approach, and any feature addition, change, extension and release would need to be coordinated between these separate components. There’s a prospect that there would be an effort to combine the two into one in the longer term.

In other words, yes, the greenfield project is more likely to meet the release date (time lever), and also cost more in maintenance over time. A considerable risk to this is that we didn’t include this in our last design sprint, so we don’t have a design document for it, and there may be hidden complexity that our cursory interest hasn’t uncovered yet. e.g. a potentially tricky area is adding the routing to the separate front-end into the reverse proxy - that’s not in our architecture and accomplishing routing in this area the first time around was a challenge. A new design sprint would help uncover those risks and build a design document, however as noted we’d use up another of our few remaining sprints we have until our release date.

Sorry @ibewes that you’re not feeling heard, your feedback is valued and I want to hear it. Did I miss it at the first call or the first summary and design sprint layout? I do know I did ask us to put these larger questions on hold during the design sprint showcase last Thursday (6/16) and the design sprint technical committee review call yesterday (6/22), and my reason for that was to be sure we heard the team’s results of their design sprint, before opening up the larger topics. Next time we could coordinate the showcase and the technical committee review calls to reduce the number of calls. Would that help here?

The next call we have scheduled for these larger topics is the same Thursday (6/24). It’s aimed at making this decision - whether that’s we’re ready to invest in the approach laid out, invest in a revision to that approach, or hold and look at new approaches (e.g. a mobile native which we moved away from early on). So this would be the time to bring up these larger questions again. Since this time doesn’t work for you, I’m hearing that you’d like us to reschedule this? What about June 29th at the same time? I know the time-zones are a challenge here so if you would like this rescheduled and I don’t see it till tomorrow morning, we’ll use the time for a short call to schedule the next call.

Let me know how else I can improve this.


1 Like

Hi everyone,

we want to plan the work for upcoming weeks and it seems that after our last meeting on Thursday(6/24) we’re ready to start the work on mobile app. Can we add required tasks, build backlog and start working on it starting from the next sprint(this Thursday)? This backlog will be build based on estimated tasks added in this document.

Please let me know in case of any questions or concerns.


Hi @dbienkowska , apologies I meant to write a summary of our last call earlier. From that call, the consensus I would summarize as:

  1. We’re going to start with a greenfield PWA, to really maximize our best chance at meeting our time to market.
  2. We’re not going to put an emphasis early on making it reactive, even though we believe it’ll be easy. The purpose to this primarily 2-fold: 1) limit scope as in #1, and 2) we want to build /for/ mobile first, really be focused on that to deliver a good experience.
  3. We will need a new design document for this shift, though we want to get started building right away. The team thought this would OK.

Further I’d recommend we start creating milestones so that we can track our big-picture progress. A few we might start with:

  1. Add to the architecture the ability to run another web-server for the mobile PWA.
  2. Setup the mobile PWA dev environment, similar to how we have the current dev environment. It’ll need to have all the basics: onboard/use instructions, how to build/test/deploy, etc.
  3. Mockups for the functionality, laying groundwork for the mobile style guide.
  4. CI/CD pipeline. Output needs to be inline with current service architecture (i.e. dockerized).
  5. etc (team to build this out in design doc)

I’d recommend we try to start some/most of these first ones in parallel. Esp. the mockups + style guide should get going right away.

Hi @joshzamor,

I updated the design documentation ( taking into consideration the recommendations from the call.

Hi @joshzamor,

Although we are ready to start working on this mobile app project, we do not have any mockups which is a blocker for us. Who should be responsible for delivering them and when can we get them? If that is necessary, we can use ready-made solutions - I guess we’ve mentioned Material Design.

Please let me know your thoughts on this one.


Hi @dbienkowska , in the past and other projects we’ve recruited from within SolDevelo for a short time. Is that possible here?