Backend for frontend (BFF)
A backend-for-frontend is a dedicated server-side layer per client type (web, iOS, Android, partner API) that adapts the underlying services to that client's specific needs — aggregating multiple service calls, reshaping payloads, and exposing only the endpoints that client requires. The pattern absorbs client-specific complexity that would otherwise pollute the shared services.
BFFs emerged at companies like Netflix and SoundCloud as a counter to the 'one API to rule them all' pattern where every client got the same generic API and did its own aggregation. The BFF lets the iOS team optimise their endpoints for mobile latency (fewer round trips, smaller payloads) without forcing the web team to live with the same constraints. The trade-offs: more services to operate, BFF code duplication across clients, and a tendency for BFFs to accumulate business logic that should live deeper. Healthy BFFs stay thin — aggregation, shaping, client-specific caching — and push domain logic to the underlying services.
Related terms
- API gateway
An API gateway is the single entry point in front of a service ecosystem that handles cross-cutting concerns — authentication, rate limiting, request routing, response aggregation, caching, observability — so each backend service doesn't reimplement them.
- Micro-frontend
A micro-frontend architecture decomposes a single web application into multiple independently developed and deployed frontend modules — each owned by a different team and integrated at runtime (via Module Federation, iframes, or web components) or build time (via package composition).
- Webhook
A webhook is an HTTP callback that one service invokes on another when a defined event occurs — typically a POST request with the event payload to a URL the consumer registered.