Backend for Frontend (BFF)
Last Updated: May 26, 2026
An API gateway gives clients a controlled entry point. A Backend for Frontend goes one step further: it gives each client experience an API shaped for that experience.
A web app, mobile app, partner integration, and admin console may use the same product domain but need different payloads, caching behavior, latency budgets, permissions, and release cycles.
The Backend for Frontend (BFF) pattern creates a small backend for one client family. It receives client requests, calls backend services, composes the result, and returns a response that fits that client.
The goal is to keep client-specific behavior close to the client without polluting core services or turning a shared gateway into a pile of client-specific branches.
The Problem: One API Shape Does Not Fit Every Client
Consider a product detail page used by three clients.
| Client | Needs |
|---|---|
| Web app | Full description, large images, reviews, related products, SEO metadata |
| Mobile app | Compact description, small images, rating summary, stock status |
| Partner API | Product ID, SKU, price, availability, bulk sync metadata |
Those clients are asking about the same product, but they are not asking for the same representation.
Different Interaction Patterns
The mobile app is sensitive to payload size and unreliable networks. The web app may care about server rendering, SEO metadata, and rich interaction. The partner API may prefer stable bulk-oriented contracts over UI-friendly responses.
Different Release Cycles
| Client | Typical Release Constraint |
|---|---|
| Web app | Can deploy many times per day |
| iOS app | App Store review and slow client upgrade curve |
| Android app | Faster than iOS in many teams, still client-version constrained |
| Partner API | Breaking changes may require months of notice |
| Admin console | Operational workflows may need fast iteration and richer permissions |
A shared API must protect the slowest-moving consumer. BFFs let each client contract evolve at the pace of that client.
Shared Gateway Drift
When every client-specific concern goes into one gateway, the gateway stops being a clean edge layer.
Changes for one client start creating risk for every other client. Ownership also gets murky: the platform team owns the gateway, but product teams keep adding product-specific behavior to it.