Web development as we know it today has migrated away from a popular pattern used in the 2000s called MVC (Model View Control). This pattern involves splitting into layers everything related to entities, business logic, database (model), from the frontend (view) and the redirections (control).

But today, we face a new reality where we have several approaches for development. Things are also omnichannel, meaning we do not necessarily develop focused solely on the web anymore, but for mobile devices, intelligent devices, and other platforms.

APIs and microservices have helped increase the adoption of other patterns of integration and the presentation of data. However, they also created some complexity for developers who need to present data or interact with the customer with rich frontend experiences.

But the challenge continues: How do we decrease the coupling between layers in our software while ensuring a powerful presentation layer?

Frameworks for Frontend Development and Native Backend Components

For a long time, developers used HTML, CSS, and JavaScript. Sometimes, even implementing the MVC pattern, they used native backend components mixed with the frontend code to develop their web projects. Or, if you are a Java developer, you likely used Taglibs, JSTL, JSF components, or even Template Engines if you are working with Spring MVC (Spring framework is one of the most modern tools for Java development today).

Even if you perform quality software engineering with well-defined classes, structured interfaces, and a well-designed backend, we tend to create a small level of coupling using these native backend components. This approach is not necessarily wrong for development. But sometimes, a software architecture requires simplicity and reusability of its ingredients to reduce the maintenance and ease development.

Suppose your project scope increases, and an omnichannel pattern is the main goal for your project. Here, scalability is not negotiable. In that case, you have to search for a low level of coupling or even achieve zero coupling using a frontend framework for your task. You might consider using Angular, Vue, React, or other frameworks for your presentation layers.

Some of these frontend frameworks are responsive, meaning they can auto-adjust to meet the requirements of web, mobile, and other client types. Therefore, using this approach, we can deploy the presentation layer separately from the backend layer, where all the business logic and requirements live. The backend is deployed separately as another process using APIs or microservices.

A coupling point may appear even in this way, as we use our HTML page to point to an API to get data and display it. You can use the API-first approach to focus on which information you should present, but some aggregation of information from several APIs may be required. Depending on the aggregation or the logic for data presentation, this won’t continue to be sustainable throughout the application’s lifetime. This is where the BFF pattern appears to help.

What’s Backend for Frontend (BFF)?

Backend for Frontend (BFF) can be defined as an abstraction layer between the presentation layer and the logical layer.

Let’s suppose that our project needs to be accessed from a mobile app or from a computer, but, depending on the device, the customer experience needs to change. Some functionalities and data can be present in one or the other device but not in both. This requirement may sound strange, but some SaaS today functions this way as a requirement from the stakeholders. This case forces us to build a process between the presentation layer to choose how data will be displayed if we’re using the same set of APIs.

Also, you will encounter a problem if, using API or microservices in your backend, you send this kind of process to it. This type of request is not related to any heavy business logic or requirement, but it’s more related to the presentation logic. So, at this point, the BFF pattern can help drive the solution to this problem.

We can use an API over the backend layer, and with this API, we can handle the process from the frontend, to define some presentation rules or even which data or functionality will call some API or microservice, and hold the load of this responsibility in one point.

The BFF pattern is mostly held by the SOLID principle for Single Responsibility. This abstraction layer is used only for this case, when we don’t want to transfer the load and responsibility for decisions or processes to a frontend layer or a backend layer, decreasing the coupling even moreso. In this way, the presentation layer has only the responsibility of presenting the data and the backend to process the business logic and requirements. The BFF will do the work to choose how these things will work together, depending on the case.

When Should I Use BFF? When Should I Not?

As we saw, BFF should be used when our scenario is related to handling requests to help avoid extra load or data processing on the presentation layer. Dealing with the presentation of data to be displayed across various client types is better done on a BFF layer.

But, if you have a small scope or if your software needs less process capacity, you probably don’t need to split it into two or more layers to deploy. The same applies if your system will be accessed by a computer in a computer for small tasks. In this case, I believe that just using the MVC approach with a well-designed control layer should be enough. But always remember that this decision must be taken according to your architectural goals and with the maturity of the development team in mind.

There are other alternatives, too. For example, if you just use REST APIs as your backend, you can use GraphQL as an aggregator. It works like an “API aggregator,” connecting all the APIs you need and then building a standard data output displayed on your frontend. I’ll not go deep into this approach, but I would like to mention it because it can simulate a BFF using different methods and mechanisms.

Additional Information

Sam Newman created the BFF pattern based on his experience working at SoundCloud. The SoundCloud app can be accessed by web, mobile, and smart devices, and the presentation layer and functionality change depending upon the client accessing the application.

Or dive into BFF opens the opportunity for further discussions and research. For more information, here are some other resources:

• Pattern: Backends For Frontends: Sam Newman’s site goes deeper into the BFF pattern.
• Pattern: API Composition: API Composition, also known as API Aggregator, is a pattern to aggregate and grab information from multiple APIs.
• GraphQL.org: Visit this site if you are interested in learning more about GraphQL.