Backend for Frontend

Definition

Rather than one general-purpose API serving web, iOS, Android, television and partner integrations, each client class gets its own thin backend. That backend aggregates from downstream services and returns exactly what its client renders.

Why it matters

A single shared API is optimised for nobody. It carries fields the mobile client discards over a mobile network, requires three round trips to render a screen because the shapes do not match, and becomes a coordination bottleneck because every client team needs changes in it.

The clinching argument is usually the device constraint. A television interface and a phone interface need genuinely different data for the same screen — different image resolutions, different pagination, different amounts of metadata. Serving both from one endpoint means serving the union to both.

Industry example

Netflix's adoption of client-specific backends came from precisely this pressure: a very large number of device types, each with different capabilities, memory limits and network conditions, all rendering conceptually similar screens. A shared API forced the lowest common denominator on every device and made the API team the bottleneck for every client change.

The key organisational property is ownership: the BFF is owned by the client team, not by a platform team. This is what converts it from an extra hop into a genuine acceleration — the team that needs the change can make it, without negotiation. A BFF owned by a central team is just an API with more steps.

Implementation patterns

• Keep it thin. Aggregation, shaping, and client-specific concerns. Business rules stay in the services that own them.
• Fan out in parallel with a strict per-call timeout and an overall budget for the screen.
• Degrade partially. If the recommendations call fails, render the screen without that shelf rather than failing the whole response. This is where a BFF adds real product value.
• Cache per client class, since payloads differ.
• Accept duplication between BFFs. Two BFFs solving similar problems differently is the intended outcome; factoring out their commonality recreates the shared API you were escaping.

Failure scenarios

• The BFF grows business logic, and the same rule now exists in three BFFs, inconsistently.
• Central ownership, which restores the bottleneck the pattern exists to remove.
• Proliferation — a BFF per screen rather than per client class — multiplying deployables for no benefit.
• No timeout budget, so a slow downstream makes the whole screen hang; the BFF has aggregated the latency tails of six services.
• Duplicated authorisation logic drifting between BFFs, which is a security problem rather than a tidiness one.

Trade-offs

You gain client-optimised payloads, autonomy for client teams, and a natural place for graceful degradation. You pay with more deployables, deliberate duplication, and the risk of logic leaking outward into a layer that was supposed to be thin.

If you have one client, you do not need this pattern; you need a well-designed API.

Interview question

"You have web, iOS, Android and a television app. When is one shared API the better answer, and what would push you to BFFs?"