Backends for Frontends (BFF)

Best Practice: Backends for Frontends (BFF)

The Backends for Frontends pattern gives each kind of client its own dedicated backend. Rather than one general-purpose API trying to satisfy a web app, an iOS app, and a third-party integration at once, each frontend gets a backend shaped for its exact needs. The web BFF can return rich payloads; the mobile BFF can return trimmed responses to save bandwidth. Sam Newman popularized the pattern based on work at SoundCloud. It matters because a single shared API tends to accumulate client-specific branching, becomes a coordination bottleneck, and serves no client well. BFFs let frontend teams move independently while keeping core domain services clean.

Step-by-Step Implementation Guidance

1. Inventory your client types and how their data and interaction needs differ.
2. Create one BFF per client experience, owned by the team that builds that client.
3. Keep domain logic in shared downstream services; the BFF only aggregates and adapts.
4. Have each BFF call downstream services and shape responses for its client.
5. Handle client-specific concerns (payload shape, auth flows, aggregation) in the BFF.
6. Avoid duplicating business rules across BFFs by keeping them in shared services.
7. Apply consistent cross-cutting concerns such as auth and observability across BFFs.

Common Mistakes Teams Make When Ignoring This Practice

• Forcing all clients through one API that grows client-specific conditionals.
• Putting business logic into the BFF, turning it into a second monolith.
• Creating a BFF per team rather than per client experience, multiplying duplication.
• Letting BFFs call each other instead of shared downstream services.
• Inconsistent auth and logging across BFFs.

Tools and Techniques That Support This Practice

• GraphQL as a flexible aggregation layer per client.
• API gateways that route to per-client backends.
• Node.js or lightweight frameworks well suited to thin aggregation layers.
• OpenAPI to document each BFF contract.

How This Practice Applies to Different Migration Types

• Cloud Migration: Stand up a new cloud-native BFF in front of legacy services during transition.
• Database Migration: Shield clients from datastore changes behind a stable BFF contract.
• SaaS Migration: Use a BFF to adapt SaaS APIs into the shape your clients already expect.
• Codebase Migration: Introduce BFFs as a seam while decomposing a monolithic backend.

Checklist

• Map each client type and its distinct needs.
• Create one BFF per client experience.
• Keep business logic in shared downstream services.
• Assign BFF ownership to the frontend team.
• Prevent BFF-to-BFF calls.
• Apply consistent auth and observability.
• Document each BFF contract.