BackendsForFrontends
title: Backends for Frontends type: technique created: 2026-05-26 last_updated: 2026-05-26 related: ["radar/techniques/DataFetchingPatternsSPA", "radar/platforms/PostgREST"] sources: ["https://itnext.io/backends-for-frontends-bff-5cbcb4b67a30"] radar_quadrant: Techniques radar_ring: Assess radar_position: inner
An architectural pattern that creates a dedicated backend service per frontend client type rather than a single shared API. Each BFF aggregates and shapes data from downstream services specifically for one client — mobile app, web app, or third-party integration — allowing each to evolve independently.
A shared API serving multiple client types must satisfy divergent requirements simultaneously. Mobile clients want compact payloads optimised for bandwidth and battery. Web clients want richer data with more fields. Public API consumers want stable contracts that never change. The result is an API that compromises on all three: too heavy for mobile, too limited for web, too volatile for external consumers.
Over time, shared APIs accumulate client-specific logic — conditional fields, version negotiation, response shaping flags — that belongs in the client layer, not the core service.
Each BFF is a lightweight aggregation service owned by the team responsible for its client:
- Mobile BFF — compact responses, optimised field selection, push notification integration
- Web BFF — richer payloads, session management, server-side rendering support
- Public API BFF — stable versioned contracts, rate limiting, API key management
All BFFs call the same downstream microservices or data stores. The BFF layer handles aggregation, transformation, and client-specific concerns. Downstream services remain generic.
The pattern increases operational surface: more services to deploy, monitor, and maintain. It pays off when client types have genuinely divergent data requirements or when separate teams own separate clients and need autonomy to change their API contract without coordinating with other clients.
For a single client type or a small team, a shared API with good design discipline is often sufficient.
Backends for Frontends sits in the Assess ring of the Techniques quadrant, at inner position. First studied via ITNEXT (2024-10-14). The pattern is well-established in microservices literature but frequently rediscovered by teams building their first multi-client API. Naming it on the radar provides a reference point when the shared-API compromise starts causing friction. Inner position reflects applicability to any multi-client API project and zero tooling cost — it is a design decision, not a dependency. Remaining gate before Trial is a concrete implementation where a BFF serves one client type with measurably simpler response contracts than the shared API it replaced.
