One API Does Not Fit All
A mobile app, a web app, and a smart TV have very different needs. A single shared API ends up bloated with options for everyone. The backend for frontend pattern, often called BFF, gives each client type its own thin backend that shapes data exactly for that surface.
What a BFF Does
- Aggregates calls to several downstream services.
- Trims and reshapes data for one client, reducing over fetching.
- Holds client specific logic so the shared services stay generic.
Trade Offs
A BFF removes coupling between clients but adds another deployable layer to build and maintain. Teams often own the BFF for their own frontend, which aligns the boundary with the team that feels the pain of a bad API.
Avoiding Sprawl
Keep BFFs thin; they orchestrate and adapt, they do not hold core business rules. Shared logic belongs in the downstream services so it is not duplicated across each BFF.
Key idea
A backend for frontend gives each client its own thin tailored API that aggregates shared services, cutting over fetching while keeping core logic downstream.