Backend for Frontend (BFF) Pattern

The problem

One-size-fits-all API loses on every client. Mobile wants minimal payload, web wants rich data, partners want stable contract. Building for one means under-serving others; clients end up writing aggregation in JS or Swift anyway.

BFF moves that aggregation server-side, one BFF per client type.

Architecture

Mobile BFF, web BFF, partner API — each owned by the client team. Each aggregates 2-5 downstream service calls into one response shaped for that client. Mobile BFF uses Protobuf for size; web BFF returns JSON.

What BFF does

• Aggregates multiple service calls into one client-tailored response
• Drops fields the client doesn't need; flattens nested structures
• Translates formats (REST ↔ gRPC, JSON ↔ Protobuf)
• Handles client-specific auth (mobile OAuth vs web cookies vs partner API keys)
• Adapts to client bandwidth

What BFF doesn't do

• Domain logic — that lives in domain services
• Persistence
• Cross-cutting infrastructure like TLS / rate limit (that's the API gateway)

When to use

Multiple distinct clients with different needs. Mobile bandwidth-sensitive vs verbose canonical API. Client teams want autonomy. Different release cadences. Partners need a stable versioned contract while internal clients evolve fast.

When not to use

• Single client type — you just have an API
• Already using GraphQL federation that solves the same problem
• Team too small to maintain multiple BFFs

Compare with alternatives

API Gateway: edge of system, generic, not client-specific. BFF: one per client type, server-side aggregation. GraphQL Federation: client picks fields via query language; same goal, different mechanism.

BFF gives static predictable shapes (cacheable, performance-budgetable). GraphQL gives flexibility but harder to cache and audit. Many orgs use both — BFF for high-volume mobile/web critical paths, GraphQL for internal tools.

Common mistakes

• One BFF for web and mobile — defeats the purpose
• Business logic in BFF — belongs in domain service
• BFF owned by backend team — loses autonomy
• N+1 calls to downstreams — aggregate in parallel via CompletableFuture.allOf
• No caching strategy
• No bulkhead between BFFs — deploy independently

Recommendation

Use BFF when you have multiple distinct client types and the canonical API can't satisfy all of them. One BFF per client type, owned by the client team, stateless aggregation only — no domain logic. Combine with an API gateway at the edge for cross-cutting concerns. Reach for GraphQL federation instead when client field selection is the better fit — typically internal tooling or long-tail consumers.