Backend for Frontend (BFF)

The One-Size-Fits-None Problem

 one shared API serving all clients serves none well:

 mobile:   needs tiny payloads, few round trips, offline tolerance
 web app:  wants rich payloads, fine-grained updates
 partners: need stable versioned contracts, bulk access

 forcing one shape:
 - mobile over-fetches fields it can't afford (battery/data)
 - web under-serves its richness, hacks around
 - every client's wish-list argues in ONE backlog

 BFF PATTERN: one backend PER frontend experience,
 owned BY that frontend's team:

 [mobile]──►[mobile-BFF]──► services
 [web]────►[web-BFF]─────► services
 [partners]►[partner-API]─► services

What Lives in a BFF

 □ AGGREGATION: compose orders+profile+recs into the exact
   screen-shape the client renders (one round trip!)
 □ PAYLOAD SHAPING: field selection per device class
 □ PROTOCOL ADAPTATION: graphql for web? grpc-web? rest for all?
 □ CLIENT-SPECIFIC CACHING + retry/posture tuning
 □ EXPERIMENT/feature-flag logic tied to that surface

 what does NOT live there:
 ✗ domain/business rules (stay in SERVICES)
 ✗ data ownership (BFFs hold no system-of-record)
 BFF = translation-and-composition layer. thin by design.

 ownership rule that makes it work:
 the FRONTEND team owns its BFF.
 changes ship on the frontend's cadence without
 negotiating with platform teams. autonomy preserved.

The Costs and Guards

Cost	Guard
N backends to run	keep them stateless/thin; shared template
logic creeping into BFFs	reviews enforce thinness; services expose richer APIs instead
duplicated composition across BFFs	accept some; extract only PROVEN common parts
more deploy units	they’re small; automation carries it

 the creep failure mode deserves vigilance:
 "just one if-statement for business rules" in the BFF →
 six months later domain logic lives in three BFFs and
 services became CRUD shells. name the smell early:
 BFFs translate; they never DECIDE.

When BFFs Earn Their Keep

 ✓ genuinely divergent client needs (mobile vs web vs partners)
 ✓ separate teams owning separate surfaces
 ✓ aggregation round-trips measurably hurt UX

 skip when:
 ✗ one client type only (a plain gateway suffices)
 ✗ clients are simple consumers of uniform resources
 ✗ team count too small to own the extra units

 evolution note: graphql deployments often play the BFF role
 (clients shape queries) — same architectural slot,
 different technology. judge by properties, not buzzwords.

Interview Framing

“Mobile team complains: 6 calls and 10× payload per screen” scored answer: BFF pattern introduced FOR their surface, screen-shaped aggregation endpoint shown, ownership-assigned-to-frontend-team point made, thinness boundary stated explicitly, gateway-vs-BFF distinction clarified (policy layer vs experience layer). This question rewards knowing WHERE composition belongs — and where it must never drift.