Backends for Frontends (BFF) pattern
Given that our system was originally designed for desktop-web UI, we frequently encountered difficulties in adapting mobile UIs or other user interfaces as we already had a tight coupling between the desktop web UI and our backend services. Does your backend architecture pose challenges when it comes to creating enjoyable user experiences? Has your API monolith become a bottleneck? If so, considering the adoption of the Backends for Frontends (BFF) architectural pattern could be beneficial.
What is it?
The backends for frontends pattern describes a world in which you should think of the user-facing application as being two components - a client-side application living outside your perimeter, and a server-side component (BFF) inside your perimeter. The BFF is specifically centered around a solitary user interface, concentrating solely on that particular UI.BFF is a variant of the API Gateway pattern, but it also provides an additional layer between microservices and each client type separately. Instead of a single point of entry, it introduces multiple gateways. Because of that, you can have a tailored API that targets the needs of each client (mobile, web, desktop, voice assistant, etc.), and remove a lot of the bloat caused by keeping it all in one place. The below image describes how it works.
When to use this pattern
As with numerous other patterns, the incorporation of BFF into your application is contingent upon the specific context and architectural approach you intend to adopt. For instance, if your application submits identical or comparable backend requests, or if a single interface exclusively interacts with the backend, the inclusion of a BFF becomes redundant and yields minimal to no advantages
If your application relies on microservices and extensively utilizes external APIs and other services, opting for a BFF can enhance the efficiency of your application by streamlining data flow and introducing significant optimization.
If your application requires the creation of a finely tuned backend tailored to a particular frontend interface, or if your clients necessitate data consumption involving substantial backend aggregation, then BFF emerges as a fitting choice.
Advantages of having a BFF
Separation of concerns: Frontend necessities will be distinct from backend considerations, resulting in simplified 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 front end: Frequently, server errors hold little significance for front-end users. Rather than transmitting the error directly, the BFF can effectively translate errors that should be presented to the user. This adjustment will enhance the overall user experience.
Multiple device types can call the backend in parallel: While the browser is requesting 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 front end can be omitted when sending back a response to the frontend. The abstraction will make it harder for attackers to target the application.
Best Practices
Some of the best practices you should follow when working with the BFF pattern include:
Avoid duplicating the BFF logic to avoid code redundancy.
Use the BFF pattern when your application works with several microservices and/or consumes data from external APIs.
You can use the BFF pattern also when your application has several different user interfaces with each requiring data to be presented in its own required format.
Conclusion
The Backend For Frontend is a design pattern conceived with both the developer and, of greater significance, the user and their experience as focal points. It provides a solution to the continually expanding utilization of applications for engaging, interacting with, and serving customers. This pattern ensures uniformity while effectively addressing their varied and changing requirements.