Backend for frontend (BFF) is a web architecture pattern in which each type of client, such as a web application, an iOS app or an Android app, gets its own dedicated server-side layer that sits between the client and the general-purpose backend services. The BFF aggregates calls, reshapes data and handles client-specific concerns such as authentication flows, caching and payload size, so that each frontend receives exactly the API it needs.
The pattern emerged in organizations running many microservices and several client platforms, where a single generic API either forced every client to make many round trips or grew bloated with options for every consumer. A BFF is typically owned by the same team as its frontend, which lets that team change the API without negotiating with every other client.
How the backend for frontend pattern works
A BFF acts as a thin, client-shaped facade over downstream services. When a mobile app opens a product screen, it calls one BFF endpoint. The BFF then calls the catalog, pricing, inventory and review services, often in parallel, combines the results, removes fields the screen does not use and returns a compact response tailored to that view.
| Responsibility | What the BFF does | Benefit for the client |
|---|---|---|
| Aggregation | Combines several service calls into one response | Fewer network round trips |
| Shaping | Renames, filters and reformats fields | Smaller payloads, simpler client code |
| Authentication handling | Manages tokens and sessions on the server | Secrets never reach the browser |
| Protocol translation | Converts gRPC or messaging to HTTP and JSON | Clients use familiar protocols |
| Client-specific caching | Caches responses per screen or device | Faster repeated views |
| Error normalization | Maps downstream errors to client-friendly messages | Consistent error handling in the UI |
What a BFF should not contain is core business logic. Pricing rules, inventory decisions and payment authorization belong in domain services so that every client gets the same behavior. When business rules creep into several BFFs, they drift apart and produce inconsistent results across platforms.
The BFF as a security boundary for web applications
For browser-based applications the BFF has become a recommended security pattern for OAuth 2.0 and OpenID Connect. Instead of storing access tokens in JavaScript, where any injected script can read them, the browser holds only an HttpOnly, Secure, SameSite session cookie issued by the BFF. The BFF performs the authorization code flow as a confidential client, keeps tokens on the server and attaches them to downstream API calls.
This design reduces the impact of cross-site scripting, because scripts cannot exfiltrate tokens they never see. It also allows refresh tokens to be stored and rotated safely on the server. The trade-off is that the BFF must protect against cross-site request forgery, usually through SameSite cookies combined with a custom header or anti-forgery token on state-changing requests.
BFF compared with an API gateway and GraphQL
A BFF is often confused with an API gateway, and both may run in the same request path. A gateway is a shared infrastructure component handling routing, rate limiting and TLS termination for all clients. A BFF is application code for one client type. GraphQL offers another way to let clients request exactly the data they need through a single flexible endpoint.
| Approach | Owned by | Client specificity | Main purpose |
|---|---|---|---|
| Backend for frontend | Frontend team | One BFF per client type | Tailored API and server-side concerns |
| API gateway | Platform team | Shared by all clients | Routing, security policies, rate limits |
| GraphQL server | Platform or API team | Shared, client chooses fields | Flexible queries over one schema |
| Direct service calls | Service teams | None | Simplicity in small systems |
These options are not mutually exclusive. A common arrangement places an API gateway at the edge, a BFF per frontend behind it, and domain services behind the BFFs. Some teams implement their web BFF as a GraphQL server, and frameworks with server-side rendering often play the BFF role implicitly through their server routes and server components.
When to introduce a BFF and how to scope it
A BFF pays off when client needs genuinely diverge or when token handling must move off the browser. It adds a deployable service, so in a small system with one web client and one backend it may be unnecessary overhead. The decision table below summarizes typical situations.
| Situation | Recommendation | Reason |
|---|---|---|
| One web client, one monolith | No separate BFF | The monolith already serves the client |
| Web and mobile with different screens | One BFF per client type | Payloads and flows differ |
| Single-page application using OAuth | Web BFF for token handling | Keeps tokens out of JavaScript |
| Many microservices behind one screen | BFF with parallel aggregation | Reduces client round trips |
| Several web apps with identical needs | Shared BFF | Avoids duplicate code |
The usual scoping rule is one BFF per user experience, not one per team or per page. Web and mobile clients typically get separate BFFs, while an iOS and an Android app with the same screens may share one. Keeping each BFF small and stateless makes it easy to scale horizontally and to deploy together with its frontend.
Risks and common mistakes
- Duplicated business logic across several BFFs leads to inconsistent behavior between platforms.
- An extra network hop adds latency, typically a few milliseconds inside one data center, more if the BFF is deployed far from the services.
- Sequential downstream calls cancel the aggregation benefit; issue independent calls concurrently.
- A BFF that grows into a general API loses its client focus and recreates the original problem.
- Missing timeouts and fallbacks let one slow service block an entire screen.
Teams also underestimate operational ownership. A BFF needs monitoring, logging, alerting and capacity planning like any other service. When frontend teams own it, they need the skills and on-call arrangements to run production server code, not only client builds.
The simple explanation
Picture a large company with many departments. A phone app and a website both need information from all of them. Without help, each one would phone every department separately and sort through long answers.
A backend for frontend is a personal assistant for each app. The app asks the assistant one question. The assistant calls the departments, collects the answers and hands back only what that app needs. It can also keep sensitive keys locked in its office, so they never travel to the user’s device.
How it is used in practice
An online retailer runs about 30 backend services and three clients: a web store, an iOS app and an Android app. The product page in the mobile apps needed seven separate API calls, which made it slow on weak mobile connections, while the web store stored OAuth access tokens in browser storage.
The company introduces two BFFs. The mobile BFF exposes one product-page endpoint that calls catalog, pricing, stock, reviews and recommendations in parallel and returns a trimmed response roughly a third of the previous combined size. The web BFF takes over the OAuth flow, keeps tokens on the server and gives the browser only an HttpOnly session cookie.
Mobile product pages now load with a single request, and a later security review rates token theft through injected scripts as no longer possible for the web store.