Skip to content

CONCEPT Cited by 1 source

Backend-for-Frontend (BFF)

Definition

Backend-for-Frontend (BFF) is an architectural pattern pioneered at SoundCloud (sam-newman.com) where a backend service is created per frontend surface or per business/use-case — rather than having one shared backend API consumed by every client. Each BFF is owned by the frontend team that uses it, sits between that team's UI and the organisation's microservices, and composes / shapes / tailors responses to what that specific client needs.

Core idea

The BFF is a thin service whose only job is to serve one frontend well:

  web app       iOS app       Android app
     │              │               │
     ▼              ▼               ▼
  Web BFF       iOS BFF         Android BFF   ← one per surface
     │              │               │
     └──────────────┴───────────────┘
                    ▼
          shared domain microservices

Each BFF handles:

  • Request shape tailored to one client (mobile wants less data than desktop).
  • Composition of multiple domain microservice calls.
  • Platform-specific formatting (iOS date format vs Web).
  • Often: auth + session handling for that surface.

Netflix's parallel framing

Netflix's "Embracing the Differences" API redesign arrived at structurally the same conclusion, stated as four characteristics any API serving frontend applications should have:

  • Embrace the differences of the devices
  • Separate content gathering from content formatting/delivery
  • Redefine the border between "Client" and "Server"
  • Distribute innovation

Zalando's 2021 post calls these out as peer framings of the same problem (Source: sources/2021-03-03-zalando-how-we-use-graphql-at-europes-largest-fashion-e-commerce-company).

Pathologies at scale

When a large organisation adopts BFF-per-surface surface-by-surface (Zalando after its 2015 microservices move: Web product page BFF, Web wishlist BFF, App wishlist BFF, App home BFF, …), five pathologies emerge rooted in Conway's Law:

  1. Suboptimal feature-delivery / developer-experience balance. Each BFF team reinvents its own primitives; cross-surface feature work requires coordinating N teams.
  2. Duplicated effort across BFFs. The same product page aggregation logic exists in N BFFs with drift.
  3. Inconsistent customer experience across platforms. The most subtle one. Zalando's worked example: mobile shows delivery "5-9 Feb" while desktop shows "1-3 Feb" because different BFFs compute the delivery window independently.
  4. Fragmented Security + Authentication. Each BFF invents its own session/auth path; security review is N times as much work.
  5. Fragmented Observability. No single place to trace a "view a product" request; every surface is wired differently.

Zalando names these explicitly in their 2021 post and cites them as the motivation for collapsing from many BFFs to a single Unified Backend-For-Frontends GraphQL service.

Why the pathology is Conway's-Law-shaped

Three BFF teams don't mean to produce three different delivery-window computations. But each BFF team owns its own logic, ships at its own cadence, and the cheapest path to features is re-deriving the logic locally. The organisation's communication structure (teams that don't regularly coordinate) shapes the system's seam structure (N implementations of the same business rule).

The unified-graph response

The industry-wide response — pioneered at GitHub, Shopify, Airbnb, Expedia, Netflix, and operationalised at Zalando — is to replace per-surface BFFs with a single unified GraphQL graph that every client consumes. The schema becomes the shared interface; business logic drops into a presentation layer behind the graph. See patterns/unified-graphql-backend-for-frontend for Zalando's canonical instance.

When BFF does still make sense

  • You have one or two surfaces and strong per-surface customisation needs.
  • Your organisation cannot yet sustain a unified-schema platform (no dedicated schema-governance team, no ability to deprecate fields across clients).
  • Your domain is small enough that duplication has not yet become painful.

Once the number of surfaces × domains crosses some scale threshold (Zalando: 12+ domains × Web + App), the BFF pathologies dominate and the unified-graph approach wins.

Seen in

Last updated · 476 distilled / 1,218 read