Tech Stack Talks: Building HospitalRun the Fastify Way!

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.

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.

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 would be used by end users. I took a look on the OpenJS foundation site and I found HospitalRun. I went on https://hospitalrun.io and started reading about it.

After reading a few blog posts, I read a post from Joel talking about how he was desperately searching for a new maintainer .  Fast forward a few weeks (and several chats with Joel) and I took over the project!

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 Balkans. 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 difficult 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 opportunity for developing countries to use a software that can help people save lives.

The second reason is more about me being a technical guy. HospitalRun has several technical challenges that are hard to approach and nail down. 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.

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 play well together. It has been 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.

The first time I encountered HospitalRun, it had been 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 doesn't have any tracking capabilities. There were many users asking for help and it was difficult to figure out what kind of deployment 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 foundation. We decided to drop Ember.js in favour of React and to use Fastify in place of Express.

After the first few weeks some members of the community felt betrayed. But things started working 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.

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 will not repeat the same mistakes that had already been made in the past.

Now, I am sure that HospitalRun will be rewritten from the ground up using 5 years of knowledge and avoiding the major pain points that the fromer maintainers faced. 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 on 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.

HospitalRun is an 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.

Since HospitalRun exists for more than 4 years now, Joel and I agreed that this new beginning was the perfect time to introduce a new tech stack.

We set 2 major goals:

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 from the ground up for modularity and performance. I really pushed hard for us to use it and after getting some feedback from the community I know that everyone is happy.

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, which allows us to replace, improve and extract parts of our code-base as standalone applications effortlessly.

As one more and final benefit, I am going to cite the framework speed. Thanks to the internals it is blazing fast!!!

Absolutely, I have been using 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 then, 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.

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 directly use several Express middleware and recycle concepts and patterns, there is a better way to get your job done.

I call it “the Fastify way”! The best way to approach Fastify is by learning its plugin system.

After learning the initial conepts rethink your approach to the APIs development. Fastify may not be easy to learn, but it is very easy to master.

Don't get stuck on your own preconceptions. Just let Fastify’s way flow!

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 will 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 more people involved in 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. I want this community to have maximum transparency. 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 experience with 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.