BFF, REST & GraphQL — Owning the Client Data Layer

1 The problem: a chatty client talking to many services

In a microservices world there is no single "backend" — there are dozens of small services (search, pricing, reviews, availability, loyalty…). If the browser talks to them directly, three pains appear, and they're the exact pains you've already met under other names:

• Under-fetching → waterfalls. One screen needs 5 services, so the client makes 5 (often sequential) round trips. This is the request waterfall from L09/L16 — devastating on high-latency mobile networks (the SEA market).
• Over-fetching → wasted bytes. A generic service returns 40 fields when the card needs 8. The client downloads and parses payload it throws away — a JS/bandwidth tax (L05).
• Leaky coupling. The UI now knows about 5 service shapes, auth schemes, and versioning timelines. Every backend refactor risks breaking the client, and secrets/tokens are exposed in the browser.

2 What a BFF actually is

A Backend for Frontend is a thin server-side layer that exists to serve one specific frontend experience. It sits between your UI and the microservices, calls them on the UI's behalf (over the fast internal network), and returns a single response shaped exactly for that screen. The pattern came out of SoundCloud — Phil Calçado and Sam Newman named it in 2015 — when one monolithic API couldn't serve a web UI and a mobile app whose needs sharply differed.

Two words carry the whole definition, and they're what separates it from a generic gateway:

3 BFF vs API Gateway vs direct-to-services

These get conflated constantly — distinguishing them cleanly is a quick credibility win. A BFF is a kind of API gateway, but a specialised one: one per client experience, rather than one shared edge for everybody.

They're not exclusive — a common production layout is a shared gateway for global concerns in front of per-client BFFs (Microsoft Azure Architecture Center).

4 What the BFF does for you — five jobs

