Book 09 · Software ArchitecturePage 2 of 48

Backend for Frontend

Updated September 30, 20263 min read

In short

Backend for frontend is an architecture pattern in which each kind of client, such as a web or mobile app, gets its own small backend tailored to its needs.

What is the backend for frontend (BFF) pattern?

The backend for frontend pattern, or BFF, gives each type of user interface its own dedicated server-side layer. Instead of one general-purpose API that tries to serve a web app, an iOS app, an Android app, and a smart TV equally well, each client talks to a backend shaped exactly for its screens. The pattern became popular around 2015, as teams building for many devices found that a single shared API was either too chatty or bloated with fields nobody needed.

A BFF sits between the client and the downstream services. For one screen it may call several microservices in parallel, merge and trim the results, and return exactly the data that screen needs in one response, which saves round trips on slow mobile networks. It is usually owned by the same team that builds the frontend, so they can change it at their own pace. BFFs are also used for security: the BFF can keep OAuth tokens on the server and give the browser only a secure session cookie.

Think of a personal shopper: instead of you visiting five shops, the shopper collects exactly what you asked for and hands it over in one bag. A mobile BFF might return small images and a compact list, while the web BFF for the same product page returns richer data and extra sections.

A BFF is often confused with an API gateway. An API gateway is a single entry point for all clients that handles cross-cutting concerns such as routing, authentication, and rate limiting, while a BFF contains client-specific logic for one frontend; many systems use both, with BFFs sitting behind a gateway. GraphQL is sometimes used instead of BFFs, since clients can request exactly the fields they need. The main risk is duplicated business logic across several BFFs, so real business rules should stay in the shared services.

Key takeaways

A BFF is a backend built for one specific frontend, such as web or mobile.
It aggregates and reshapes data from several services into one response per screen.
It is usually owned by the frontend team.
An API gateway handles cross-cutting concerns for all clients; a BFF serves one client's needs.
Keep core business rules in shared services, not in each BFF.

Example

A mobile BFF endpoint that combines three servicestypescript

// Mobile BFF: one request from the app, several calls to internal services
app.get("/mobile/home", async (req, res) => {
  const userId = req.session.userId;
  const [profile, orders, offers] = await Promise.all([
    fetch(`http://user-service/users/${userId}`).then((r) => r.json()),
    fetch(`http://order-service/orders?user=${userId}&limit=3`).then((r) => r.json()),
    fetch("http://promo-service/offers?channel=mobile").then((r) => r.json()),
  ]);
  // Return only what the mobile home screen shows
  res.json({
    greeting: `Hi, ${profile.firstName}`,
    recentOrders: orders.map((o) => ({ id: o.id, status: o.status })),
    topOffer: offers[0] ?? null,
  });
});

Readers ask

What is the difference between a BFF and an API gateway?

An API gateway is a shared entry point for all clients that handles routing, authentication, and rate limiting. A BFF is a separate backend for one specific client that shapes data for its screens, and BFFs often sit behind a gateway.

When should you use the BFF pattern?

It helps when several different clients, such as web and mobile apps, need very different data from the same services, or when frontend teams want to change their API without coordinating with every other team. For a single client with simple needs, one API is usually enough.

Does GraphQL replace the need for a BFF?

Sometimes. GraphQL lets each client request exactly the fields it needs, which solves much of the same problem, but some teams still add a BFF for session handling, security, or client-specific logic.