Technology stack for Platforms serving field based users

We have been developing platforms for users who are do not work from an office. Currently there are two such platforms OpenCHS and Gunak. They are used by people on the move — hence the user platform is mobile/tablet based. Another important factor is that the users do not have good Internet connection all the time when they are supposed to use the platform.

In order to provide best user experience, the apps are developed as very rich and completely functional when not connected to the Internet. This has few important technical implications:

• Most of the functionality (its code) resides in the app and not on the server.
• The app depends on the on device database that has everything needed for the user — metadata, reference data and transaction data.
• Server is quite dumb because it doesn’t provide any functionality and is just the source/storage of the data.
• The load on the server is quite less compared to connected systems, since most user interactions are contained on the app.

Given the server is quite thin and load being less, we have chosen Java and Spring JPA. Spring Data REST helps in creating API by just defining interface methods like this — much less mapping boilerplate code to write. Stability and familiarity was other big factor. Any time spent learning some other stack but not getting tangible benefit would have been a waste.

For app development we have chosen React Native for the following reasons:

• Web style UI code (JSX) is much familiar paradigm for anyone to learn.
• The ability to instantly reload the app code (facilitated by external packager) provides significant advantage over pure Java based development for android .
• Code once and run on both iOS and Android works quite well with RN.
• And, potentially with Code Push (packager kind of approach), one doesn’t need to rollout a new version of binary to app/play store for minor changes.

We use ES6 and Redux. I love Redux actions + immutable view separation of React. It is way easy to reason about the code, than the approach of MVC or its cousins. Redux is not designed keeping in mind the idea of rich objects though. It strips off functions from ES6 classes when you pass them between view and actions.

Realm as an offline object database has worked fine. Realm needs better support for lazy loading, querying and aggregate functions etc. But it is still better than having to write all the SQL queries by hand with Sqlite.

We use PostgreSQL on the server side. JSONB and excellent in-built multi-tenancy support stands out as the reason for choosing Postgres.

On the reporting side — all the Big Data revolution hasn’t thrown up a lot of open source reporting and analytics platforms— that keep the cost of development down. In our context where one has different customers and multiple health programs people want to extract out data in many many ways. Writing all the data extract and their visualisation by hand is cost prohibitive. Remember that, these customers (Government, NGOs) do not have internal IT teams who can create these reports. Most tools that we came across, are designed keeping in mind having development teams and paying them money for data extraction and presentation. These are not generic platforms but a bunch of tools that requires developers ($$$). Another reason many tools are limited in their power is because they cannot understand the schema as they are based on schema-less databases.

For the rest of the world, things haven’t gotten much better than it was during JasperReports and Pentaho days. And both of these are creaking for their age. Metabase is an exception. Metabase on relational database works great because it interprets the database schema for you, without any configuration. Since it understands the schema it can do many repeated things automatically.

More on Postgres and Metabase for schema-less and multi-tenant platforms in later posts as they are large topics to cover.