Backend for Frontend (BFF) Pattern
The Backend for Frontend (BFF) pattern, popularized by Phil Calçado from SoundCloud, addresses a fundamental tension in API design: a single backend cannot optimally serve multiple, diverse clients. Mobile applications have different data requirements, bandwidth constraints, and interaction patterns than web browsers or IoT devices. The BFF pattern creates a dedicated backend layer for each client type.
Core Concept
A BFF sits between the frontend and downstream services, tailored specifically to the needs of one client. Instead of forcing a mobile app and a web app to share the same API, each gets its own BFF that aggregates data, transforms responses, and manages session state in a client-appropriate way. The BFF is not a general-purpose API—it is purpose-built for its consuming application.
Benefits
The primary advantage is optimization. A mobile BFF can return smaller payloads with aggregated data from multiple microservices, reducing the number of network round trips on bandwidth-constrained connections. A web BFF might return richer HTML fragments or include data for server-side rendering. Each BFF can evolve independently, allowing teams to experiment with new APIs without affecting other clients.
Security is another benefit. Client-specific authentication and authorization logic lives in the BFF rather than being duplicated across frontend code. The BFF can handle token exchange, session management, and credential validation without exposing internal service architecture to the client.
GraphQL BFF
GraphQL has emerged as a natural fit for the BFF pattern. A GraphQL BFF provides a schema tailored to a specific client, allowing the frontend to request exactly the data it needs. The BFF resolves those queries by calling downstream services, combining results, and returning precisely shaped responses. This eliminates over-fetching and under-fetching while maintaining the BFF's role as a client-specific adapter.
Netflix's GraphQL federation and Apollo's federated graph approach extend this concept, where multiple BFFs can be composed into a unified graph while each remains independently deployable.
When to Use BFF
The BFF pattern shines in organizations with multiple client apps that have divergent requirements. Companies like SoundCloud, Netflix, and ThoughtWorks have documented successful BFF adoptions. It is particularly valuable when mobile and web products are on different release cycles or are built by different teams.
However, BFF introduces operational overhead. Each BFF is a deployable service that must be maintained, monitored, and scaled. Small teams may find the overhead unjustified. A pragmatic approach is to start with a single API and introduce BFFs only when clear pain points emerge.
Implementation Considerations
Each BFF should be owned by the same team that owns the frontend, fostering shared responsibility. BFFs should be thin—they orchestrate and transform, but should not contain business logic. Business logic belongs in downstream domain services. BFFs should also be independently deployable and scalable, since mobile and web traffic patterns differ significantly.
In practice, the BFF pattern has become a standard recommendation for microservice architectures serving multiple client types, and is a key building block in modern platform engineering initiatives.