Backend for Frontend (BFF) Pattern: When, Why, and How to Use It

Introduction – With the rise of the web, UI delivery shifted from thick clients to web‑based interfaces, dramatically lowering the cost of releasing new features. The subsequent mobile era introduced new challenges: limited screen real estate, battery and data constraints, and differing interaction models, which made a single generic API backend increasingly unsuitable.

Generic API Backend – A single server‑side API can serve multiple UIs initially, but as mobile experiences diverge from desktop, the API becomes a bottleneck. Adding features for each new UI type inflates the codebase, creates cross‑team coordination overhead, and often leads to an unintelligent middleware layer that does not align with service‑oriented architecture principles.

Introducing Frontend Backend (BFF) – A solution observed at REA and SoundCloud is to give each UI its own backend, called a Backend‑for‑Frontend (BFF). The BFF is tightly coupled to a specific UI, owned by the same team that builds the UI, making API definition and iteration faster and more aligned with UI needs.

How Many BFFs? – Two common models exist: (1) one BFF per UI type (as seen at REA), and (2) a shared BFF for both iOS and Android native apps (as used at SoundCloud). The choice depends on how similar the mobile experiences are and on team boundaries; Conway’s Law suggests aligning BFF count with team structure.

And Multiple Downstream Services (Microservices!) – In architectures with many microservices, a BFF aggregates calls to downstream services. For example, building a wishlist view may require calls to Wishlist, Catalog, and Inventory services. Parallelizing these calls improves latency, but error handling becomes critical; the BFF must decide how to degrade gracefully when some services fail.

Reuse – Multiple BFFs often duplicate aggregation logic. While extracting shared code into a library or a separate service can reduce duplication, it also introduces coupling. The article suggests extracting shared functionality only when the abstraction is truly service‑level and the cost of creating a new service is low.

Desktop Web and Other Domains BFFs – BFFs are not limited to mobile; they can be useful for desktop web when server‑side rendering or heavy aggregation is needed, or when exposing APIs to third parties. Placing a reverse‑proxy cache in front of a BFF can also improve performance.

Autonomy – When UI teams own their BFFs, they can iterate quickly without waiting on backend teams. This ownership also lets them decide where functionality should live (client vs. server) and release new features without app‑store delays.

General Peripheral Concerns – Some teams use BFFs for cross‑cutting concerns like authentication or logging, but this can add latency. Alternatives include handling such concerns at the edge (e.g., Nginx/Apache) or using shared libraries, though each approach has trade‑offs.

When to Use – For pure web‑only applications, a BFF is only justified when the server must perform heavy aggregation. For mobile or third‑party consumers, a BFF is usually worthwhile because it isolates concerns, reduces client complexity, and enables faster releases.

Further Reading (and Watching) – References to ThoughtWorks articles, podcasts, and a 2016 microXchg talk by SoundCloud’s Bora Tunca provide deeper insight into the BFF pattern.

Conclusion – The BFF pattern solves a pressing problem for mobile development on microservice architectures, offers a compelling alternative to generic API backends, and, by limiting the number of consumers, makes services easier to manage while preserving team autonomy.