Backend for Frontend (BFF)
Create a dedicated backend service for each frontend — web, mobile, and third-party each get their own API tailored to their needs.
★★★★★3/5System topology — how multiple services are organised
How it works
The BFF pattern (coined by Sam Newman) creates a separate API layer for each type of frontend client. A mobile BFF returns compact payloads; a web BFF may aggregate more data. A third-party BFF exposes a stable public API.
BFFs own the translation between backend microservices and frontend data needs. They can aggregate calls to multiple services, transform data shapes, and adapt to the evolution of each client type independently.
Why it matters
A single general-purpose API often becomes a compromise — too heavy for mobile, too sparse for web. BFF lets frontend teams own their API, moving faster without blocking backend teams.
✓ When to use
- →Multiple client types with significantly different data needs
- →Mobile apps where payload size and battery impact matters
- →When frontend teams and backend teams move at different speeds
✗ When NOT to use
- →Single client type — adds unnecessary service
- →Teams too small to own separate BFF services
Trade-offs
Each frontend gets an optimised API contract
Code duplication across BFFs if logic is shared
Frontend teams can evolve their BFF independently
More services to deploy, monitor, and maintain
In production
Separate BFFs for TV devices, mobile, and browser
Originated the BFF approach for their platform rebuild
Industry adoption
Related principles
API Gateway
LiveSingle entry point for all clients that handles routing, authentication, rate limiting, and protocol translation.
Microservices Architecture
LiveDecompose an application into small, independently deployable services that communicate over a network.