What is a Backend For Frontend — BFF and How it saved the day?
Imagine you have a cool web or a mobile application. Now, this app needs to talk to a bunch of computer magic happening behind the scenes (that’s the backend) to fetch data, make things happen, and so on. But here’s the twist: instead of all apps sharing the same backend, we create a “special” backend just for each app. This special backend is the Independent Backend for Frontend or BFF. Think of it as a cool connector between Frontend and Backend services.
Now, I bet you’re thinking, “Why add another layer?” But guess what? I’m here to tell you how it actually makes things smoother and better in the world of development. If you’re moving from big old systems to the newer micro service setup, this BFF thing could be a game-changer for you too! So, let’s dive in and discover why BFF is worth knowing about.
Why would I need it?
It has been so popular companies migrating their monolith applications to micro-services and micro-frontends (even if it is not necessary in every case) so that the projects can be maintained and scaled easier. My inspiration for writing this article is also one of those monolith migration stories. In my story, the goal was to migrate legacy monolith application with greenfield technologies. Yet, there were a lot of issues at the beginning you would expect. Let me explain you what they were and how BFFs helped us.
Since Backend and Frontend have their own concerns, they have different pace and priorities for development. For instance, a Frontend developer needs some changes in the Backend, but it is a monolith right? Backend developers are hesitant to go into the monolith, understand it first, then develop some more garbage and finally return the data back. As you see, while trying to move away from monolith, you can end up with more code is added there. Don’t worry! I will explain how to solve these development process issues without causing to any Frontend-Backend developer conflicts.
These are minor things but everyday issues while migrating from a monolith. If you already started feeling there has to be a better way. Yes you are right. Here is the BFF pattern comes into the game.
Use case 1 — Adjust BE according to FE needs.
In our Frontend app, we had to fetch data from 3 endpoints in order to be able to render a page. One of the endpoints was even returning massive data. We had to retrieve it for the first time a user logged in. Yet, we were using only tiny part of the data. Even if the data does not change everyday and it is not user specific, for the users fetching it for the first time was not a good experience at all.
Besides, since these endpoints don’t make sense to exist alone, there was no point for keeping them separated. Yet, it is not easy to make changes in monoliths. Even if it is not that hard, Backend developers were not enthusiastic to spend time on improvements.
With the help of BFFs, we managed to compose those endpoints into single one. Also, caching the big data (not user specific) from one of the endpoints, invalidating it in an hour and returning only the part Frontend is interested. As a result, we managed to improve the performance, simplified the usage and change data structure in a way Frontend can use. Thus, we kept Frontend app clean.
Use case 2 — Monolithic application maintenance issues.
It is not always easy to keep Frontend and Backend development keeping at the same speed. You might not be able to find a Backend developer to develop your new feature in the monolith. Sometimes even a minor fix or a change can be a headache since every change have potential for a snowball effect. I can’t blame a Backend developer for this, but as it was the case for us. If Frontend is going ahead, it does not make sense to wait for Backend. Especially while there is something you can do your own. Whenever possible, make your changes in BFF and move forward. When Backend takes care of the necessary changes, it will be about only removing some code from your BFF and integrating it to the new service. That is it.
Use case 3 — Team autonomy.
There were also 3rd party services that we store some media types. We needed that data in our Frontend app. It was easy to ask from our Backend developers to integrate those services. However, you can easily do it in the BFF where you can still stay in your Frontend zone. Just go to your BFF, retrieve data from 3rd party services. You are good to go. No Backend involvement is required. It brings more autonomy to Frontend developers.
Use case 4 — Fake it until you make it.
While some tasks are in progress on Backend side, and you know it will take more time, wouldn’t it be nice to have a BFF that returns data you need? Of course, it will eventually come from a proper Backend service and database. Yet, until that time, you can pretend Backend is already there. Thus, you can define data structure and develop your feature in the Frontend. It does not matter what kind of changes Backend will make. Once Backend implements the demanded feature, there is only a integration left between the BFF and Backend. You don’t have to be bothered by the api changes in Backend since it is still possible to map it in BFF.
Here is the big question comes: How can I create a BFF?
You might consider creating a kind of micro-service (of course, without any business logic, database connection, caching). This service will only be bridge between your Frontend app and Backend services. Depending on the requirements, you can add 3rd party integration, data mapping, etc. That is pretty much it.
Of course there is more than that, but I guess you already got the idea. Congrats, we got a new service, most probably maintained by Frontend and a place where we can hide the garbage. You can decide which language would be more appropriate for BFFs. If you ask me, after some bad decisions and painful development process, we decided javascript was the best fit for my team. Depending on your team, organisation structure and product, BFFs can be very useful and help to unblock your teams.
Conclusion
Of course, it is also vital to consider that introducing one more application to your team will require maintenance, monitoring, performance, security issues, etc. Therefore, take your time before making such a decision, and I hope it makes your life easier, not any harder :)
Thanks for reading!
Please do share your story how BFF saved the day for you.
Resources
Seeing the BFF Pattern used in the wild
Web App Security, Understanding the Meaning of the BFF Pattern
Best Way to Structure Your Directory/Code (NestJS)
