Backends for Frontends Pattern
Backends for Frontends: start from the problem
See the responsibilities
A mobile screen needs a small order summary, while an administrative web page needs more detail. One general response may force every client to fetch and discard extra fields or make many requests.
This is a service boundaries pattern lesson. Follow the responsibilities, inspect the small JavaScript example and compare the design choices. The example is local teaching code; its boundary is explained before you apply the idea to a real service.
What you’ll learn
- Explain the problem Backends for Frontends addresses and the roles involved.
- Follow the example and distinguish this pattern from nearby alternatives.
- Choose when the benefit justifies the extra responsibilities and testing.
How the responsibilities work
Backends for Frontends gives a client experience an appropriate server-side interface. It can shape and aggregate data for that experience while domain services retain their business ownership. The boundary follows meaningful client needs rather than one backend per device model.
The local example gives a mobile client only an order identifier and status from a larger record. A real BFF needs authentication, resource authorization, dependency deadlines and compatible response evolution.
Follow a small example
Read the JavaScript from top to bottom and compare the expected output. The values are chosen to make this pattern’s responsibility visible. This example runs in one local execution context; it does not create remote services, durable storage or production access controls.
JavaScript · local teaching example
const order = {id: 'O1', status: 'ready', internalNote: 'warehouse route'};
function mobileSummary(record) { return {id: record.id, status: record.status}; }
console.log(JSON.stringify(mobileSummary(order)));Expected output
{"id":"O1","status":"ready"}Choose a design and inspect the consequence
Compare the design choices
Compare the visible consequences. With JavaScript enabled, choose an option in each scenario to assemble your decision record.
This is an exploratory design exercise. It does not run infrastructure, measure capacity or replace the lesson’s quiz.
Apply the pattern to two situations. Select one option in each situation to build a decision record. Every option and its consequence stays visible, and you can change your choices.
When it helps—and what it costs
Use it when client experiences have substantial different data and interaction requirements. A shared backend can be better when those requirements mostly align.
Multiple BFFs can duplicate orchestration and diverge in access policy. Keep core business rules with their owners and coordinate schema evolution. A smaller payload is not permission to expose private fields.
Distinguish the neighbouring patterns
Gateway Aggregation focuses on combining service responses. A BFF focuses on a client experience and may use aggregation. Facade is a simpler subsystem interface and does not require a network service.
Follow aggregating service responses, a focused subsystem interface, REST, GraphQL and client contracts to compare the specific responsibility before combining patterns.
For further reading, use Microsoft’s Backends for Frontends guidance. Compare it with this original example and the guarantee required by your application.
Check your pattern reasoning
Check your pattern reasoning
Name the responsibility before choosing the pattern
For Backends for Frontends, describe the problem, the participating roles and the observable contract. Use the example as a starting point and test the boundaries identified in the trade-offs. A pattern name alone does not establish correctness or performance.
Return to the design-pattern guide to compare families, or apply the idea alongside REST, GraphQL and client contracts.
Reaching the recap and completing the quizzes are separate milestones.