In one of the previous articles, we wrote about using the SDK and API to integrate products with the backend. We continue the topic – now we will talk about Backend-for-Frontend technology. It simplifies the development of services that many different clients work with at the same time: computers, smartphones and tablets with all possible operating systems.
The Backend-for-Frontend (BFF) approach was developed at SoundCloud. Back in 2015, the head of the SoundCloud development department, Phil Calçado, described BFF as a natural stage of evolution that modern IT products have gone through.
In the past, in the analog world, corporate systems were used only 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 and from smartphones, 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 creating APIs so that third-party IT services can connect to the infrastructure. The disadvantage of this technology is that it offers everyone the same set of features. If you need to limit the amount of traffic on smartphones, and offer tablet users their own method of data entry, difficulties may begin.
The task of SoundCloud was even more difficult – the company needed to integrate with third-party developers so that they could embed the player into their platforms. To do this, the API must interact with any platforms out of the box, and with each update, the team needs to make sure that the revision does not break all these integrations. In practice, this is impossible to achieve.
And so the concept of Backend-for-Frontend was born – a lightweight service that lies closer to the frontend than to the back.
The keyword is “lightweight”, the list of features of the BFF is much smaller than that of the API:
- Work with the microservices of the product 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 simultaneously support several BFF: for PC users, for Android, for iOS, etc. And from the point of view of developers, the main advantages are getting rid of many technical limitations of the backend and speeding up the release of features:
You can build a backend and API from a built-in client path and product, and not vice versa.
You can already agree on an interaction contract at an early stage of development and make a mockup to build an application by calling the API.
It becomes easier to manage mobile app access to the backend.
Now many major technology companies use BFF in their practice – for example, Netflix and Flickr. It is recommended by Microsoft and IBM. We will share our experience from one of the recent projects.
How we use BFF
In one of our mobile applications, the main resource for all services on the part of the customer is the website. Behind it is the RabbitMQ bus, which picks up incoming events from the site and returns the result of requests.
The site has an API, but its functions were not always enough for a mobile application. Without going into details, let’s say that these are about the same difficulties that we wrote about above. Therefore, when we launched the sale of a new product in the application, we built our own BFF to handle its requests. As a result, we can send messages to Rabbit ourselves and read his answers.
This architecture accelerates the updating of data in our product, which periodically occurred when working through the API. Previously, our product received data from its own database of the online store, and when working directly with Rabbit, it was simply impossible to update the data. With the introduction of BFF, we have launched a new Data Provider module, which allows you not to go to 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 BFF logic allows us to wait until all requests are processed before transmitting data to our product. And when the customer decides to update his API in the future, minimal improvements will be required from our side – just reorient the BFF to new conditions.
What you need to remember when creating a BFF
The BFF service should be lightweight – this is its main difference from the API. It is not necessary to prescribe complex business logic in the 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 need to make sure that this does not go beyond the reasonable, otherwise you will spend extra resources to support them.
You need 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.