BFF Pattern in Production: GraphQL, tRPC, Edge (2026)

Q: What is the difference between a BFF and an API gateway?

An API gateway and a BFF solve different problems and almost every production estate needs both. The gateway is a single edge tier that authenticates incoming traffic, rate-limits across all clients, applies WAF rules, routes to the correct downstream, and emits one normalised observability stream. It is shared by every client, every service, every BFF — there is one gateway, not one per client. A BFF is the opposite shape: per-client-experience, behind the gateway, owned by the client team, aggregating a small number of upstream services into a client-shaped response. The gateway routes; the BFF aggregates. The gateway speaks every transport; the BFF speaks the one transport its client wants. The gateway authenticates against the issuer; the BFF terminates the session and mints per-service tokens. The classic confusion is to call the gateway a BFF or to put per-client logic in the gateway; both regress the architecture toward a single fat tier that owns everything. The discipline is to keep them separate: the [API gateway pattern](/en/blog/microservices-pattern-api-gateway-in-production-2026) handles cross-cutting edge concerns; BFFs handle per-client composition.

Q: Should I have one BFF per channel or one per client experience?

Per *client experience*, not per channel. Counting channels (iOS, Android, web, partner) and provisioning a BFF per channel is one of the most common adoption mistakes — a team ends up with three near-identical BFFs that drift over six months because no single team owns the cross-channel contract. The right unit is the *experience*: iOS and Android are usually one experience because they share product behaviour and only differ in transport, so they share a mobile BFF; web SSR is a different experience because its latency budget, security boundary, and rate of change differ from mobile; the partner B2B API is a third experience for the same reason; an AI agent client is increasingly a fourth. The signal that two channels are the same experience is whether the client team can write down a single contract that serves both with at most cosmetic transport differences. The signal they are different experiences is whether the contract changes — different fields, different auth, different latency SLA, different security boundary. Within reason, fewer BFFs is better; the operational cost of each BFF is real, and most products converge on two to four BFFs at maturity, not eight.

Q: Should I use GraphQL Federation, tRPC, or REST for my BFF?

Per client-shape, not per organisation. GraphQL Federation v2 (Apollo, Cosmo, Hive) is the right shape when there are five or more subgraphs, three or more client experiences sharing entity types, and a dedicated platform team to operate the router — typically rich web applications with deep relationship graphs, persisted queries in production, and a schema-registry CI gate. The operational tax is real: GraphQL has a learning curve that does not amortise unless the team is large, and the "one big query" pattern collapses when a single field is slow because the entire response waits. tRPC is the dominant 2026 shape for full-stack TypeScript teams using Next.js / Nuxt / Remix / Astro / SvelteKit — end-to-end type safety with zero schema drift, but only when the client and BFF are both TypeScript; it cannot serve iOS, Android, or partner consumers. REST / JSON BFFs are still the right answer for mobile, partner-API, and AI-client BFFs — lowest learning curve, easiest onboarding, cleanest observability, lowest operational tax — paired with OpenAPI 3.1 + a CI gate that rejects backward-incompatible changes. Mixed estates are normal and correct: a single product can run a tRPC web BFF, a REST mobile BFF, and a federated GraphQL partner BFF without contradiction.

Q: When does an Edge BFF beat a regional BFF?

When three things are simultaneously true. First, the user population is globally distributed and TTFB is measurable in user-experience metrics — if users are within 100 ms of one regional datacentre, the edge buys nothing. Second, upstream services have a regional read replica or an edge-friendly cache (CDN-fronted catalog, global Spanner / Aurora Global, [multi-region read-replica pattern](/en/blog/microservices-pattern-multi-region-read-replication-2026)) — an edge BFF that calls a single-region upstream loses everything it gained at the edge by paying the full WAN round-trip per request. Third, the BFF code respects edge-runtime constraints: no long-lived connections, no native modules, request-CPU budgets in 50–200 ms, no large heaps. When all three hold, the edge BFF wins by 60–200 ms TTFB for global users, the static-asset path is co-located with the dynamic path, and SSR cold-start is effectively zero. The hybrid pattern that has emerged in 2026 is the most common production shape: edge BFF terminates the request, performs auth, reads from edge cache for the steady-state 95% of traffic, and falls back to a regional BFF for the long-tail write path. This composes cleanly with [the cache-aside CQRS pattern](/en/blog/microservices-pattern-cache-aside-cqrs-2026).

