Reducing costs with a unified Web API
An outdated legacy system caused a lot of headaches and unnecessary expenses for our partner. We joined forces to clean up their architecture in a renewed REST API.
Adam T.Our partner's more than a decade-old telemedical platform had significant issues with its outdated, fragmented architecture, complicated maintenance, and rising costs, which also increased developer frustration for their in-house team.
We worked together to find a better solution that would benefit both end users and all departments involved in the project.
Fragmented infrastructure
Our partner encountered plenty of troubles when they wanted to extend or simply maintain their 10+ years old telemedical platform.
It started as a simple website to help patients manage their health records and related therapeutic data with the assistance of their doctors. As technology advanced, more requirements emerged to support different kinds of connected clients, like mobile applications or other web-based services.
The biggest pitfall of their old infrastructure was they did not have a single source of truth. They made a separate web API for client applications while keeping the old website as it was, sometimes relying on different data sources. This meant they had to develop each feature multiple times to support them on every client application.
Decentralised data channels increase overall complexity and require special care across different pipelines. Every source has its own set of validation rules, often making maintaining data integrity the most challenging task.
With each update, the two systems became so inconsistent that by the end, when a requirement arose for a new API feature already supported by the website, our partner got an irrational offer from their contractor both in development time and cost.
The behaviour of their API endpoints caused another problem since they did not follow any architectural style, meaning different groups of API endpoints worked by different rulesets like they were part of a completely separate system.
Integrating a new API typically involves configuring the required interfaces and implementing the logic to handle reoccurring patterns. However, this task becomes almost impossible when dealing with an unpredictable API. Even if you manage to identify the patterns and prepare for all cases, a new API endpoint can easily break your solution with a new set of rules. This unpredictability makes their integration less of an engineering task and more of a slow manual labour.
Working with various data sources through inconsistent API endpoints also led to increasing load times for everyday tasks like syncing patient healthcare records. A fundamental issue was that patients had to wait minutes for the app to synchronise their data before they could do anything when starting the Android client.
All these issues raised expenses in all departments, from product management to customer support, and it increased frustration for the in-house development team responsible for client applications, not to mention the end users who had to get used to slow services and frequently delayed updates and bug fixes.
A single source of truth
Together, we crafted a thorough plan for a centralised web API with supplementary third-party services (like Firebase for push notifications) to serve all the needs of the existing clients. The main goal was achieving feature parity while sunsetting unused features and making the new system consistent, predictable, and open for upcoming features.
Database
Our first task was designing a new, properly normalised database schema without any space for duplications since the predecessor introduced plenty of them in the past decade.
Database normalisation
Database normalisation is the process of structuring a relational database per a series of so-called normal forms to reduce data redundancy and improve data integrity.
API Endpoints
After designing the database schema, we prepared the rules for the new web API endpoints with their request and response structures based on RESTful principles.
REST
Representational State Transfer is a design style used to structure software, especially for the web. It sets rules for how systems should communicate over the internet. REST focuses on consistent ways for different system parts to interact, making it easy to scale, update components separately, and use caching to speed things up and improve security.
Auth
For the authorisation, we chose the OAuth 2.0 standard because of all the various client applications and user roles the previous system had, as well as the plans our partner already had for the platform's future.
Implementation
In the following months, LevooLabs laid the foundation for the new REST API and its delegated authorisation service. We also helped the in-house development team implement the specific endpoints required for the initial release.
Not long after, we could quickly put the new API architecture to the test when developing the modern frontend application we were responsible for delivering while the in-house team was finishing the rest of the backend API.
During this phase, the integration was seamless. Meaning we could focus on the problems that mattered rather than constantly searching for workarounds for the issues with the backend API. This experience was a great forecast for the integration process of other clients.
Technical relief
During the development, the in-house team seamlessly migrated their native clients to the new cloud, meaning we successfully achieved the main goals we were aiming for.
The new backend architecture and overall solutions opened new doors for improvements on the client application side. The previous Android application had a bad reputation on the app store because of its flaws and slow operations. After releasing a new update leveraging the new API, some users returned to the app store to show their appreciation based on their new experiences.
"Synchronisation takes a long time before you can use the application. The meter device is sometimes not visible, and the measured data is not synchronised. UPDATE: After the latest update, everything works perfectly. Excellent, useful app." - Updated 5-star PlayStore review
While we weren't directly involved in the development of every client application, we still managed to help the desktop application team cut a massive chunk of their development scope and forthcoming maintenance costs with a completely new strategy for their 2.0 release that the new features made available.
The new architecture increased overall security and enabled more frequent service updates. All this allowed us to help our partner become the first in the country to send structured data into Hungary's National eHealth Infrastructure (EESZT).
The new ecosystem brought significant improvements to the platform. While some doctors took longer to adjust to the UI and feature changes we made, the overall feedback from patients and medical workers was highly positive, and the user base grew substantially.