1. Aggregate — fan out to N services in parallel inside the datacenter (sub-millisecond hops) and return one payload. Kills the client waterfall.
2. Shape & trim — return exactly the fields this screen needs, in the structure it wants. No over-fetching, less client-side transformation.
3. Orchestrate — encapsulate "call A, then B with A's result" sequencing on the fast internal network instead of across the public internet.
4. Secure — the BFF holds secrets and talks to services with privileged credentials; the browser never sees them. This is the token-handler pattern: the opaque/refresh token lives server-side in the BFF, the browser only gets an HttpOnly cookie (ties directly to L18's XSS-vs-CSRF storage triangle).
5. Degrade gracefully — when one downstream service 503s, the BFF decides the fallback (return the hotel card minus price) so the UI gets a coherent partial response instead of orchestrating failure itself.

// One call from the browser → parallel fan-out server-side → one shaped response
app.get('/bff/hotel-page/:id', async (req, res) => {
  const [hotel, price, reviews] = await Promise.allSettled([   // parallel, not waterfall
    getHotel(req.params.id),
    getPrice(req.params.id, req.user),   // privileged creds stay here — never reach the browser
    getReviews(req.params.id),
  ]);
  res.json({
    name:   hotel.value.name,
    price:  price.status === 'fulfilled' ? price.value : null,  // degrade, don't fail
    rating: reviews.value?.avg,
  });
});

5 REST BFF vs GraphQL BFF — same topology, different contract

Now that you know what a BFF does, the question that trips up interviews: "Why BFF instead of GraphQL?" The correct answer is that this is a false choice — they operate at different levels:

The five BFF jobs don't change. What changes is how the browser expresses what it needs and how the contract is typed:

// REST BFF — fixed shape per screen, server decides fields
app.get('/bff/hotel-page/:id', async (req, res) => {
  const [hotel, price, reviews] = await Promise.allSettled([
    getHotel(req.params.id), getPrice(req.params.id, req.user), getReviews(req.params.id)
  ]);
  res.json({ name: hotel.value.name, price: price.status==='fulfilled' ? price.value : null, rating: reviews.value?.avg });
});

// GraphQL BFF — identical fan-out, but the client picks which fields it needs
const resolvers = {
  Query: {
    hotel: async (_, { id }, { user }) => {
      const [hotel, price, reviews] = await Promise.allSettled([
        getHotel(id), getPrice(id, user), getReviews(id)
      ]);
      return { name: hotel.value.name, price: price.value, rating: reviews.value?.avg };
    }
  }
};
// Detail page: query HotelPage($id:ID!){ hotel(id:$id){ name, price, rating } }
// List card:   query HotelCard($id:ID!){ hotel(id:$id){ name, price } }
// Same BFF, same fan-out — client declares exactly what it needs per call

6 What to reach for first — and the upgrade triggers

The question isn't "BFF or GraphQL" — it's which contract on top of your BFF topology, and when does the topology itself need to change?

Start with REST BFF when…

• Stable, well-defined screen shapes — you know what each page needs; a fixed endpoint shape is fine.
• HTTP caching matters — hotel-list pages, search results, public content. GET endpoints are CDN-cacheable without extra plumbing; GraphQL over POST is not.
• Team is new to owning a server layer — shipping fast beats schema elegance; REST has zero learning curve.
• Simple production debugging — curl-able URLs beat a query playground during an incident.

Upgrade the contract to GraphQL BFF when…

• Field-selection pain — different page components need different subsets of the same resource and you're proliferating one-off REST endpoints to serve each combination.
• Data is highly relational — hotel → rooms → pricing → promotions, and different pages traverse the graph differently.
• 3+ clients with divergent shapes — web, native, and partner widget all need the same data but structured differently; per-query field selection removes the need for per-client endpoint variants.

Move to GraphQL Federation when…

• BFF sprawl — web, iOS, Android, partner-widget BFFs all re-implement the same composition. Federation gives each domain team a subgraph; a gateway composes them into one shared supergraph.
• Domain ownership at scale — the hotel team deploys their subgraph independently; the pricing team deploys theirs.

7 The modern angle: your SSR server is a BFF

With SSR and React Server Components (L09), the framework's server layer already plays the BFF role: a Next.js Route Handler, a server action, or an RSC fetching data on the server is doing exactly the BFF's five jobs — aggregating services, holding secrets, shaping the response, and owning degradation. RSC takes it furthest: the component fetches and renders on the server, so the data-shaping layer and the UI that consumes it are the same code, and zero aggregation JS reaches the browser.

This means: in a Next.js stack, you don't need a separate BFF tier for the web surface. You'd only add a dedicated BFF for a client that doesn't go through that server — a native app, a partner API, a CLI tool.

8 The costs — and keeping it thin

A BFF is not free. The Lead-level answer names the downsides without being asked:

• On the critical path — if the BFF is down, the UI is down. You own its availability, not just its API shape.
• Duplicate logic across BFFs — web and mobile BFFs often re-implement the same composition. Sam Newman's guidance: share via downstream services or libraries, not by merging BFFs back into one (that's the one-size-fits-none monolith again).
• Mini-monolith risk — the moment you push business logic (pricing rules, loyalty tiers, tax calculation) into the BFF it becomes a fat monolith that duplicates domain knowledge across surfaces. Keep it a thin shaping/orchestration layer; rules belong in the domain services.
• BFF sprawl — at scale you can end up maintaining dozens, each subtly diverging.

9 Platform Lead synthesis — the full answer

How to land all of this in the room in one confident answer:

"I'd put a BFF per surface — web and native have very different payload budgets. It collapses the hotel-page waterfall into one datacenter-side fan-out, trims responses to what each card needs, holds the auth tokens server-side so nothing sensitive reaches the browser, and owns graceful degradation when pricing flakes. In our Next.js stack the Route Handlers and Server Components are that BFF — no separate tier needed for web. I'd start with a REST contract: screen shapes are stable, GET endpoints are CDN-cacheable, and we ship fast. I'd switch to a GraphQL contract when field-selection proliferation kicks in. And if we hit BFF sprawl across many surfaces, that's the specific trigger for GraphQL Federation — keeping each domain team's subgraph independent. The key thing: BFF and GraphQL aren't alternatives; GraphQL is just a contract you put on top of the BFF topology."

10Check yourself — scenario quiz