The model

We’ve rebuilt Open mSupply from the ground up. Here were our design goals:

• Offline first – local database to store changes when the internet is down, and a background process that clears a queue of pending synchronisation tasks when internet is restored.
• It needs to synchronise with existing mSupply systems.
• High performance – our calculations are that a country like Nigeria with 400M people in a few decades could be sending 15 or 20 million synchronisation records per day – we need to build a system that will keep up.
• Single code base – our software needs to work on all platforms. We maintained separate mobile and desktop code bases in the past, and it was painful.
• Highly reliable – our software is often used in small clinics where remote support is hard to come by. Also, a system designed for hundreds of thousands of devices needs to have minimal bugs.

Overall design

• A web server written in Rust that runs on all platforms
• A GraphQL API
• A front end written in TS/React
• We use Electron to create a desktop app that bundles the back end server and the front end in a single app. This app by default connects to its own web server, but also connects to any other web server, creating an out-of-the-box multi user system. We have DNS discovery to find other Open mSupply servers on the LAN. No need to know IP addresses.

Back end

Why Rust? This question is answered all over the internet, so we don’t need to go into it here. Some things that are features that aren’t mentioned so much in other places (where they talk about memory safety, etc…):

• Rust has fantastic support for different compile targets. That’s why our single app can run on Android or on a big *nix/Windows/Mac server.
• We care about minimal energy use – with our aim of running on > 100,000 devices, saving 1 watt would save 100 Kw across all devices- that’s worth some effort!
• Being cross-platform means we’ve had to support both SQLite for Android and Postgres for large installations. To do that we’ve used the Diesel crate. Diesel is a bit of a beast, but it is also a very good piece of software.
• Yes, Rust is slow to compile. A lot is asked of the compiler, and it takes time. It does also give a lot back in fast, reliable software, and great compiler messages when you’ve made a mistake.

Front end

• We had considerable experience with React, and decided to stick with it.
• Using Typescript and GraphQL.
• We use Storybook for our design library.
• We’re fully internationalised, using Weblate to make it easy for external translators to update a language.