Backend for Frontend (BFF)

Table of Contents

🟠 P1 — solves the “one API doesn’t fit all clients” problem

Problem #

Mobile clients need minimal payloads and few round-trips. Web clients need richer data. Admin dashboards need different views entirely. A single generic API serves none of them well.

Mechanism #

Mobile App     Web App     Admin Dashboard
    ↓              ↓              ↓
Mobile BFF     Web BFF     Admin BFF        ← per-client API layer
    ↓              ↓              ↓
    └──────────┬───────────┘
               ↓
        Shared Backend Services

Each BFF is a thin service that:

Aggregates calls to multiple backend services
Transforms responses to client-specific shapes
Optimises payload size and round-trips for its client

Key Trade-offs #

Dimension	BFF approach	Single API approach
Client UX	Tailored per-client	Compromise for all clients
Maintenance	Multiple API surfaces to maintain	Single surface
Duplication	Logic can duplicate across BFFs	No duplication
Team ownership	Client teams own their BFF	API team owns everything

Instinct #

BFF is justified when you have genuinely different client requirements — not just “mobile vs web.” If the data shape and round-trip requirements truly differ, BFF pays for itself. If clients differ only in styling/presentation, a single API with sparse fieldsets (or GraphQL) is simpler.

References #

Backends For Frontends — Sam Newman (the originator)
The Backend for Frontend Pattern — Phil Calçado (SoundCloud)