This is the home of an open source version of the popular mSupply - providing pharmaceutical supply chain management and dispensing, all the way from national warehouses to remote clinics, on servers, laptops and mobile. Used in over 30 countries and for over 20 years and now becoming open source.

The code is separated into two main areas, the client and server:

Built on React - a responsive, multi-lingual, web based client, also packaged as both a desktop and android app.

For more information, read the client developer docs

Built to be fast and reliable using Rust and supporting either PostgreSQL or SQLite databases.

For more information, read the server developer docs

The client application is a web app, which is compiled and then hosted by the server. This can also be hosted externally by any web server, though this is no longer the recommended approach. The server connects to the database and provides a graphQL API which is consumed by the client app.

Users browse to the client app on the configured server port from a web browser, or the various wrappers which provide platform specific capabilities. This web app then connects to the server using graphQL in order to fetch data, and to the web server for app resources.

In diagrammatic form this looks like the image below:

There are also several ancilliary applications as noted, which are available to be run (cli applications) or hosted (storybook) separately.

We have some automations to build windows installers based on git tags. To create a build:

1. Update the package version in client/package.json appropriately and commit it. v1.0.4 example
2. Create a tag on your commit stating the version/build you're doing, but add v to the start. v1.0.4 example
3. Our Jenkins server will pickup this tag and start the build process against the repo for the tagged commit
4. A TMF staff member can download the generated executables from the Jenkins server and share them on the releases page.

For test builds feel welcome to just create the tag based off the current version of your base branch. For example a test build of develop might be v1.0.4-test1. Continue incrementing the test version as builds are done.

If you want to build your own branch, anything such as v1.0.4-PR123-t1 will work great.