We love to hear how open source technologies that NearFormers have authored, contributed to or help maintain, are being used in live environments. Here Maksim Sinik talks to us about HospitalRun, the open-access platform that aims to provide the most modern hospital information system to the less-resourced environments. We hear about the challenges in building a high-performing offline-first application, how a change in tech stack will make HospitalRun future-proof and attract more new contributors and why Fastify was selected as the framework of choice.
Before we delve into the technology choices, can you tell us a bit about HospitalRun and why was it formed?
HospitalRun is an open-source Hospital Information System, built and driven by the community for the community. The initial idea was born in 2012, when one of the original project founders, Joel Worrall, went to Kenya thanks to CURE. He found that one of the local hospitals managed by CURE, treating children with surgically correctable conditions, was still relying mostly on paper patient records. This was a big issue because records were lost and prone to error.
After some discussion with CURE and assessment of needs in the setting of developing countries, HospitalRun was born.
When did you first hear about HospitalRun?
In June 2019, I decided to spend more time contributing to open-source. In the past, I used to contribute to several projects, but they were all libraries and tools for developers. This time I really wanted to find a software project that will be used by final users. I took a look on the OpenJS foundation site and I found HospitalRun. I went on https://hospitalrun.io and start reading about it. After some blog post, I read a post from Joel where he was desperately searching for a new maintainer. Fast forward some weeks (and several chats with Joel) and I was taking over the project!
What made you want to get involved?
First, I was caught by the humanitarian aspect of HospitalRun. I was born in Sarajevo, my parents were both working as doctors during the war in the Balcans. As a child, I experienced war and bombing, so I feel it has something to do with my personal story about helping people living and working in hard conditions. With some of my best friends, I founded a startup, called Nucleode, that operates in the biomedical field to pursue this objective. The mission of HospitalRun is unique and amazing: providing the chance for developing countries to use a software that can help people saving lives.
The second reason is more about me being a technical guy: HospitalRun has several technical challenges that are both hard to approach and nail. Indeed, the ONG often operate in difficult conditions, with no power supply nor internet connection and therefore the application has to be offline first, robust in handling data and smart when it comes to resolving conflicts.
What is your role in the project?
Today I am the lead maintainer of the project. My role is to give a direction to HospitalRun and to lead the development of the application. My daily routine includes deciding and discussing the roadmap with other contributors, helping newcomers, trying to involve more contributors and reviewing pull requests that come to our repositories. Furthermore, I write code myself, focusing on the core parts that need to be stable and battle proof: since there are many moving parts, across several projects and repositories, I must ensure that all of them plays well together. Said that the role of the lead maintainer is more about people than about code and what I really like is that it allows me to meet amazing people from all around the world.
What have been the challenges to date? How are they/can they be overcome?
The first time I encountered HospitalRun, it was on stale for almost a year and a half. The software, even if it is in beta version, is quite stable and there were already some hospitals that were using it in production. One of the first big problems was to try mapping all the deployments since the beta version hasn’t any tracking capabilities. There were many users asking for help and it was difficult to figure out even what kind of deploy they did in the first instance.
Another big challenge was rebuilding the developer’s community: many, if not all, of the old developers, stopped contributing since they saw the project was almost abandoned. The technology and frameworks were ageing and it was hard for the newcomers to just pick an issue and start working on it.
Joel and I decided to do one of the most hated things in the Open Source world: restart from the foundations. We decided to drop Ember.js in favour of React and to use Fastify in place of Express. After the first few weeks, where some members of the community felt betrayed, things started to work again: there were many developers who reached out to me just to say that they were happy about the decision because, for them, the major point of friction in contributing to the project was the fact they didn’t know the old tech stack.
What are the key improvements you want to make?
I’ve spent my first three weeks of being the lead maintainer in reading all of the GitHub issues, documents, posts and chats on slack. I needed this time just to ensure that we are not going to repeat the same mistakes that had already been done in the past. Now I am sure that HospitalRun will be rewritten ground up using 5 years of knowledge and avoiding the major points of pain that the old maintainers faced up. Since the application has to be offline first, many of the ideas and architectural decisions made for the 1.0.0-beta version will be ported over to the new one. Since the UX was already very mature and one of the best of all open-source Hospital Information Systems, we will try to maintain it and to refresh the UI. Moreover, we will also keep using CouchDB to allow our users to use the software even if there is no internet connection.
We will focus our attention to the on-premise deployments, to make them as frictionless as possible. It is important for us to be sure that almost everyone can deploy a self-hosted instance with very few external dependencies.
Is Performance a key driver given your focus on usability?
HospitalRun is offline-first application. We need to provide constant concurrent, conflict-free and fast bidirectional updates. What this means, in practice, is that the server can be stressed with many simultaneous requests, most of the time because several clients come back online together. During this specific phase, it is the only moment where clients show loading bars, therefore it is important to respond to all connections as fast as possible.
What tech stack choices have you made and why?
Since HospitalRun exists for more than 4 years now, Joel and I agreed that this new beginning was the perfect time to introduce new tech stack.
We set 2 major goals: 1. attract more new contributors (hoping that old ones would start contributing again); 2. make HospitalRun future proof. We decided to reconfirm CouchDB as primary sync and storage DB, but we changed both frontend and backend frameworks. React was the most obvious choice for the FE: we are going to build huge software and we will benefit from the modularity of React components.
On the other hand, the BE choice was harder. Personally, I think that Fastify is the most future proof Node.js framework out there right now. It is built ground up for the modularity and performance: I hardly pushed to use it and getting some feedback from the community I know that are all happy.
Regarding Fastify in particular, what will it enable Hospitalrun to do that other frameworks may not?
Choosing Fastify for the new version of HospitalRun was one of the easiest decisions I’ve made. Building an upgradable, maintainable and swappable system is the most challenging part when building such a big application as HospitalRun.
In my opinion, Fastify has, by far, the best plugin system out there, that allows us to replace, improve and extract as a standalone application, parts of our code-base, with no effort at all.
What are the top 3 benefits of Fastify in your opinion?
First of all the plugin system. The underlying mechanism, called “avvio”, is a game-changer: everything in Fastify is a plugin (that could be loaded also asynchronously), that is isolated from the rest of the system by default. This allows the developers to register a plugin and to be sure that it is not going to interfere with other parts of the software.
Secondly, Fastify encourages the use of JSONSchemas to describe queries and payloads inside routes. This alone makes validation and serialization a lot easier, preventing bad input being passed all the way down to the database. As a side benefit, if declared, the JSONScehma speeds up serialization (one of the slowest tasks that run on the servers) thanks to fast-json-stringify that uses the provided schema as a blueprint and therefore already knows to props to serialize.
The third benefit is surely the developer experience. The framework is stable, powerful and driven by enlightened maintainers who have a clear vision of not just the future of Fastify, but also of the development as a whole. From writing code to interacting with the community, every second spent working using Fastify is a pure pleasure.
As one more and final benefit, I am going to cite the framework speed: thanks to his internals it is blazing fast!!!
Have you used Fastify in other previous applications?
Absolutely, I use Fastify in production since version 0.36.0. At that time it was already very stable, but some breaking changes happened, so the team didn’t bump up the version for a while. Since that moment, I do my best to give feedback to the maintainers and to contribute to the project myself, as much as I can.
Today, since I am the CTO and Principal Architect of two different companies I can choose tools and frameworks on my own. This freedom allows me to use Fastify as the core of all of my client-server projects.
For others considering Fastify as a web framework, what would be your advice?
The best advice I can give is to forget what you learned using Express and other express-based frameworks. Even if Fastify technically allows you to use directly several Express middleware and recycle concepts and patterns, there is a better way for getting your job done. I call it “the Fastify way”! The best way to approach Fastify is by learning its plugin system. After that these initial concepts are learnt, rethink your approach to the APIs development. Fastify may not be so easy to learn, but it is very easy to master: don’t stick to your own preconceptions and let the Fastify’s way flow inside yourself!
As an Open Source project, how are you promoting HospitalRun in order to attract contributors/maintainers?
Open-source projects are all about people and community. My primary goal is to make people comfortable in contributing to HospitalRun. We have strong rules and code of conduct to ensure that no one could feel bad or threatened by any means. Speaking of code, we’ve just finished our monorepo setup. Our idea is to let contributors focus on issue and roadmap, without the fear that any of their commits can ever break something. Soon we will do a “call for developers and contributors” and we hope that we will be able to communicate our values in order to get involved more people into the project.
In addition to that, in order to accept new core-team members, soon we will publish the steps needed to join the team: maximum transparency is the way I want this community to be.
Maksim Sinik is a software architect, conference speaker, CTO & Startup Founder. Maksim strongly believes that the next significant evolution for healthcare lies in technology. He is an Open Source software enthusiast and therefore he is the lead maintainer and software engineer at HospitalRun, an open-access platform that offers free downloadable software for hospital management with the aim of providing the most modern hospital information system to the less-resourced environments.
If you have an experience of open source technologies you’d like to share, let us know and we’ll help tell your story with the Open Source community via our blog and social media so that we can continue to learn from one another.