BFF

The BFF block gives a front end one endpoint per screen. Instead of a page making six calls across IAM, the Data API and Content and assembling the result in the browser, it makes one call to a BFF endpoint that does the stitching server-side.

Why

A rich screen usually needs data from several services. Doing that assembly in the client has three costs that compound:

• Latency multiplies on bad networks. Six sequential round trips on mobile is a visible delay; one is not.
• The front end learns your backend topology. Every client — web, iOS, Android — encodes which services exist and how they relate, so a backend change becomes a coordinated release across all of them.
• Over-fetching becomes the default. Clients pull whole entities to display three fields, because narrowing the response means another backend change.

A BFF endpoint is defined declaratively: which calls to make, how to combine them, what shape to return.

Endpoints

GET /list      BFF endpoints defined for this product
GET /health    liveness
GET /ready     readiness

Product endpoints are declared per tenant and served from the same surface.

One BFF per client, not one per platform

The pattern’s original form is one BFF per client type — the web app’s needs differ from the mobile app’s, and forcing both through one endpoint reproduces the over-fetching you were trying to remove.

The failure mode to avoid is the opposite: a single “BFF” that accumulates every screen’s endpoint until it is a second application with its own business logic. Keep the stitching declarative. When an endpoint starts needing real branching, that logic belongs in a service — usually the Data API or a workflow.

See also

• API Stitching — composing several backend calls into one response