The BFF (Backend-for-Frontend) Pattern

The plain-language idea

A single general-purpose backend often has to serve several genuinely different clients at once — a web app, a mobile app, maybe a third-party integration — and those clients frequently want different data in different shapes. Shaping one set of API responses to be perfect for all of them simultaneously is often impossible: what a data-dense web dashboard wants (lots of fields, in one big response) can be exactly what a bandwidth-constrained mobile client doesn't want.

A BFF (backend-for-frontend) is a thin backend service, owned by (or sitting close to) a specific frontend team, placed between that frontend and the general-purpose backend(s) it ultimately reads from. Its entire job is reshaping and aggregating whatever the general-purpose backend returns into exactly the shape that one specific frontend needs — nothing more general than that.

Three concrete benefits fall out of this:

• The frontend team controls the shaping work directly. The response-shape decisions covered in the earlier lesson on frontend-friendly responses become code the frontend team can change on its own release schedule, instead of a request sitting in a backend team's backlog.
• It can aggregate multiple backend calls into one response. If a screen needs data from three different backend services, the BFF can make all three calls server-side and hand the frontend one finished response — instead of the frontend itself making three requests and risking the kind of request-waterfall delay covered in the earlier lesson on response shapes forcing follow-up requests.
• It's a natural place to hide backend implementation details. Field renaming, format conversion, and not exposing which internal service actually owns a piece of data are all easy to do in a layer the frontend team controls, without touching the general-purpose backend at all.

See it in a real thing: a dashboard's "order summary" screen

Without a BFF, the frontend makes three separate calls and assembles the result itself:

const [order, customer, shipment] = await Promise.all([
  fetch(`/orders/${id}`).then((r) => r.json()),
  fetch(`/customers/${order.customerId}`).then((r) => r.json()),
  fetch(`/shipments?orderId=${id}`).then((r) => r.json()),
]);

(And the customer call actually can't run in parallel with the order call above, since it needs order.customerId first — a real waterfall.)

A BFF endpoint built for exactly this screen does the aggregation server-side and returns one response:

// Inside the BFF, not the frontend
app.get("/bff/order-summary/:id", async (req, res) => {
  const order = await ordersService.get(req.params.id);
  const [customer, shipment] = await Promise.all([
    customersService.get(order.customerId),
    shipmentsService.getByOrder(order.id),
  ]);
  res.json({ data: { order, customer, shipment } });
});

The frontend now makes exactly one request and gets exactly the shape that screen needs.

What people usually miss

Watch out

• A BFF is not "a second backend that duplicates the first one." It doesn't own data or business logic — it orchestrates and reshapes calls to services that already own those things.
• One BFF per frontend, not one BFF for everyone. The pattern's whole value is that each BFF is shaped for exactly one client's needs — a single shared BFF serving both a web app and a mobile app recreates the original one-size-fits-all problem one layer down.
• It genuinely trades operational simplicity for shape control. A team that adopts a BFF is explicitly choosing "we'd rather own this shaping code and its deploy pipeline" over "we'd rather have one fewer service to run."
• The aggregation benefit only pays off when a screen actually needs multiple backend calls. A BFF endpoint that does one pass-through call to one backend service isn't adding real value — it's just an extra network hop.

Why this matters in interviews

"How would you handle a mobile app and a web app needing very different shapes from the same backend?" is a real system-design-adjacent question, and naming the BFF pattern — plus its real operational cost — shows you understand it as a genuine architectural tradeoff, not a default best practice to reach for everywhere.