Backend for Frontend (BFF) Pattern
Term 60 of 68 in the ERPStack technical glossary
What is Backend for Frontend (BFF) Pattern?
The Backend for Frontend (BFF) pattern is an API design strategy that creates a dedicated backend service for each type of frontend client (web, mobile, IoT), optimizing data fetching and response shaping for each client's specific needs.
Backend for Frontend (BFF) Pattern at a glance
- Shape
- 1 backend per client type — web, mobile, partner — over the same shared domain services
- Purpose
- Collapse 6 chatty client calls into 1 response shaped for the screen that needs it
- Implementation
- Next.js 16 route handlers or server components acting as the web BFF
- Boundary rule
- 0 business rules in the BFF — it aggregates and reshapes, it does not decide
- Built with
- Next.js 16 route handlers and React 19 server components as the web BFF, TypeScript 5.9 end to end, Redis caching, PostgreSQL 18 behind the domain services, traced with OpenTelemetry
- Numbers that matter
- 6 client calls collapsed into 1 response; 1 BFF per client type; 0 business rules inside it; 3 typical clients — web, mobile, partner
- Compare with
- A shared REST API, a GraphQL API Schema, or an API gateway serving every client
- Commonly paired with
- Next.js 16, React 19, tRPC Protocol procedures, a GraphQL API Schema, Redis caching and Sentry
- Contract discipline
- Every response shape declared with Zod 4 and exercised by Vitest 4, so a screen change is 1 typed edit rather than a silent break in a mobile client.
- Where it runs
- Beside the front end on Vercel or AWS, with OpenTelemetry Observability tracing 1 request through the aggregation and out to each domain service.
How Backend for Frontend (BFF) Pattern works in production
The ERPStack approach to Backend for Frontend (BFF) Pattern
We implement BFF patterns using Next.js Route Groups and tRPC router namespaces, allowing mobile apps and web dashboards to share the same PostgreSQL backend while receiving optimized, client-specific response shapes.
Frequently asked questions about Backend for Frontend (BFF) Pattern
Why add a Backend for Frontend at all?
Because 1 general-purpose API cannot be optimal for every client. A mobile screen wants a small payload in 1 round trip; a desktop dashboard wants far more data; a partner integration wants stable, generic resources. The Frontend Pattern gives each client an adapter that aggregates and trims on the server, so the client stops paying for a shape designed around somebody else's constraints.
How is a BFF different from an API gateway?
Ownership and purpose. A gateway is shared infrastructure doing cross-cutting work — routing, authentication, rate limiting — for everyone. A Frontend Pattern backend is owned by the client team and exists to serve exactly 1 experience, so it can change whenever that experience changes without negotiating with other consumers. Using a gateway as a BFF re-creates the coordination problem the pattern removes.
What should never go in a BFF?
Business rules. The moment pricing logic or an authorisation decision lives in the Frontend Pattern layer, it has to be duplicated for the next client, and the 2 copies will drift. The BFF's job is aggregation, projection and protocol translation; the authoritative decision belongs in the domain service behind it, where every client inherits the same answer.
Do React Server Components make the BFF unnecessary?
They absorb part of it. In Next.js 16 a server component fetches and composes on the server, which is exactly the aggregation a web Frontend Pattern layer performed, so a separate service is often unnecessary for the web client. The pattern still applies where non-web clients exist — a mobile app or a partner integration still needs its own shaped surface.