Backend for Frontend
A backend for frontend is a dedicated server-side layer per client type — web, mobile, TV — that aggregates and shapes services for that experience, decoupling client needs from service contracts.
Definition
The BFF pattern gives each user experience its own server component: the mobile BFF joins services, trims payloads, caches aggressively, and exposes exactly the endpoints that experience needs. Services stay generic; client-specific shape lives in the BFF. It replaces one general-purpose API struggling to serve every form factor.
Context and scope
Adopted by teams with distinct clients whose needs diverge: mobile with constrained bandwidth, web with rich interactivity, third-party partners with stable contracts.
Common misconceptions
- A BFF is just an API gateway — gateways route and translate protocols; BFFs contain presentation logic and experience-specific aggregation
- One BFF per user experience, not per team — per experience is the organizing principle; team ownership then follows naturally in team-per-experience orgs
- BFFs are for mobile only — any client family with divergent shape, latency, and caching needs qualifies: TV, embedded, partner APIs
Anti-patterns
- Building one god-BFF serving all clients and recreating the general-purpose API with extra hops
- Pushing business rules into BFFs until the experience layer owns decisions that belong in services
- Duplicating orchestration logic across three BFF codebases without shared libraries
Related concepts
Related examples
Authoritative source
https://learn.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends
What it is
One API cannot be optimal for a phone on cellular and a desktop on fiber simultaneously: payload shape, latency budget, caching, and refresh patterns all diverge. The BFF lets each experience be selfish about its server.
How it works
Each BFF composes downstream services, selects fields, batch-calls, and caches at the edge appropriate to its client. Clients deploy against their BFF contract, freeing service teams from client-specific field pressure. BFFs belong to the client team — frontend skills, backend runtime, one ownership line per experience.
When to use it
Multiple client types with measurably different needs, client teams wanting to evolve their server surface independently, and partner-facing APIs requiring stability internal services do not promise. Single-client products should keep a single well-shaped API instead.
Pitfalls
BFF sprawl: each new client spawning a full server needs a cost review. Cross-BFF duplication of aggregation logic belongs in shared downstream services once it stabilizes. A BFF that accumulates authorization and business decisions becomes the new monolith middle — it is a presentation aggregator, not a domain owner.