The BFF Pattern (Backend for Frontend): An Introduction
Get to know the benefits of using the BFF pattern in practice
Imagine a scenario where you need to build an e-Commerce application using microservices. You may have microservices for Customers, Orders, Products, Shopping carts, etc. The microservices expose APIs to be used by the frontend.
However, the data returned to the frontend by the Microservices may not be formatted or filtered according to the exact way the frontend needs to represent them.
In that case, the frontend needs to have some logic on its own to re-format these data. Having such logic in the frontend will use up more browser resources.
In a situation like this, we can use a BFF in order to shift some of this front-end logic to an intermediate layer. The intermediate layer is the BFF. When a frontend requests some data, it will call an API in the BFF.
The BFF will do the following.
- Call the relevant microservices APIs and obtain the needed data
- Format the data based on the frontend representation
- Send the formatted data to the frontend
As a result, there will be minimal logic on the frontend. Therefore, a BFF helps to streamline data representation and takes up the responsibility of providing a well-focused interface for the frontend.
💡 Another great way to simplify your backend-frontend relation is by sharing types between them. Learn how to use Bit to share types (or any other piece code) between decoupled projects:
If you prefer to watch:
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- To implement a more manageable Backend-for-Frontend (BFF) pattern for your microservices, a good practice is to see each as components, and then leverage a modular, reusable, and shareable approach for them. For this, you can once again use Bit to create, version, publish, and share each component as a separate package — or even use Bit’s variants to create different configs for each.
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.
And here are some tools you can use for implementing the BFF pattern:
Let me know your experience and opinions as well afterward. 😃
Integrating faster with components
From monolithic to composable software with Bit
Bit’s open-source tool help 250,000+ devs to build apps with components.
Turn any UI, feature, or page into a reusable component — and share it across your applications. It’s easier to collaborate and build faster.
Split apps into components to make app development easier, and enjoy the best experience for the workflows you want:
