Hi, this thread is a place to discuss the Technical Architecture for the project, tentatively titled OpenMRS Flow.
This continues the conversation from the original talk thread: An Amazing future for OpenMRS, based on the concept paper, discussed on Monday’s design call:
This document tracks the weekly Technical Architecture Questions
Question 1: As a technology, is the Community Health Toolkit the right foundation to build OpenMRS Flow upon? What are its strengths? limitations? and areas that require further clarification?
Working Document:
Message me to have your email added to the documents to be able to edit them
I think the most probable dealbreaker with CHT is the relationship between Couch, Pouch, Postgres, and the OpenMRS MySQL. It’s hard to imagine deep integration between them, at the level that we might call CHT a “front end” to OpenMRS.
At the same time, CHT’s ability to be offline easily is very motivating.
If CHT has a great deal to offer at the application layer, it might be worth writing an alternate logic layer that would hook it up to the OpenMRS API directly. Some clients could be API clients, some could be offline clients (that would sync to OpenMRS with Nifi or whatever). The benefit is that those clients could share configuration, e.g. forms.
I’d like to advocate building a framework-independent front-end data management layer. Redux would probably be the right choice for this. Whatever front-end components people write, in whatever language, would request the data from this data manager. It would request things from the server, use cached data when available, handle updates to data and serve as the one source of truth about data for the front-end application.
Having data management factored out will also dramatically reduce the extent to which we’re married to a particular framework. I think that React and Angular will live longer than the frameworks that came before them (Ember, Vue, etc), but if in 10 years or whatever our choice loses support, we’ll only have to rewrite display logic and UI.
This would be more complicated if we went with CHT, which would need to be refactored to use the data management layer. But then again, we wouldn’t be writing the application itself from scratch, so maybe it’s a wash.
Hi I liked the idea of a framework-independent front-end data management layer, these are some conceptual drawings from a few weeks ago about how data could go through such a layer, and be distributed to the multiple UX components.
I wonder how much of this may be handled by: GraphQL.org (@nkimaina’s suggestion)
GraphQL is an API technology. Using it would require writing a whole new OpenMRS API module that handles it, parallel the OpenMRS REST API module. I imagine there would be meaningful performance gains, but that building it would be a huge amount of work.
The data management layer is part of the front-end, which makes requests against whatever API, whether REST or GraphQL.
The CHT is currently in the process of a refactor that includes angular.js–>angular 7 and migrating to use redux for state management. I’m pasting two links that give a little more context on this refactor, and I’d be happy to introduce the developers working on this to schedule a call (or ask them to join the routine OpenMRS design calls) if you’d like to learn more? The refactor is ongoing, and if there are ways that this could be oriented to make it more useful to the OpenMRS community, that would be really cool for the CHT to hear about.
The CHT currently supports the distinction between online and offline users allowing the former to query the server CouchDB directly. This is used primarily when the user has access to too much data to replicate to the device. As you say the benefit is that both types of users have the same configuration.
Completing the bidirectional CouchDB OpenMRS integration on the server would allow for deep integration between the systems. The downside to this approach is having to store two copies of the same data. One upside is the CHT and OpenMRS are kept independent so they can be deployed together or separately as required.
Postgres is only used for analytics queries for which CouchDB is not well suited, and I think it’s likely that the OpenMRS MySQL database could be used instead.
While that integration would be awesome for organizations that use both CHT and OpenMRS, managing two different databases with redundant data seems like a less-than-ideal architecture for OpenMRS as its own application.