Q: Who should own the BFF — the client team or a platform team?

The client team. This is the single most consequential organisational decision in the BFF pattern, and the one most often gotten wrong. When a platform team owns BFFs, the BFFs become a queue: every iOS feature waits behind every Android feature, the iOS team has no autonomy, and the platform team becomes the bottleneck the architecture was meant to remove. When a separate "BFF team" owns BFFs, the team has no consumers — it builds aggregations no one asked for, drifts from the client’s actual needs, and becomes a fiefdom that survives reorgs by accreting scope. The correct shape is that the iOS team owns the iOS BFF, the web team owns the web BFF, the partner-API team owns the partner BFF; each BFF lives in the client team’s repo or a dedicated repo the client team has commit rights on. The platform team owns the *runtime* (Kubernetes cluster, edge platform, deploy pipeline, observability spine) and the *standards* (auth pattern, schema-registry policy, rate-limit defaults). The client team owns the *code* and the *roadmap*. This is also why BFFs in 2026 trend toward small, opinionated, single-purpose codebases readable in an afternoon — a 30,000-line BFF means business logic has leaked in and a domain service is missing upstream.

Q: How should the BFF handle authentication and authorisation?

Session-at-the-BFF, short-lived service tokens downstream. The client holds an opaque session cookie or refresh token; the BFF terminates that session, looks up the principal, and exchanges it for a short-lived per-service token (a 5-minute JWT or an [OAuth 2.0 token-exchange grant](https://www.rfc-editor.org/rfc/rfc8693.html)) before fanning out to upstream services. The client never sees the per-service tokens; the upstream services never see the client session. This pattern matters for three reasons. First, the blast radius of a leaked client token is bounded — the client token is opaque and only the BFF can act on it; per-service tokens are short-lived and scoped, so a compromised one expires before exfiltration matures. Second, the BFF is the single point where rotation, revocation, and step-up authentication happen — when the user re-authenticates for a high-risk action, the BFF mints a tighter scope and the upstream services do nothing differently. Third, the upstream services authenticate every call against a service-to-service identity (workload identity via [SPIFFE / SPIRE](https://spiffe.io/) or cloud-native equivalents), which is a precondition for any zero-trust posture. The classic mistake is to forward the client’s token unchanged; every upstream service is now in the client’s threat model, and the BFF reduces to a value-less proxy.

Q: How should fan-out and partial failure be handled at the BFF?

Parallelise wherever data dependencies permit; apply per-call deadlines that sum to less than the BFF’s own deadline; tolerate partial failure with sensible defaults; bulkhead per upstream. A BFF that aggregates five upstream services on every request multiplies the failure rate by five if calls are sequential and by approximately one (the slowest one) if calls are parallel and partial failure is tolerated. The naive sequential implementation is the single most common BFF performance failure: an order-detail page that needs order, customer, shipping, recommendations, and reviews must fan out all five in parallel under a single deadline, sequencing only what genuinely depends on previous results. Per-call deadlines are arithmetic: an 800 ms p99 BFF response budget means each upstream gets 600–700 ms, never 800. Partial failure tolerance is per-upstream: if recommendations time out, the page returns without the recommendations rail and a structured `partial` flag rather than failing the whole response — the BFF is the natural place to encode [graceful degradation](/en/blog/microservices-pattern-graceful-degradation-2026) because only the BFF knows the client’s tolerance for missing data. [Bulkheads](/en/blog/microservices-pattern-bulkheads-isolation-failure-2026) per upstream service — separate connection pools, per-upstream circuit breakers, per-upstream queue depths — prevent one slow upstream from cascading across every client experience the BFF serves.

Q: When should the BFF cache responses, and what should the cache key include?

The BFF should cache only when the same composition is requested by many clients (a hot product page) and upstream services cannot cache as cheaply — cache aggregations, not single-service reads that the upstream already caches. The cache key must include every dimension on which the response varies: the user’s locale, currency, time-zone, feature-flag bundle, A/B segment, auth scope, role, tenant, and any personalisation signals. A cache key that omits any of these is a privacy bug — user A’s response served to user B — not a performance win. The TTL is short and the invalidation strategy is explicit: event-driven invalidation when an upstream emits a change event, time-based fall-through for the long tail, and an "always include in stale-while-revalidate window" rule for hot paths so a cache miss never blocks the user. For multi-region edge BFFs, the cache is per-PoP with replication via the underlying KV store; for regional BFFs, an in-process cache plus a Redis tier handles 99% of need. The deeper retrieval-cache discipline applies to AI BFFs as well — see [the retrieval cache hierarchy pattern](/en/blog/ai-service-pattern-retrieval-cache-hierarchy-embedding-bm25-dense-rerank-response-2026) and [the semantic cache pattern](/en/blog/ai-service-pattern-semantic-cache-when-it-helps-when-it-lies-2026) for the AI-specific cases.

Q: How does the BFF handle streaming, SSE, and WebSocket connections?

The BFF terminates the streaming connection from the client and translates it into the right downstream shape — SSE for chat / log tail / progress, WebSocket for bidirectional collaboration, HTTP/2 chunked for partial-response APIs. The BFF is the natural place because it already owns session and the client speaks one transport per experience. The composition discipline is that the BFF holds the SSE connection to the client, opens a streaming call to the upstream model or service, propagates back-pressure via the writable-stream drain, propagates cancellation via AbortController, and dedupes reconnects via X-Request-ID + Last-Event-ID — the [streaming LLM response pattern](/en/blog/ai-service-pattern-streaming-llm-response-sse-websocket-structured-output-2026) covers this in detail. Two production constraints dominate. First, every layer between the BFF and the client must explicitly disable proxy buffering: X-Accel-Buffering: no, NGINX proxy_buffering off, the corresponding ALB attribute, Front Door / GCP LB equivalents — proxy buffering is the single most common cause of "the stream works locally but stalls in production". Second, for voice and bidirectional flows, the BFF runs a session-affinity-aware WebSocket endpoint backed by Redis sessions or Cloudflare Durable Objects on the edge; the connection holds translation state, but a connection drop and reconnect must be replayable from upstream truth, never from BFF-only state.

Q: What is the AI BFF, and how does it differ from a chat product?

An AI BFF is a typed surface that an AI agent client talks to — a tool catalogue, terminated model session, fan-out to the same domain services the human-facing BFFs use, and a response shape the model can consume (typed tool-call schemas, structured output, citation-bearing JSON). It is not a chat product. It is a *client experience* with its own contract, distinct from web, mobile, and partner. The architectural rule that defines BFFs generalises here: a BFF is whatever translates the upstream estate into one client’s contract, including when the client is a model. The discipline is identical — no business invariants, no persistence beyond ephemeral session state, owned by the team that ships the AI feature — and the implementation differs mostly in transport (typed tool calls vs HTTP routes), error shape (machine-actionable codes vs HTTP status), and observability (per-tool-call OTel spans vs per-route HTTP metrics). The composition with existing AppScale AI patterns is straightforward: [tool-calling schema design](/en/blog/ai-service-pattern-tool-calling-schema-design-llm-agents-2026) for the catalogue contract, [the enterprise LLM gateway](/en/blog/enterprise-llm-gateway-architecture-routing-rate-limiting-observability-2026) for routing/rate-limiting/observability, [classification-first architecture](/en/blog/microservices-pattern-classification-first-architecture-2026) for cheap-route-first, [PII redaction](/en/blog/pii-redaction-pipeline-llm-presidio-ner-reversible-tokenisation-2026) at egress. The AI BFF is the natural place to enforce all of these together.