Backend for Frontend
You'll learn to
- -Explain what problem the Backend for Frontend (BFF) pattern solves that a single shared gateway API does not
- -Decide when a BFF is worth its added infrastructure versus when a single well-designed API (or GraphQL) already solves the problem
A single gateway API serving every client type (web, iOS, Android, a partner integration) tends to accumulate compromises - fields the mobile app doesn't need but the web app does, response shapes tuned for one client's rendering model that fight another's. Backend for Frontend addresses this by giving each client type its own dedicated backend layer, shaped specifically around what that client needs.
One Gateway, Many Compromises
{
"id": 501,
"customer": { "id": 42, "name": "Ada Lovelace", "billing_address": {...}, "order_history_summary": {...} },
"line_items": [...],
"shipping_details": {...},
"internal_fulfillment_notes": [...],
"audit_trail": [...]
}
// mobile app needs maybe 4 of these fields; the rest is wasted bandwidth
// on every mobile requestA BFF Per Client Type
// GET /mobile-bff/orders/501
{
"id": 501,
"status": "shipped",
"total": 149.99,
"tracking_number": "1Z999AA10123456784"
}Each BFF sits between its specific client and the underlying domain services, aggregating and shaping data exactly for that client's needs - the mobile BFF might aggressively trim payloads for bandwidth-constrained connections, while a web dashboard BFF might aggregate data from several services into one rich response to minimize round trips for a data-dense UI. Neither client is compromising to accommodate the other's needs anymore, since each has its own tailored layer.
The Real Cost: More Services to Maintain
A BFF per client type means more deployed services, each needing its own maintenance, monitoring, and on-call ownership - this is a genuine infrastructure cost, not a free win. It earns its place when client needs have diverged enough that a shared API is a real, ongoing source of friction (not just a one-time inconvenience), and there's a team structure where each BFF can be clearly owned (often by the same team that owns the corresponding frontend, keeping the BFF's evolution tightly coupled to the client it serves).
BFF vs. GraphQL: Overlapping, Not Identical
GraphQL solves a similar problem - letting each client fetch exactly the shape it needs - from a different angle: one shared schema with client-driven queries, instead of multiple bespoke backend services. GraphQL avoids the "many services to maintain" cost of BFF, but it centralizes schema evolution and resolver logic in one place, which reintroduces some of the shared-bottleneck coordination concern BFF specifically avoids. Neither pattern is strictly superior - the choice depends on whether the team structure favors one shared schema everyone contributes to, or genuinely independent per-client backend ownership.
A useful test before adopting BFF: is the pain genuinely "different clients need different data shapes," or is it actually "our one API has grown badly designed for everyone"? BFF solves the first problem; it just relocates and multiplies the second one.
Interview Signal is part of Pro
See a real weak answer next to a real strong one for this exact topic.
Quiz is part of Pro
Test what you just read with a short quiz, and bank the XP.
Design BFF Workshop in the API Design Lab's Full System Design act.