Backend for Frontend design pattern – BFF for short while it’s definitely not “Best Friends Forever” 🙂 – seems to get some hype lately.
It’s nowhere a new thing: one of the first mentions were by SoundCloud guys back in 2015. Basically it’s a specialized case of a more generic API Gateway pattern. Let’s figure out what it is and when it’s useful.
A bit of historical perspective
Web apps / services evolution outlines itself by following major milestones:
- Static web sites – these were mostly just hand-written HTML/CSS and there was little dynamic content.
- Post-back Model-View-Controller (MVC) apps – server generates parts of previously static web sites allowing dynamic content. That was the era of monoliths, such behemoths as Django or Ruby on Rails were created exactly to enable such apps at first. The first rise of e-commerce is also attributed to this period.
- Single Page Apps (SPA) + APIs – this was a crucial step to enable rise of mobile apps in particular and multiple client types in general. Most modern web apps follow this approach which enabled frontend / backend specializations as both became very complex programming products on their own.
BFF pattern surfaced as part of further evolution of APIs.
Backend for Frontend as APIs evolution milestone
With backend systems separated from the frontend and exposed via APIs there were some major milestones in their further development.
Microservices is an architectural approach that splits a monolith backend into multiple independent & specialized services. Despite all the hype this architectural approach can’t be applied blindly since it’s not always the best way. Check out my article “When to use microservices?” for more details on how to decide.
In a pure microservice-based system clients use microservices directly. This may lead to a huge amount of requests made to perform a single business transaction. With clients distributed across the globe cumulative latency can become a problem. Clients also suffer from excessive complexity knowing about backend too much and handling communication failures themselves.
That’s where API Gateway patterns come to play. It encapsulates request routing / composition / protocol translation. Typically an API gateway handles a request by invoking multiple microservices and aggregating the results. It can also translate between web protocols and web‑unfriendly protocols which work internally.
BFF pattern is a way to implement API gateway.
Backend for Frontend as API Gateway implementation approach
There could be at least following ways to employ the API gateway pattern:
- A single API gateway providing a single API for all clients. This is the obvious approach. It may be problematic to provide generic & useful API for all kinds of clients this way.
- A single API gateway provides an API for each kind of client. This allows different kind of clients to consume specific API portions provided by the single API gateway implementation. It may be problematic to evolve such complex implementation. Different kinds of clients may have drastically different scale requirements leading to inefficiencies in resources consumption.
- A per-client API gateway providing each client with an API. This implies separate API gateway implementations for client-specific APIs. It may be problematic to support all the different API gateway implementations in parallel.
The last approach is what BFF actually advocates for. As usual there’s no silver bullet and every option is a tradeoff to be chosen for a particular situation.