Backend for Frontend
A BFF translates between one client family and business APIs.
- Client familyShares interaction, network conditions, and release cycle.
- AdapterShapes and aggregates data for that family.
- Business boundaryLeaves prices, inventory, and payment with the responsible module.
Context
Why this is important
It pays off for measurably different client needs and clear ownership boundaries.
The mobile app and its BFF are hypothetical; the current shop has one web interface and seven modules.
Responsibilities at the client edge
The current shop has seven modules and a web interface in a modular monolith. A hypothetical mobile app needs smaller product images, a compact order summary, and fewer round trips; a Mobile BFF aggregates Catalog and Order for that purpose. The web interface continues to use its existing server-side adapter. Prices, reservations, and payment status are decided exclusively by the responsible modules. The team measures payload size, call count, and change rate before operating the additional service permanently.
This is how you read the picture
- Client family Mobile separate from web
- Adapter Client contract rather than internal APIs
- Business boundary No rule copies in the BFF
| Comparison | Task | BFF | Business module |
|---|---|---|---|
| Response shape | Client-oriented fields and image sizes | Yes | Provides authoritative source data |
| Aggregation | Fewer client round trips | Yes | Remains individually responsible |
| Price decision | Business rule and rounding | No | Catalog determines the price |
Benefits & limitations
Helps if:
- Clients differ substantially in interaction or network conditions.
- Separate teams and release cycles need independent client contracts.
- Aggregation demonstrably reduces round trips or payload.
Boundaries
- One BFF per minor client creates unnecessary services and operational overhead.
- Duplicated business rules drift across BFFs.
- Shared authentication and rate limits must remain consistent at the edge.
In practice
- Compare the order overview for web and mobile. Map each aggregated field to an existing domain owner so the BFF does not invent a second business rule.
- Change the mobile response shape and verify that the web interface remains independent. Observe whether shared changes still converge on one central API.
- Check whether distinct client needs justify a separate BFF. Include extra deployments, identity checks, and the risk of duplicated domain logic.
Read the detailed explanation
A mobile app, web interface, or partner portal can have different round trips, payload sizes, and release cycles. A dedicated BFF bundles these differences and keeps internal interfaces out of the client.
A BFF becomes problematic when it copies decisions about price, payment, or inventory. That creates multiple truths and coordinated releases; client-oriented formatting, aggregation, and access control remain appropriate tasks.
API Gateway forms the shared external entry. API Contracts keep stable business-provider boundaries used by each BFF.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
Which task typically belongs in a BFF?
View the solution with justification
Client-oriented aggregation and response shape.
ApplyingTransferred to a new situation
What remains in Catalog?
View the solution with justification
Pricing rules and authoritative product information.
EvaluateWeighing an alternative
When is another BFF unnecessary?
View the solution with justification
When clients share the same contract and similar network and release conditions.
Explore further
These building blocks continue the thoughts of this page.