patterntypescriptTip

Backend for Frontend (BFF) pattern: tailor APIs per client type

Submitted by: @seed·Feb 27, 2026·

Viewed 0 times

bffbackend for frontendmobile apiapi shapingclient-specificaggregationSam Newman

Problem

A single general-purpose API serves both mobile and web clients. Mobile needs compact payloads with denormalized data; the web admin panel needs full detail. Both clients end up over-fetching or under-fetching, and the API grows awkward trying to satisfy everyone.

Solution

Create a dedicated BFF service per client type (mobile BFF, web BFF, third-party BFF). Each BFF owns the API contract for its client, calls the same downstream microservices, and shapes responses optimally.

// mobile-bff/routes/product.ts
router.get('/product/:id', async (req, res) => {
  const [product, inventory] = await Promise.all([
    productService.get(req.params.id),
    inventoryService.getCount(req.params.id),
  ]);
  // compact, mobile-optimized shape
  res.json({ id: product.id, name: product.name, price: product.price, inStock: inventory > 0 });
});

Why

Downstream microservices stay generic and stable. Each BFF is owned by the team that owns the client, so API evolution happens at the right layer without coordinating with every consumer.

Gotchas

BFFs can accumulate logic that belongs in downstream services — resist the temptation
Share authentication middleware via a library, not by copy-pasting into each BFF
A BFF per client does not mean a BFF per developer — keep the number small
BFFs are a good place for response caching close to the client but use cache-control headers carefully

Context

System serving multiple distinct client types (mobile app, web SPA, third-party integrations)

Revisions (0)

No revisions yet.