BFF · REST · GraphQL — Client Data Layer

FE Lead · Lesson 25 — print before the round

Open with — the reframe that wins the interview

"BFF is a topology — a server-side layer owned by the FE team that aggregates microservices and returns a UI-shaped response. REST and GraphQL are contracts — how the browser talks to that layer. A GraphQL server that aggregates services for one UI IS a BFF with a GraphQL interface. They're not alternatives. I'd start with a REST BFF (stable shapes, GET caching, zero learning curve), switch to a GraphQL contract when field-selection proliferation kicks in, and move to Federation when I have BFF sprawl."

The three patterns

Pattern	What it is	BFF?
REST BFF	HTTP endpoints per screen, FE-owned	✓ Yes
GraphQL BFF	GraphQL schema, FE-owned, aggregates services	✓ Yes
Federation	Domain subgraphs → shared supergraph, shared by all clients	Not per-client

Common production stack: shared Gateway (global concerns) → per-client BFF → microservices.

REST BFF vs GraphQL BFF

	REST	GraphQL
Field selection	Server-fixed	Client-per-query
HTTP caching	Native (GET/CDN)	Harder (POST)
New data need	New endpoint	Add to query
N+1 risk	Endpoint-level	Resolver (DataLoader)
Debugging	`curl` URL	GraphiQL/Sandbox
Learning curve	Low	Higher

Five BFF jobs (aggregate / shape / orchestrate / secure / degrade) are identical either way.

BFF five jobs (contract-agnostic)

Aggregate — parallel fan-out inside datacenter, one payload.
Shape/trim — exactly the fields this screen needs.
Orchestrate — "call A then B with A's result" on the fast internal net.
Secure — token-handler: real token in BFF, browser gets HttpOnly cookie (L18).
Degrade — one service 503s → BFF returns coherent partial (hotel card minus price).

Decision: what to reach for first

Stable screen shapes, team new to server layer, HTTP caching matters (public pages) → REST BFF

Clients need different field subsets from same resource; REST endpoints proliferating → GraphQL BFF

Highly relational data; multiple clients traverse graph differently → GraphQL BFF

Multiple BFFs duplicating the same composition (sprawl) → GraphQL Federation

Domain teams want to own and deploy their schema slice independently → GraphQL Federation

Modern angle: SSR/RSC server IS the BFF

Next.js Route Handlers + Server Components aggregate services, hold secrets, and ship UI-shaped data. That's the BFF role. No separate tier needed unless you have a second client (native) that doesn't run through that server.

RSC takes it furthest: data layer + view in one place, zero aggregation JS to the browser.

GraphQL Federation at scale

Domain teams own subgraphs composed into one supergraph. Each client queries what it needs — no per-client aggregation. SoundCloud migration: ~86% less compute, ~45% better latency. Trade-off: adds a graph platform + governance layer to run.

Don't add Federation until you have the sprawl. Don't merge BFFs into one (one-size-fits-none monolith).

Don't fail the interview — traps & recoveries

"BFF vs GraphQL" is a category error. BFF = topology; GraphQL = contract. A GraphQL BFF is both at once. If an interviewer pushes back on BFF with "why not GraphQL?", reframe: they're not mutually exclusive — you choose the contract independently of the topology.
Don't add a BFF tier in an SSR/RSC stack by reflex. Your server layer already does the job. Add one only for a client that doesn't run through that server (e.g., native).
Keep it thin. Business logic in the BFF = mini-monolith + duplicated rules across web/mobile BFFs. Rules belong in domain services.
REST first, GraphQL when it hurts. The specific pain: clients need different field subsets from the same resource and REST endpoints are proliferating. Don't add GraphQL before you feel this.
Sprawl → Federation, not merged BFF. Merging BFFs re-creates the one-size-fits-none monolith. Federation = domain subgraphs in a shared graph.
It's on the critical path. BFF down = UI down. Own its availability, not just its API contract.

Memorize — one paragraph that survives pushback

BFF = topology (FE-owned, aggregates microservices, server-side). REST/GraphQL = contract. · Start REST BFF: stable shapes, GET caching, fast ship. · Switch to GraphQL BFF: field-proliferation pain, relational data. · Federation: BFF sprawl, domain subgraph ownership. · SSR/RSC server = your BFF. · Token-handler: real token in BFF, HttpOnly cookie to browser (L18). · Keep it thin. · SoundCloud: BFF → Federation (86% compute ↓, 45% latency ↓).