Backend for Frontend (BFF)

A BFF is developed and maintained by the same team responsible for the frontend. This eliminates cross-team dependencies and allows the frontend team to iterate on the API contract and data shaping logic at their own pace. One BFF per user interface—a mobile app, a web SPA, or a smart TV app each gets its own dedicated backend service.

The BFF acts as a translation layer between the frontend's specific needs and the general-purpose downstream microservices. It handles:

• Data Aggregation: Orchestrating calls to multiple services and merging responses into a single, cohesive payload.
• Protocol Bridging: Translating between frontend-friendly protocols like WebSockets and backend protocols like gRPC or message queues.
• Format Transformation: Converting verbose internal data models into the minimal, view-ready JSON structures the UI requires.

To keep client-side code thin and performant, the BFF absorbs complex non-visual logic. This includes:

• Session Management: Handling OAuth token refresh cycles and user context enrichment.
• Feature Flag Resolution: Evaluating toggles server-side to prevent layout shifts.
• Device-Specific Adaptation: Delivering optimized image URLs or truncated text based on the client's viewport and network conditions.

The BFF serves as a security boundary that is uniquely positioned to enforce client-specific access controls. It can:

• Token Mediation: Exchange a client-held public token for a privileged service token before calling downstream systems.
• Request Validation: Strip out extraneous or malicious fields from user input before forwarding requests.
• Data Masking: Redact sensitive fields like internal IDs or PII that are irrelevant to the specific frontend view.

Unlike a generic API gateway that might return a raw 500 error, a BFF implements graceful degradation strategies tailored to the user experience. If a downstream recommendation service fails, the BFF can return a cached default list or a static fallback JSON structure, allowing the frontend to render a partial but functional view instead of a broken page.

A BFF is not a replacement for an API Gateway. The gateway handles cross-cutting concerns like rate limiting, TLS termination, and global routing. The BFF sits behind the gateway and handles client-specific experience logic. Confusing the two leads to a bloated gateway that becomes a bottleneck for all frontend teams.

A centralized, single-entry point for all client requests that handles cross-cutting concerns like authentication, rate limiting, and routing. Unlike a BFF, which is client-specific, an API Gateway serves as a generic reverse proxy for an entire service mesh. It often routes to multiple downstream services but does not perform client-specific data aggregation or transformation.

• BFF vs. Gateway: A BFF sits behind the gateway, tailored to one UI
• Common tools: Kong, Apigee, AWS API Gateway
• Use case: Centralizing security policies across all clients

An architectural pattern where multiple subgraph services are composed into a single unified supergraph. A gateway (like Apollo Router) distributes incoming queries to the responsible subgraphs and assembles the response. This can serve a similar role to a BFF by allowing clients to request exactly the data they need in one round trip.

• Entity resolution: Subgraphs contribute fields to shared types via @key directives
• Contrast with BFF: Federation pushes query complexity to the gateway; BFFs handle it in custom server logic
• Best for: Organizations with multiple independent domain teams

A read-optimized, high-performance endpoint specifically designed to serve published content to public-facing applications. In a headless CMS architecture, the Content Delivery API provides structured JSON, but it is generic—it doesn't tailor responses to a specific client's view requirements.

• BFF integration: A BFF often calls a Content Delivery API, then reshapes the payload for a specific mobile or web view
• Caching: Heavily cached at the CDN edge, with cache invalidation triggered on content updates
• Example: Contentful's CDN API delivering blog post entries as raw structured data

A rendering technique where a web page is dynamically generated on the server at request time, sending fully populated HTML to the client. A BFF frequently serves as the SSR execution environment for a specific frontend framework like Next.js or Nuxt.

• Data hydration: The BFF fetches data, renders the React/Vue tree, and sends complete HTML
• Performance benefit: Eliminates client-side data-fetching waterfalls
• Contrast: SSR generates HTML; a BFF may return JSON or HTML depending on the client's needs

A network of interconnected content services stitched together via a unified API layer. A BFF can act as the integration point that queries multiple sources in the mesh—a CMS, a DAM, a PIM—and composes a single, coherent response for one frontend.

• Sources: Headless CMS, Digital Asset Management, Product Information Management systems
• BFF role: Hides the complexity of the mesh from the client, presenting a simplified, view-model API
• Key principle: Each service owns its domain; the BFF owns the composition logic

The practice of storing content copies on geographically distributed CDN servers to serve user requests from the nearest point of presence. A BFF's responses are often cached at the edge to reduce latency, but cache keys must account for client-specific variations like device type or authentication state.

• Cache key design: Include User-Agent or X-Device-Type headers to avoid serving mobile markup to desktop clients
• Stale-while-revalidate: Serve cached BFF responses instantly while asynchronously refreshing in the background
• Invalidation challenge: When underlying content changes, the BFF's cached view models must be purged