Hot-swapping the Web API for mobile application

Reverse Proxy ( API Gateway ) to manage Web API versioning.

Hot swapping term drive from hardware component replacement or addition without rebooting the system. When we talk hot-swapping in the Web API context, we can interpret it as no downtime when releasing new features or promoting from beta to public release.

Why is a mobile application is the most suitable candidate?

Mobile Apps are an ideal candidate for hot-swapping web API.

Imagine you have a mobile app with live traffic, and you have a new feature release that needs to make generally available for public testing ( beta ). It will break the current app because API changed or has breaking changes.

This creates a deadlock situation, so we need to release a new API version that will break the current app or if we go with releasing the mobile app that will not work with the old web API.

We have a few possible solutions and work around here to resolve this issue.

1. Add new fields if possible to handle current and upcoming requirements.
2. Change URL routing like add v1, v2, v3 or add version in HTTP headers so new mobile app can consume new API on another URL prefixed route.
3. Add central API in front that will route API on demand by mobile app.
4. Add reverse-proxy ( API Gateway more princely here )

Let’s validate all four options and select an optimal solution to this problem.

1. Add new fields if possible to handle current and upcoming requirements. Adding custom fields to prevent breaking changes might be possible in some cases. The solution is to introduce a new field to fulfill the latest requirements. But unfortunately, that does not solve your problem every time but more of this will add an extra burden on API to handle multiple fields that will result in the app no more remaining maintainable, scalable, and sustainable.
2. API versioning by URL or Headers Another approach is to add API versioning so whenever a new app is released it will increment the API version as well and point the app to use the latest version, the previous version of the app will still work with the previous version. This option is widely adapted by mobile application developers/companies.
   Problem solved? Yes, it is solved when you do not promote apps directly from beta to publicly available and change URL when public releasing this means you have to go through again with testing on Apple & Android Stores.
3. Central API This approach is used when the app adds another Web API to load configuration, users base, and client base implementations by another Web API. Central API is responsible to establish initial communication between the app and the Web API server and performing central operations like authenticating users and loading configurations then it will tell the mobile app which endpoint they need to use for reset of the functionality. This approach is widely used for mobile applications that have multiple clients or multi-tenant nature. This will introduce a single point of failure for every tenant or client when the central API goes down.
4. Reverse-proxy or API Gateway Add a reverse proxy that will site in front of Web API. That will provide extra perks like load-balancing, protection from attackers (WAF), caching, SSL, and gateway to manage requests. Reverse-proxy retrieves resources on behalf of a client from one or more servers. These resources are then returned to the client, appearing as if they originated from the reverse proxy server it. This approach makes Web API enabled for hot-swapping.

Reverse Proxy Setup

Tada!🎉We have winner here.

[Next Post] I will share story in upcoming week on how we can implement solution based on reverse-proxy to enable hot swapping web API and manage multiple versions.

Stay tune! follow our publication for more interesting stories.

---