The BFF Pattern (Backend for Frontend): An Introduction
By: Viduni Wickramarachchi
Tags: Backends For Frontends, Microservices, Backend Development, JavaScript, Front End Development

How does it fit in for the eCommerce example?

The following diagram shows how each microservice connects with the frontend through BFF.

The role of a BFF

As we already explored, BFF acts as a simple interface between the frontend and microservices. Ideally, the front-end team will be responsible for managing the BFF as well.

A single BFF is focused on a single UI, and that UI only. As a result, it will help us keep our frontends simple and see a unified view of data through its backend.

That brings the next question. Can we have multiple BFFs for multiple UIs? We’ll answer this question in the latter section of this article. Keep reading. 😊

Will this increase latency?

Now we know that a BFF is similar to a proxy server between the client and other external APIs, services, etc. If the request has to go through another component, it will definitely increase latency. However, the BFF latency is negligible compared to the browser’s high resource usage if it needs to work with multiple services not optimized for the frontend.

Building a BFF allows you to intelligently make batch calls to other backends/ microservices and return the data all at once, or return a more convenient representation by transforming and formatting the data.

This can be very useful for mobile clients on 2G or 3G networks where it can take seconds (or more) to establish the connection.

When to use a BFF for your applications

Like many other patterns, using the BFF in your application depends on the context and the architecture you plan to follow. For example, if your application is a simple monolithic app, a BFF is unnecessary. It will add little to no value.

However, if your application depends on microservices and consumes many external APIs and other services, it is better to use a BFF to streamline the data flow and introduce a lot of efficiency to your application.

Further, if your application needs to develop an optimized backend for a specific frontend interface or your clients need to consume data that require a significant amount of aggregation on the backend, BFF is a suitable option.

Can we have multiple BFFs?

Of course, we can! That is the whole point of having a BFF.

A traditional approach (an application without a BFF) will have only one API gateway for all clients. It will look as follows.

However, the purpose of having a BFF is to provide your client a focused interface to connect with. For example, data consumption by a mobile UI could be different from data consumption by a browser. In that case, for better data representation, two BFFs can be used. Let’s have a look at an application diagram with multiple BFFs.

As you can see, each client has a BFF here. It will help optimize the responses by the services (Sa, Sb … Sn).

Advantages of having a BFF

A few advantages of having a BFF are as follows:

Separation of concerns — Frontend requirements will be separated from the backend concerns. This is easier for maintenance.

— Frontend requirements will be separated from the backend concerns. This is easier for maintenance. Easier to maintain and modify APIs — The client application will know less about your APIs’ structure, which will make it more resilient to changes in those APIs.

— The client application will know less about your APIs’ structure, which will make it more resilient to changes in those APIs. Better error handling in the frontend — Server errors are meaningless to the frontend user most of the time. Instead of directly returning the error server sends, the BFF can map out errors that need to be shown to the user. This will improve the user experience.

— Server errors are meaningless to the frontend user most of the time. Instead of directly returning the error server sends, the BFF can map out errors that need to be shown to the user. This will improve the user experience. Multiple device types can call the backend in parallel — While the browser is making a request to the browser BFF, the mobile devices can do the same. It will help obtain responses from the services faster.

— While the browser is making a request to the browser BFF, the mobile devices can do the same. It will help obtain responses from the services faster. Better security — Certain sensitive information can be hidden, and unnecessary data to the frontend can be omitted when sending back a response to the frontend. The abstraction will make it harder for attackers to target the application.

— Certain sensitive information can be hidden, and unnecessary data to the frontend can be omitted when sending back a response to the frontend. The abstraction will make it harder for attackers to target the application. Shared team ownership of components — Different parts of the application can be handled by different teams very easily. Frontend teams get to enjoy ownership of both their client application and its underlying resource consumption layer; leading to high development velocities. The below diagram shows an example of such a team separation along with BFFs.

Best practices to follow in practice

What we have seen so far has been amazing! However, are BFFs fault-proof?

The answer is NO! Like every other technology or pattern, even BFFs have pitfalls. In order to avoid these, we have to follow best practices.

Avoid implementing a BFF with self-contained all-inclusive APIs — Your self-contained APIs should be in the microservices layer. Most developers forget this and start implementing service-level APIs in the BFF as well. You should keep in mind that the BFF is a translation layer between the client and the services. When data is returned from a service API, the purpose of it is to transform it into the data type specified by the client application.

— Your self-contained APIs should be in the microservices layer. Most developers forget this and start implementing service-level APIs in the BFF as well. You should keep in mind that the BFF is a translation layer between the client and the services. When data is returned from a service API, the purpose of it is to transform it into the data type specified by the client application. Avoid BFF logic duplication —A vital point to note is that a single BFF should cater to a specific user experience, not a device type. For example, most of the time, all mobile devices (iOS, Android, etc.) share the same user experience. In that case, one BFF for all these operating systems is sufficient. There is no need to have a separate BFF for iOS and another for Android.

—A vital point to note is that a single BFF should cater to a specific user experience, not a device type. For example, most of the time, all mobile devices (iOS, Android, etc.) share the same user experience. In that case, one BFF for all these operating systems is sufficient. There is no need to have a separate BFF for iOS and another for Android. Avoid over-relying on BFFs — A BFF is merely a translation layer. Yes, it provides a certain level of security to the application too. But, you should not rely on it more than you should. Your API layer and frontend layer should take care of all the functionality and security aspects regardless of the presence of a BFF or not. Because the BFF is supposed to fill a gap, not add any functionality or service to the application.

Summary

The BFF pattern not only helps development, but it also helps improve user experience drastically. Therefore, it is essential to consider data optimizations and aggregations while keeping the BFF focused on its frontend.

Besides, if you haven’t used the BFF pattern before, it’s time to start now. Let me know your experience and opinions as well afterward. 😃