In a simpler world, a web application will only ever have one client interacting with one server. For many years, this was the case. Data surfaced from the server through an API could be closely tied to the client’s specific needs. There was little need for any additional complexity. However, new technologies and complex, changing user requirements created the need for applications to support a wider range of requirements.
The biggest offender is the mobile app. A mobile application client and a web application client for the same server have the same functionality. However, the underlying issue is how the user interacts with the application. The data coming in and going out from a mobile app may not be the same as from a web application. This results in either two near-identical iterations of the same server existing for each client, or one polluted, general server handling requests from both clients.
The rise in popularity of micro-services has also presented an issue. That’s because now the client will make calls into a variety of APIs to retrieve all the necessary data. For instance, a banking application could have a micro-service for handling savings and checking accounts and a micro-service for investments. There’s still only one client for the entire banking application, but there are multiple servers the client needs to retrieve data from. Any interactions between the data retrieved from these micro-services must be resolved in the client, potentially exposing sensitive business logic.
One popular solution to these issues is the Backend for Frontend (BFF) pattern.
Backend for Frontend (BFF) Pattern
The Backend for Frontend Pattern is a software architecture pattern that adds a layer between your client and your server(s). That extra layer serves as a way to resolve API requests and format the data for proper usage on the frontend. It is tightly related to the client and is deployed alongside it. Rather than the client directly calling an API method into a server, it will call an API method into the BFF layer. There, the BFF layer can delegate where that request goes. The BFF layer will then call the API methods into the respective server(s), retrieve the data, and carry out any necessary operations before sending that data to the client.
It is important to note that the BFF layer is merely a translation layer. The sole purpose is retrieving and translating data into the correct form so the client and server(s) can properly use it.
Advantages of a BFF
Implementing a Backend for Frontend pattern brings significant advantages to an application.
- A server doesn’t need to support multiple implementations of the same functionality based on which client is interacting with it.
- There is no need for multiple iterations of nearly the same server to exist reducing the number of spots where a team needs to change and support code.
- This pattern moves the functionality of tailoring data for specific clients into the BFF and away from the server. That way, the server can process more requests faster.
- The added layer keeps the client incredibly light by hiding as much information as possible. The client doesn’t know if it needs to retrieve data from one or 1,000 servers and doesn’t care how the data is resolved. It only needs properly-formatted data when the BFF sends it back. The BFF layer can include caching to speed up requests and limit the times a server needs to process a request.
- A BFF can integrate new technologies into your client code independently of the server. (For example, supporting GraphQL on the client side while the server(s) rely on a Rest API.)
When to use a BFF Pattern
For any application with only one direct connection between a client and a server, implementing a BFF pattern likely brings no benefits and only adds complexity. Since the BFF layer exists as a translation layer, there is nothing to translate for this case. This would only add additional layers of pass-through to support.
Consider a BFF implementation as soon as any resolution is needed for data sent or returned from an API method. This could involve pulling content from two different micro-services or supporting a mobile client and a web client. Keeping the translations contained in a BFF layer insures your client(s) and server(s) can remain lightweight and not care or know about where the data is coming from or where it’s going.
Overall, the BFF pattern is a great tool for developers looking to create applications with complex connections between multiple clients and servers. Its scalability and flexibility allow for easier development and a better, tailored user experience.