Healthcare Application Development | Vicert
Read about ideas that untangle
the complexity of Digital Health

“Eating” Spaghetti Code for Breakfast, and “Serving” Custom API Framework for Lunch

Posted by Boris Zolotarev on Apr 27, 2017

Or How to Setup an API Framework for a Client that Serves a Million Users Monthly Without Disturbing Them

Our client serves a million customers monthly. Over the years they have worked with multiple vendors who have built apps on top of the legacy code system, which overtime has made it extremely complex and unstable. All the services in the client’s portfolio were developed by different vendors/teams who had various architectures and patterns. Every service had it’s own login and monitoring, plus they all were mutually dependant.

Serving hundreds of thousand customers daily escalated the problem even further, making it unscalable, vulnerable and without a centralized login and monitoring. On top of that, the resources needed for the maintenance of the code skyrocketed. Therefore the addition of new apps would endanger the work of the system as a whole.

How it looked like in practice:

 spaghetti_code3_blog-illustrations.png

The system worked by one app calling another app, who then called another app and all without the possibility to turn off select parts of the system. This made it virtually impossible to implement new services by other vendors.

SOLUTION:

Our solution was to introduce a new layer to the system - API Framework. First we had to separate various services/apps and unify them in terms of architecture. We needed to increase the level of security since the client hosted private data from the users, so we made a standard external API access point with a high level of security.

The most important thing was to centralize the implementation of the system's core functions: login, monitoring and standardizing the development of new services by creating dev templates.

The new system allowed the maintenance crew to easily turn off apps they wanted to update or fix without disturbing the rest of the system/apps through a graphic user interface.


The framework architecture looked like this:

framework_blog-illustrations.png

 

BENEFITS:

The solution we developed is one of the three core systems our client has on which everything else rests: the core system, the business process modelling system and now the API framework.

Keeping in mind that amount of users our client serves daily, while collecting and storing their private data - security was one of the most important aspects of the solution. Having worked with payers for more than 15 years allowed us to deliver bullet-proof code. Additionally, we set up dev templates for future vendors by establishing a service for developing new apps and refactoring of the existing modules. This way we could guarantee the security of apps and services built on top of the API framework in the future.

Since the client’s internal IT team was not familiar with the API framework, we held a series of workshops for their developers and delivered 11 documents with instructions and explanations on how to use and develop this configuration portal further.  

The client was using .NET technology so we used the latest version of .NET visual studio which was launched two weeks before the project started. After working with us, the client introduced a series of new processes such as priority queue patterns, circuit breakers and numerous detailed unit tests.

 

Tech: .NET

Duration: 7 months

Segment: HealthTech Product

Topics: .NET, API Framework