Contents

Backend Development › API Design

Backend for Frontend (BFF)

A backend tailored to one frontend's needs.

Also known as: backend for frontend, BFF, bff pattern

A backend for frontend (BFF) is a backend layer dedicated to one type of client — a web app, an iOS app, a partner portal. Instead of every client calling one general API and stitching responses together, each client gets a backend shaped for its needs: the fields it wants, in the calls it can afford, in the format it expects.

web app  → BFF-web  ─┐
iOS app  → BFF-ios  ─┼─▶ shared services (users, orders, payments)

It solves the “one API for everyone” problem. A single API serving wildly different clients tends to accrete flags and fields to satisfy each, becoming bloated and forcing clients to over-fetch or make many round trips. A per-client BFF lets each be simple and opinionated.

The classic mistakes:

  • Putting business logic in the BFF. A BFF should aggregate, shape and tailor responses — not re-implement domain rules. Rules belong in the shared services; otherwise they diverge per client.
  • Confusing it with an API gateway. The gateway routes and applies cross-cutting policy for all clients; a BFF is client-specific composition and shaping. They often coexist.
  • One BFF to rule them all. If a single “BFF” serves every client, it becomes the general API you were trying to escape. BFFs are per client type.
  • Too many BFFs. A BFF per screen or per feature multiplies services and duplication. Split by client, not by page.
  • Sharing the BFF with external consumers. A BFF is an internal, changeable interface for your own clients; don’t accidentally publish it. See public vs internal APIs.
  • Ignoring ownership. The team that owns the client usually owns its BFF, so they can change it together — a natural fit with Conway’s law.

When to use it: when you have several distinct clients whose needs diverge, and a single general API is forcing awkward compromises. It trades a layer of services for simpler, faster clients and decoupled evolution. GraphQL can be an alternative for flexible client-driven querying, but a BFF is often simpler to reason about and cache. It all rests on a clear contract.