Modern software applications often need to support multiple frontend UI like Web, Android, IOS, TV, and VR, each with unique requirements. Traditionally, developers have dependent on a single backend to serve all clients. However, the complexity of serving different frontends needs using a monolithic backend can result in performance bottlenecks, complicated APIs, and unnecessary data interactions.
The Backend for Frontend (BFF) architecture helps answer these challenges by creating a dedicated back-end service for each frontend type. Each BFF is dedicated to a specific UI kind, improving performance, UX, and overall system stability and maintainability.
A General-Purpose API Backend (Traditional)
If different UIs make the same requests, a general-purpose API can work well. However, the mobile or TV experience often differs significantly from a desktop web experience. First, mobile devices have distinct constraints; less screen space limits how much data you can show, and multiple server connections can drain the battery of the device and also impact data (on LTE).
Next, mobile API calls differ from desktop API calls. For example, in a traditional Netflix scenario, a desktop app might let users browse movies and shows, buy movies online, and show a lot of information about the movies and shows. On mobile, the features are very limited. As we’ve developed more mobile applications, it’s clear that people interact with devices differently, requiring us to expose different capabilities or features.
In general, mobile devices make fewer requests and display less data compared to desktop apps. This results in additional features in the API backend to support mobile interfaces.
A general-purpose API backend often ends up taking on many responsibilities, which will result in creating a dedicated team to manage the code base and fix bugs. This can lead to increased use of budget, complex team structure, and front-end teams required to coordinate with this separate team to implement changes. This API team has to prioritize requests from various client teams, while also working on integration with downstream APIs.
Introducing the Backend For Frontend (BFF)
One solution to the traditional general-purpose API issue is to use a dedicated backend for each UI or application type, also known as Backend For Frontend (BFF). Conceptually, the user-facing application has two parts: the client-side application and the server-side component.
The BFF is closely aligned with a specific user experience and is typically managed by the same team responsible for the user interface. This makes it easier to tailor and adjust the API to meet the needs of the UI, while also streamlining the release process for both the client and server components. A BFF is only focused on a single user interface, allowing it to be smaller and more targeted in its functionality.
How Many BFFs Should We Create?
When delivering similar user experiences across different platforms like mobile, TV, desktop, web, AR, and VR, having a separate BFF for each type of client is preferred. For example, both the Android and iOS versions of an app share the same BFF.
For all TV clients, for example, Android TV, Apple TV, and Roku TV, all apps use the same BFF, which is customized for TV apps. When all similar platform apps share a BFF, it’s only within the same class of user interface. For example, Netflix’s IOS and Android apps share the same BFF, but their TV apps use a different BFF.
How Do We Handle Multiple Downstream Services Efficiently?
BFFs are a useful architectural pattern when dealing with a few back-end services. However, in organizations with many services, they become essential as the need to aggregate multiple downstream calls to provide user functionality grows significantly. Take, for instance, Netflix, where you want to display a user’s recommendation along with ratings, comments, languages available, CC, trailer, etc.
In this scenario, multiple services are responsible for different parts of the information. The recommendation service holds the list of movies and their IDs, the movie catalog service manages item names and ratings, while the comments service tracks comments. The BFF would expose a method to retrieve the complete recommendations, which would require at least three downstream service calls, constructing a recommendations view through multiple downstream calls.
From an efficiency perspective, it’s best to run as many of these calls in parallel as possible. After the initial call to the recommendations service, the subsequent calls to the rating and comments services should ideally occur simultaneously to minimize overall response time. Managing parallel and sequential calls, however, can quickly become complicated in more advanced use cases. This is where asynchronous programming models are valuable, as they simplify handling multiple asynchronous calls.
Understanding failure modes is also crucial. For instance, while it might seem logical to wait for all downstream calls to succeed before responding to the client, this isn’t always the best approach. If the recommendations service is unavailable, the request can’t proceed, but if only the rating service fails, it may be better to degrade the response by omitting the rating information, instead of failing the entire request. The BFF should handle these scenarios, and the client must be capable of interpreting partial responses and rendering them correctly.
Conclusion
The BFF pattern is a powerful tool for organizations seeking to deliver optimized, scalable, and efficient frontends for a variety of client types. It allows for better separation of concerns, minimizes complexity in frontend development, and improves overall system performance. While the approach does come with challenges, such as maintaining multiple backends and avoiding code duplication, the benefits often outweigh the downsides for teams working in complex, multi-client environments.
