Backend For Frontend Layer

Backend For Frontend Architecture — What, Why and When?

What is BFF Architecture?

A BFF layer refers to having multiple servers serving as a linkage between various frontend frameworks — like a desktop, a website, a mobile application, and the backend server where all the data and business logic resides. It offers seamless User Experience independent of the platform the client is using to access our platform or application.

APIs in monolithic systems often contain extraneous data that is specifically useful to a single FE framework. Take financial transactions as an example. A frontend application running on the smartwatch only requires the transaction amount from the API if the user wants to know about their most recent transaction. Creating a generic API in this situation would result in extra data being returned that would be useless for a smartwatch but useful for the client app running in the web. Such an API will add overhead to applications for smartwatches.

Thus, the usage of a specific BFF backend for various FE frameworks would contribute to the achievement of an optimal solution that would not only be free of overhead costs but would also enhance the user experience.

Benefits and Challenges of BFF

Advantages:

• A distinct backend service can respond more quickly, and multiple frontend application interfaces can simultaneously call their respective BFF backends.
• Hiding sensitive or pointless data before sending it to the frontend application interface might benefit the BFF layer in the overall system architecture and make the system more simple.
• When dealing with the FE frameworks, BFF layers can utilise a single protocol even if they are requesting data from microservices using any protocol, including FTP, SOAP, REST, or GraphQL.
• With specialised teams working on the changes, implementing BFF architecture speeds up the process of updating backend systems.

Disadvantages:

• Code duplication and reuse are common since many development teams take care of various BFFs. When there are communication gaps, the same implementation may be used by BFFs, increasing the development costs.
• Any microservice outage in the BFF layer that reacts to many BFFs can have an effect on the entire system.
• In BFF, the failure of one service has the potential to bring down the entire system as the BFF layer is acting as the single point of failure between the backend and the FE systems.

Most important of all, When should we use a BFF Architecture?

The greatest fit for your software will depend much on its features and environment, however the following are some things to think about:

• Consider using the BFF pattern if your system is intended to employ a shared or general-purpose backend service that is difficult to maintain and takes a lot of time to construct.
• Having a specialised BFF service for each of your FE frameworks will considerably minimise maintenance complexity if functional needs for various frontend application interfaces (mobile and web-browser, etc.) are significantly varied.
• BFF is a good choice if your software system has to create an efficient backend for a particular frontend interface.