Backend for Frontend
Pattern where each client type (web, mobile, IoT) has its own dedicated backend adapting microservice APIs to that client's specific needs.
seed#bff#pattern#frontend#api#microservices#architecture
What it is
Backend for Frontend (BFF) is a pattern where each client type has its own dedicated backend. Instead of a generic API Gateway, each BFF adapts, aggregates, and transforms data specifically for its client.
Why?
- Web needs different data than mobile
- Each client has different network constraints
- Avoids an API Gateway "god object" trying to serve everyone
- Each frontend team controls its BFF
Structure
Web App → BFF Web → Microservices
Mobile App → BFF Mobile → Microservices
IoT Device → BFF IoT → Microservices
When to use
- Multiple client types with different needs
- Frontend teams needing autonomy
- Microservice APIs too granular for direct consumption
When not to use
- Single client type — a generic API Gateway is enough
- Small teams where maintaining multiple BFFs is overhead
- When differences between clients are minimal (just response format)
BFF vs API Gateway
| Aspect | BFF | API Gateway |
|---|---|---|
| Purpose | Adapt data per client | Route and protect |
| Ownership | Frontend team | Platform team |
| Logic | Aggregation and transformation | Routing and auth |
| Quantity | One per client type | One centralized |
A BFF can live behind an API Gateway — they're not mutually exclusive.
Why it matters
The BFF pattern solves the problem of a generic API trying to serve multiple clients with different needs. Instead of overloading a single backend, each frontend has its own backend optimized for its specific access patterns.
References
- BFF Pattern — Sam Newman. The original article defining the pattern.
- Backends for Frontends — Microsoft, Azure Architecture Center.
- The Back-end for Front-end Pattern — Phil Calçado, 2015. Detailed analysis of the BFF pattern.