API Stitching

Stitching is what a BFF endpoint does: call several backends, combine the results, return one response shaped for the screen that asked.

The shape of a stitched endpoint

An endpoint declares its upstream calls and how the response is assembled:

  GET /screens/order-detail?id=…
        │
        ├─▶ Data API      the order and its line items
        ├─▶ IAM           the customer's display name
        └─▶ Content       the returns-policy blurb for the order's region
                │
                ▼
        one response, shaped for the screen

Independent calls run in parallel, so the endpoint costs roughly the slowest upstream rather than the sum of all of them. That is most of the latency win — a client making the same calls sequentially pays the sum.

Field selection

Declaring which fields reach the client keeps the response to what the screen renders. This matters more than it looks: response size is the dominant cost on mobile, and the fields a screen does not display are pure waste that grows every time an upstream entity gains a column.

Failure handling

Decide per upstream whether a failure is fatal to the response or degrades it. A missing returns-policy blurb should not fail an order-detail screen; a missing order should.

Making that choice explicit per call is the difference between a BFF that improves perceived reliability and one that couples the availability of every screen to the availability of every service behind it.

Keep it declarative

Stitching is composition, not computation. When an endpoint needs conditional logic, derived values or writes across services, that is a sign the behaviour belongs in a service rather than in the assembly layer — see the note in BFF.