Backend-for-Frontend and Experience-Oriented APIs

Backend-for-frontend patterns are useful when different clients need different response shapes, caching behavior, or composition logic. A mobile app may need compact responses and fewer round trips. A web UI may need broader aggregated data. A partner endpoint may need a different contract entirely. Serverless functions are often a good fit for this pattern because they can live close to the HTTP edge, scale with demand, and keep experience-specific orchestration separate from the deeper domain services behind them.

The strongest use of a BFF is to tailor experience, not to duplicate the whole backend. If the BFF starts owning business truth or inventing its own independent domain rules, it becomes an accidental fork of the platform instead of an experience-oriented boundary.

    flowchart LR
	    A["Mobile client"] --> B["Mobile BFF"]
	    C["Web client"] --> D["Web BFF"]
	    E["Partner client"] --> F["Partner API"]
	    B --> G["Shared domain services and data"]
	    D --> G
	    F --> G

What to notice:

• clients may need different API shapes even when the underlying domain is shared
• the BFF is a composition and adaptation layer, not a replacement domain
• separating client-facing concerns can reduce accidental coupling between frontend needs and core services

Why Serverless Fits the BFF Pattern

Serverless is often a natural fit because:

• different clients can have separate entry points and deploy independently
• traffic may differ significantly by client type
• the functions can aggregate, tailor, and reshape responses without requiring a full persistent application tier per experience

This is especially useful for:

• mobile-specific payload trimming
• partner-specific response contracts
• lightweight aggregation across a few domain services
• response caching tailored to one client experience

What the BFF Should Own

A healthy BFF usually owns:

• client-specific response shape
• experience-specific aggregation
• edge-adjacent validation and representation concerns
• client-appropriate caching or routing choices

It should not usually own:

• authoritative business state
• duplicated domain rules that already live in core services
• complex cross-client workflow semantics that belong deeper in the system

Example: Web vs Mobile Response Shaping

1routes:
2  - GET /mobile/orders/{id}
3    function: mobile-order-view
4  - GET /web/orders/{id}
5    function: web-order-view

 1export async function mobileOrderView(orderId: string) {
 2  const order = await orderService.get(orderId);
 3
 4  return {
 5    id: order.id,
 6    status: order.status,
 7    total: order.total,
 8  };
 9}
10
11export async function webOrderView(orderId: string) {
12  const [order, shipment, payments] = await Promise.all([
13    orderService.get(orderId),
14    shipmentService.getForOrder(orderId),
15    paymentService.getForOrder(orderId),
16  ]);
17
18  return {
19    order,
20    shipment,
21    payments,
22  };
23}

This is a healthy pattern if:

• both functions still depend on shared domain truth
• the difference is mainly representation and composition
• experience-specific latency or caching trade-offs are explicit

Where It Goes Wrong

BFF patterns become weak when:

• each client boundary reimplements core business logic differently
• the BFF becomes the only understandable system boundary
• several client-specific functions call too many backend services and create chatty request paths
• teams use BFFs as a justification for ad hoc duplication

The pattern should improve separation, not multiply backend inconsistency.

When a Single API Is Better

Not every system needs several BFFs. If the clients are similar enough and one stable API contract works, a single API surface may be cleaner. Create a BFF when the experience differences are real, not because the pattern sounds modern.

Design Review Question

A team wants separate mobile, web, and partner serverless APIs. Each one will re-implement pricing rules, order eligibility logic, and customer-state interpretation “so each client can move faster.” Is that a strong experience-oriented design?

Usually no. The stronger answer is that the experience boundary should tailor representation and composition, not fork core business meaning. If the BFF starts owning major domain rules independently, the system is likely to drift into inconsistent behavior across clients.

Check Your Understanding