Backend-for-Frontend technology simplifies the development of services with which many different clients work simultaneously: computers, smartphones and tablets with all possible operating systems.
The Backend-for-Frontend (BFF) approach was developed by SoundCloud. SoundCloud's head of development, Phil Calçado, described BFF back in 2015 as a natural evolutionary stage for modern IT products.
In the past, in the analog world, only companies used corporate systems. 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 such an architecture that would allow such access to corporate resources.
Developers started building APIs so that third-party IT services could connect to the infrastructure. The disadvantage of this technology is that it offers everyone the same set of capabilities. If you need to limit the amount of traffic on smartphones, and offer tablet users their own method of data entry, difficulties can begin.
SoundCloud's task was even more difficult - the company needed to integrate with third-party developers so that they could embed the player into their sites. To do this, the API must interact with any platform 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 unrealistic to achieve.
This is how the concept of Backend-for-Frontend was born - a lightweight service that lies closer to the front-end than to the back-end.
BFF features
The key word is "lightweight", the list of features of the BFF is much less than that of the API:
Work with product microservices and receive data from them.
Format this data so that it is processed correctly on the frontend.
Send data to the frontend.
BFF: , Android, iOS .. – :
API , .
, , API.
.
BFF – , Netflix Flickr. Microsoft IBM. True Engineering.
BFF
. RabbitMQ, .
API, . , , , . , , BFF, . Rabbit- .
, API. -, Rabbit . BFF Data Provider, .
, API – BFF , , . API , – BFF .
, BFF
A BFF service should be lightweight - this is its main difference from an API. No need to write complex business logic in the code, build a database, etc. Simple communication should be a priority.
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, monitoring need to be built additionally.