Backend for Frontend
Date: 2026-08-17
A backend for frontend (BFF) is an API layer owned by one client team and shaped for exactly one client. It exists because a single general-purpose API serving web, mobile and till systems ends up serving none of them well — and because every client otherwise reimplements the same fan-out over the network.
The problem it solves
A product page needs catalogue, price, stock, reviews and content. Without a BFF, the browser fetches all five.
WITHOUT BFF WITH BFF
browser browser
├──→ catalogue 120ms └──→ BFF /product/123 140ms
├──→ pricing 180ms ├──→ catalogue ┐
├──→ inventory 90ms ├──→ pricing │ parallel,
├──→ reviews 200ms ├──→ inventory │ same datacentre,
└──→ CMS 160ms ├──→ reviews │ 5–15ms each
└──→ CMS ┘
5 round trips over mobile network
waterfall if any depends on another 1 round trip, one payload,
~750ms and five failure modes already shaped for the page
in the client one failure mode the client sees
Two things changed. The fan-out moved to where the network is fast, and the failure handling moved somewhere it can be written once. The client gets one call with the fields the page renders.
What belongs in it
- Aggregation — the fan-out above
- Shaping — return the eight fields this screen uses, not the sixty the catalogue service holds
- Client-specific concerns — image sizes for this viewport, currency and locale formatting, the mobile app’s pagination convention
- Degradation policy — reviews time out, render the page without them; price times out, fail the request. That decision is per-client and belongs here — Graceful Degradation
- Session and token exchange — hold the session server-side, call downstream services with their own credentials, and never ship a downstream token to a browser — Sessions and Tokens
What doesn’t
No business logic. The moment pricing rules or stock allocation live in the BFF, the mobile app and the web app disagree about them, which is exactly the bug the pattern is supposed to prevent. If two BFFs need the same rule, it belongs in a service behind them.
No persistence. A BFF with its own database has become a service and needs to be governed as one.
One per client, and the cost of that
web BFF ← owned by the web team
mobile BFF ← owned by the mobile team
in-store BFF ← owned by the retail team
all three call the same catalogue / pricing / inventory services
The ownership is the point. A BFF changes at the pace of its client’s UI, which is much faster than a shared API can safely move. If the platform team owns the BFF, the queue is back and the pattern has failed.
The honest cost: duplication between BFFs is expected and correct. Three BFFs will each format a price. Deduplicating them into a shared library recreates the coupling you paid to remove — accept the repetition, or accept the queue.
When it’s the wrong answer
- One client. A BFF for a web-only site is just your backend. Call it that
- The clients genuinely want the same thing. Then the shared API is fine and the BFF is a hop
- GraphQL already solves it. A GraphQL layer lets each client select its own shape, which is the shaping half of a BFF without the per-client deployment. It doesn’t give you per-client degradation policy or ownership, so the two coexist more often than they compete
- It’s becoming a monolith with extra steps. A BFF that accumulates logic from every team is the old monolith rebuilt in front of the services
Where it interacts
- Monolith vs Services — a BFF is mostly a device for stopping a service split from leaking into clients
- Edge Computing — running the BFF at the edge cuts the client round trip further, at the cost of being further from the services it calls. Measure both hops before assuming it wins
- Rendering Strategies — with server rendering the BFF and the renderer often merge, which is fine as long as the no-logic rule holds
- Rate Limiting — the BFF is where per-client limits are enforceable, since it’s the only place that knows which client is calling