Backend for Frontends
Backend for Frontends creates a dedicated backend layer for each client channel such as web, mobile, or partner applications. Instead of asking clients to coordinate many domain services themselves, each BFF tailors orchestration and response shape to the needs of one channel.
βΆArchitecture Diagram
π RelationshipDashed line animations indicate the flow direction of data or requests
A single shared API often becomes a compromise when channels need different payloads, different request patterns, and different caching strategies. Then clients either over-fetch or make many small service calls and become tightly coupled to backend internals. BFF exists to reduce that mismatch between client experience and backend structure.
As SPAs, mobile apps, and multiple device experiences became normal, one generic backend stopped fitting every frontend equally well. Teams wanted to move faster on channel-specific UX without pushing that complexity into every client or every domain service. BFF emerged from that mismatch.
Each client type calls its own BFF. The BFF orchestrates internal services, shapes the response for that channel, and may apply channel-specific policies. It should remain an experience-composition layer rather than turning into a second domain core.
API Gateway is the common front door for shared entry policies, while BFF is a channel-specific composition layer behind or alongside that door. Gateway centralizes common concerns; BFF specializes for one experience. If you only have one client or very similar client needs, BFF may be unnecessary extra structure.
BFF is especially useful for rich composite screens, different web/mobile payload needs, and frontend teams that need freedom to evolve quickly. It often sits in front of many internal services and can simplify clients dramatically. The discipline is to keep domain rules in the core services rather than duplicating them across BFFs.