Backend for Frontend
also called BFF
A dedicated backend per client experience, owned by the client team, that shapes and aggregates downstream services for that client's exact needs.
The problem it solves appears whenever one API serves several clients: a web application, a mobile application and a smart display need different data shapes and different payload sizes, and a shared general-purpose API serves all of them adequately and none of them well. Mobile in particular pays for over-fetching in battery and bandwidth on networks the API designer never experienced.
The BFF is a thin layer per client that calls downstream services, aggregates, trims and reshapes. Crucially it is owned by the client team, which is what removes the cross-team negotiation for every field change — that ownership is the pattern, and a BFF owned by a central platform team is just another API with an extra hop.
What it costs: another deployable per client, some duplicated aggregation logic between BFFs, and a real risk of business logic migrating into a layer that was meant to shape data. That last one is the degradation to watch — the moment a BFF starts making domain decisions, it has become a service with a misleading name.
Where it earns its place beyond shaping: it is a natural spot for client-specific authentication handling, for token exchange so browser sessions never hold downstream credentials, and for the response caching that suits one client's access pattern.
GraphQL is frequently proposed as the alternative and genuinely solves the over-fetching half while leaving the ownership and aggregation questions open.