Start with different needs
A mobile product list, a web detail page and an administrative interface may need different shapes of data. A Backend for Frontend, or BFF, gives an interface a server-side contract tailored to its tasks and release cycle.
This can reduce coordination around a shared API, but separate backends are not required merely because two screen sizes exist. A shared API with suitable projections or query capabilities may already serve both clients well. Microsoft describes the BFF pattern and its operational tradeoffs. Backends for Frontends.
An example contract
Consider a hypothetical store. Its mobile list needs an identifier, display name, price summary and thumbnail. Its web detail page adds description, availability and related products. The administrative page exposes editing operations to authorized staff.
A mobile BFF can return the list projection without downloading and forwarding every catalog field. A web BFF can assemble detail data. Both still call the same authoritative catalog and ordering capabilities.
Avoid defining permissions only by the client that sent the request. A mobile endpoint is not automatically less privileged, and an admin URL is not proof of an administrator's identity.
Decide what belongs in the layer
Client-specific formatting, response composition and input-shape validation fit naturally in a BFF. Authoritative rules such as who can alter an order, how a price is calculated and whether a purchase may proceed belong in the owning domain service.
Validation is therefore not forbidden in the BFF. It should reject malformed input early while the domain layer enforces the business invariant regardless of which client invokes it.
Keep the contract small enough to describe clearly. If changing a shipping policy requires separate business-rule edits in three BFFs, the boundary is probably wrong.
Sessions and upstream access
A browser BFF may hold upstream credentials on the server and expose a session cookie to the browser. That design still needs appropriate cookie attributes, CSRF protection, session expiry and server-side authorization. The BFF pattern itself supplies none of those automatically.
Mobile clients can have different authentication constraints, but refresh lifetimes should follow the actual security model rather than a blanket rule that mobile tokens are long-lived.
Never put a privileged upstream key in browser JavaScript to make the integration simpler.
Make partial failures deliberate
Aggregation adds dependencies to a single response. Define which fields are mandatory, which may be unavailable and how the client distinguishes “empty” from “failed to load.” Set deadlines and avoid retrying the same failing service from several layers. Gateway aggregation considerations.
For example, a missing recommendation list may be acceptable. An unknown order total is not a valid successful checkout summary. Preserve that distinction in the response type and UI.
Choose a deployment boundary
A BFF may live in an existing server application or as a separate service. Server-rendering code can perform composition, while an HTTP endpoint provides a network contract; those are related but different interfaces.
Before splitting services, compare the extra deployment, monitoring and ownership work with the coordination problem being solved. Test contracts with recorded or synthetic upstream responses, including unauthorized access, missing fields and slow dependencies. The result should be a clearer client boundary with fewer hidden assumptions.
Sardar Mukhshaf
Full-Stack & DevOps Engineer
I build scalable web applications, secure backend systems, and production-ready cloud infrastructure. My engineering focus spans interface design, API architecture, deployment pipelines, and observability. Follow for more deep dives into system architecture, performance engineering, and emerging technologies.
More from the practice
Keep the useful ideas close.
Follow new articles with your preferred RSS reader.
Open the RSS feed ↗
