February 17, 2024

Understanding Back-for-Front (BFF)

In the world of system development, it's paramount that the communication between the client (front-end) and the server (back-end) is fluid and efficient to ensure everything works as smoothly as possible for the user. This is where BFF (Back-for-Front) comes into play, serving as an intermediary layer that acts like a friend facilitating this communication between different client instances and services. In this post, we'll dive into what a BFF is, discuss why it's important, and when it does or doesn't make sense to use it.

So, what is a BFF? 🤔

BFF, and no, it doesn't mean Best Friends Forever, but rather Back-for-Front. It's essentially an intermediary layer situated between the front-end and the back-end. This layer is tailor-made to directly assist a specific interface on the front-end, like a web system or mobile app. The main goal of the BFF is to improve communication, manage the necessary data processing, and, consequently, enhance the user experience with the system.

This image illustrates the architecture of a web and mobile application. It is divided into two main parts: the front-end and the back-end. The front-end includes mobile and web front interfaces. The back-end comprises BFF (Backend for Frontend) services for mobile and web, which connect to three different backend services (Service 01, Service 02, and Service 03). The mobile interface connects to the BFF Mobile, which then communicates with the backend services. Similarly, the web front connects to the BFF Web, which also communicates with the same backend services.

The image above represents a simple interaction between the Front and the BFF, where the goal is for the front-end to interact only with the mediator and not both services directly. Now, imagine you're building an application with multiple user interfaces (UIs), such as a web application and a mobile app. Each of these clients might require data in slightly different ways due to their unique design and user experience particulars. The BFF acts as a customized intermediary for each type of client, optimizing backend calls and consolidating responses from multiple microservices.

Practical Example:

Consider a blog system with three microservices: the "Post Management Service," responsible for creating, editing, and deleting posts; the "Comments Service," in charge of managing comments associated with each post; and the "View Statistics Service," which provides information on the number of views each post gets. The BFF acts as a smart intermediary between the front-end and these microservices, consolidating the information obtained from each into a single display.

The image below demonstrates a mobile APP that requests its BFF with just the necessary information for displaying a Post. It's worth considering that in a web application with the same purpose, some information may be necessary or dispensable, highlighting the usefulness of the BFF.

This image shows the architecture of a mobile application interacting with backend services. On the left side, there is a mobile app interface displaying a post with title and comments. The app makes a request to /post/:id to the BFF Mobile (Backend for Frontend), which then communicates with three different backend services: Views Service, Posts Service, and Comments Service. Each service is responsible for handling different aspects of the post.

Motivations 💪

Interface Specialization: The BFF allows user interfaces to receive data in the most suitable format, reducing the need for heavy processing on the client side.
Decoupling: Introducing a BFF layer allows the front-end to be developed and evolve independently from the back-end services, providing flexibility and agility in development.
Performance Optimization: With the BFF, it's possible to consolidate several API calls into a single call, reducing latency and improving user experience.

When to Use or Not Use the BFF 👀

When or when not to use this architectural strategy?

When to Use

Applications with Specific UI Requirements: When different clients (web, mobile, etc.) have unique requirements, the BFF can provide each with data in the most optimized way.
Microservices: In microservices-based architectures, the BFF can simplify communication between services and clients, acting as a service aggregator.
Independent Evolution: When it's desirable for front-end and back-end teams to work more autonomously, without directly depending on each other for changes.

When Not to Use the BFF

Simple Applications: For applications that don't require complex logic between the front-end and back-end, introducing a BFF may be unnecessary and increase complexity.
Limited Resources: Implementing and maintaining a BFF requires additional resources. In projects with limited resources, carefully evaluate whether the benefits justify the additional investment.

In conclusion, the BFF is a powerful architectural approach that, when applied correctly, can significantly improve communication between the front-end and back-end, offering a richer and more efficient user experience. However, like any tool or technique, it's crucial to carefully assess your specific project needs before adopting it.