Stackbook Logo
distribution-communicationestablished · medium operational burden

Backend for Frontend (BFF)

Also known as: bff, experience-api

Intent

Give each client type its own tailored backend so UI needs do not distort a shared general-purpose API.

Problem

A single shared API serves web, mobile and partner clients with very different needs. Mobile wants small payloads and few round trips while web wants rich data, so the API either bloats or accumulates client-specific hacks. Every UI change then requires coordination with the backend team.

Forces

  • •Clients differ in bandwidth, screen size and data shape
  • •Frontend teams want to ship without waiting on a central API team
  • •Duplicated aggregation logic across clients is costly
  • •Each extra backend is another service to run

Solution

Overview

A Backend for Frontend is a server-side component dedicated to one user experience. Instead of forcing mobile, web and partner clients through one generic API, each gets a backend shaped for its screens. The BFF is typically owned by the frontend team, which removes the cross-team queue for API changes.

How it works

The client calls only its BFF. The BFF fans out to domain services, merges and trims the results, and returns a response that maps one-to-one to a screen.

Mobile app --> mobile-bff --+--> orders-service
                            +--> catalog-service
Web app    --> web-bff   ---+--> profile-service

A typical mobile endpoint, GET /home, might call three services in parallel, drop fields the phone never shows, and return one compact JSON document. The web BFF calls the same services but returns richer data and supports server-side rendering. Cross-cutting concerns such as token exchange and rate limits are handled here or in a gateway in front of the BFFs.

Pitfalls

  • Business rules migrating into the BFF. Keep it a translation and aggregation layer; domain decisions belong in domain services.
  • Copy-pasted client code across BFFs. Extract shared libraries only for truly generic concerns like auth.
  • Serial downstream calls. Parallelise calls and set timeouts so one slow service does not stall the screen.
  • One BFF per team rather than per experience, which recreates the shared-API problem.

Key takeaways

  • One backend per client experience, owned by the frontend team.
  • Keep BFFs thin: aggregate and reshape, do not decide.
  • Accept some duplication in exchange for client fit and team autonomy.
  • Pair with a gateway for shared edge concerns.

✓ When to Use

  • •Multiple client types with clearly different data needs
  • •Frontend teams own their delivery cadence
  • •Screens need data from several services per view

✗ When Not to Use

  • •A single client with a stable API
  • •Business rules would leak into the BFF layer
  • •Team is too small to run several backends

Pros

  • +Payloads and calls fitted to each client
  • +Frontend teams ship independently
  • +Downstream services stay client-agnostic

Cons

  • −Duplicated code across BFFs
  • −More services to deploy and monitor
  • −Risk of business logic creeping into BFFs

Cost Profile

Infrastructure

Medium - one service per client type

Operational

Medium - more deployments and dashboards

Cognitive

Low - simple concept

Failure Modes

  • BFF becomes a second monolith holding business rules

  • Shared logic copied and drifting between BFFs

  • BFF latency adds to every request path

Real-World Examples

Alternatives

    Related Patterns

    • api-gateway

    Competency Domains

    distribution communicationeconomics evolution