The Software World
Scaling Client-Server Architecture — An Exploration
Exploration of various scenarios to enable forming of a scalable Client-Server architecture
Wheater we develop a mobile or web application, their usage is relatively limited if they are not connected to a server to provide meaningful content or personalized attribution. Therefore it is very critical for one to have a scalable architecture for the client (Web and App) with its Server/s (source of data).
I’m trying to think of various scenarios and try to make sense of them. Sharing my thought process here, and welcome anyone pointing out any mis-consideration.
In this exploration, our focus is more on the architecture between the client and servers, than the architecture of the server side on how they are partitioned (e.g. into multi-tier, etc, as shared here).
A simple view, the concept of BFF
The most simplified view we usually draw a Client Server Relationship is below.
However, in a more realistic scenario, sometimes the client needs to stitch information from various sources (server), hence making it look more like below.
While technically, the above is feasible, where the client can asynchronously stitch up information from multiple clients, it does introduce various complications on the client side, e.g. race condition, and complex stitching logic on the slower processing power client device.
Besides, from an App device point of view, one can argue this violates “Single-Source-of-Truth”, though strictly, it might not be the case (assuming each server are there to serve a distinctly different purpose)
The introduction of BFF (Backend for Frontend)
To overcome the above issues, a famously adopted approach is Backend-for-Frontend (aka BFF). This basically introduces another layer of Service between the App and all its previous servicers.
