Backend-for-Frontend: When a simple API is not enough
In a previous article, we wrote about using SDKs and APIs to integrate products with the backend. Now we are going to talk about Backend-for-Frontend technology. It simplifies creating services that work simultaneously with many different clients: computers, smartphones and tablets with all operating systems.
The Backend-for-Frontend (BFF) approach was developed at SoundCloud. Back in 2015, Phil Calçado, the Director of Engineering and SoundCloud platform, described BFF as a natural step in the evolution of the modern IT products.
In the past analog ages, corporate systems were only used by the companies themselves. The more digitalization and omnichannel developed, the more the focus shifted from the corporate infrastructure to the outside. Customers began to buy goods online using their smartphones and business partners began to interact with the company through web platforms. It became important for business to build an architecture that would allow such access to corporate resources.
Developers have started to create APIs so that third-party IT services can connect to the infrastructure. The drawback of this technology is that it offers the same set of features to everyone. If you need to limit the amount of traffic on smartphones and offer tablet users their own method of data entry, it can be difficult.
SoundCloud had an even more difficult task as the company needed to integrate with third-party developers so that they could embed the player into their platforms. To do this, an out-of-the-box API would need to interact with all platforms, and with each update, the team would have to make sure that the refinement does not break all these integrations. In practice, this is unrealistic.
That’s how the concept of Backend-for-Frontend was born, a lightweight service that is closer to the frontend than to the backend.
BFF features
The key word is lightweight; BFF has a much smaller feature list than the API:
- Ability to work with the product’s microservices and receive data from them;
- Format this data so that it is processed correctly on the frontend;
- Send data to the frontend.
The company can support several BFFs at a time: for PC users, for Android, for iOS, etc. And from the developers’ point of view, the main advantages are getting rid of many technical limitations of the backend and speeding up the release of features:
- You can build the backend and APIs from a lined-up client path and product, not the other way around.
- You can agree on an interaction contract early in development and make a mockup to build the application by calling the API.
- It becomes easier to manage mobile app access to the backend.
BFF is now used by many major technology companies, such as Netflix and Flickr. It is recommended by Microsoft and IBM. We will share our experience from a recent project.
How we use the BFF
In one of our mobile applications, the main resource for all services on the customer side is the website. Behind it is the RabbitMQ bus, which picks up incoming events from the site and returns query results.
The site has an API, but for a mobile app, its functions were not always enough. Without going into details, let’s say that these are roughly the same difficulties we wrote about above. So, when we were launching a new product sale in the app, we built our own BFF to handle its requests. As a result, we can send messages to Rabbit ourselves and read its responses.
This architecture speeds up data updates in our product, which occasionally occurred when working through the API. Previously, our product received data from our own online store database, and when working directly with Rabbit, it was impossible to just update the data. With the introduction of BFF, we launched a new Data Provider module, which allows you not to go to the IM for information updates.
In addition, this is how we were able to organize the work of the customer’s asynchronous API with our synchronous service: the logic of BFF allows us to wait for all the requests to be processed before passing the data to our product. And when the customer decides to update their API in the future, we will only need to make minimal improvements just adjusting BFF to the new conditions.
What to keep in mind when creating a BFF?
BFF-service should be easy, this is its main difference from API. You don’t need to write complex business logic in your code, build a database, etc. The priority should be simple data exchange.
As we said, a product can have several BFF services for different clients. They will inevitably duplicate each other in some part, but you have to make sure it’s within reason, otherwise you’ll be spending unnecessary resources to support them.
You have to understand that BFF is something like a translator between the backend and the frontend. Therefore, security, fault tolerance, and monitoring need to be built additionally.