What is the Backend for Frontend (BFF) pattern and when does it replace a general API Gateway?

The Backend for Frontend (BFF) pattern creates a dedicated API backend for each distinct client type — one BFF for the mobile app, one for the web SPA, one for third-party integrations. Each BFF is owned by the team building that frontend and is free to shape, aggregate, and optimise responses exactly as its client needs, without compromising the API shape that other clients rely on.

The driving insight is that different clients have genuinely different needs. A mobile app on a 4G connection needs lightweight payloads with only the fields it displays. A web dashboard needs richer, pre-aggregated data across multiple services. A third-party partner API needs a stable, versioned contract independent of UI feature work.

Client request: GET /mobile/orders/42
Mobile BFF:
  parallel fetch:
    order  = orderService.get(42)          // id, status, total only
    status = shippingService.track(42)     // latest event only
  return { id, status, total, latestTracking }   // 4 fields, ~200 bytes

Client request: GET /web/orders/42
Web BFF:
  parallel fetch:
    order    = orderService.get(42)        // full order model
    customer = customerService.get(order.customerId)
    items    = productService.getBulk(order.itemIds)
  return { order, customer, itemDetails } // rich object, ~4 KB

When to use BFF over a general gateway:

• Multiple client types exist with divergent payload, filtering, or aggregation requirements.
• Frontend teams are blocked by a shared gateway team whenever they need API changes.
• Mobile clients suffer from over-fetching because the API was designed for a richer web client.

BFFs and a general API gateway often coexist: the general gateway sits at the edge and handles cross-cutting concerns (auth, SSL, DDoS); each BFF sits behind it and handles client-specific orchestration. A BFF is not a replacement for the gateway — it is a specialisation layer on top.