API Gateways in a Microservices World
You'll learn to
- -Explain the gateway's role once you have many services
The Protecting Your System module introduced the API Gateway as a good idea even for a single service. In a microservices world, it goes from "good idea" to close to mandatory: dozens of independently-deployed services can't each reimplement authentication, rate limiting, and TLS termination without massive duplicated effort and inconsistency.
Backend for Frontend (BFF)
Some architectures go a step further and run multiple gateways, each tailored to one type of client: a mobile BFF that aggregates and trims responses for a bandwidth-constrained app, and a separate web BFF shaped around what the browser client needs. Same backend services underneath, different front doors for different consumers.
Each BFF aggregates the same backend services into a shape tailored to its specific client.
Your mobile app screen needs data from four different microservices. Should the mobile client call all four directly?
"Sure, the client can just make four API calls."
"That couples the mobile client to internal service boundaries that have nothing to do with it, and turns one screen load into four round trips (worse on a mobile network) with four separate failure modes to handle client-side. A BFF aggregates those four calls server-side (one request from the client, one response shaped exactly for that screen) and internal services can be re-split or renamed later without ever touching the mobile app."
Which of these is a genuine signal to split a monolith?
Level 18: Ride-Sharing (Uber) is a full microservices exercise.