BFF super entry
What is BFF (Backends For Frontends)
As the name suggests, it is the backend (server) of the frontend. A server that calls the API specifically for the front end, or generates HTML. At this point you might be thinking, "how is this different from a traditional web application server?". It's essentially the same, it's just that it's built specifically for the front end.
First of all, the web application server has the following purposes:
- Get and update data from middleware such as databases and full-text search engines
- create a page
- Obtain input information from the user as an HTTP interface
Here, the part that fetches and updates data from databases and full-text search engines is designed to manage while ensuring data integrity and reliability. The part that builds the page and the part that gets the user input information corresponds to the user interface (UI), and the purpose is to improve the user experience (UX).
The former is used as the backend (Backends), while the latter is used as the frontend (Frontends). Through the division of the front and back ends, developers can focus on their respective professional fields. This kind of architecture design is called "BFF".
The outline diagram is as follows:
Like this, BFF often takes the configuration of "set between the reverse proxy and the backend API server". A reverse proxy is a server used to replace a web application server for static file compression and caching. The back-end API server mainly cooperates with middleware such as databases and full-text search engines to operate resources and manage data.
BFF is responsible for UI/UX-related functions, such as creating a page between the two servers, accepting user input and sending it to the backend.
The technical background and historical background of BFF
In order to know why BFF is needed, it is necessary to understand the background of "the internal structure of the application is constantly changing with the development of the times".
Traditional web applications are based on HTML and have relatively simple functions. Especially when CGI is dominant, many applications are mainly composed of HTML, and JavaScript only does some interaction. The web application server of this era is usually a monolithic application (Monolithic application), and all the work from database interaction to HTML construction is completed on this server.
In addition, as the number of clients other than web applications (such as mobile applications) increases, the server side needs to build APIs that focus on a certain field. It has evolved into "architectures that specialize in specific resources" as it is called microservices.
However, as clients become more diverse, it becomes increasingly difficult to create an API server that meets the needs of all clients. The mobile application and web application you create have different UIs, and the content that needs to be displayed on different clients may also be different. For example, if you create a web application, the information the user can see may be different on PC and smartphone due to different screen sizes, and even the UI may be completely different from the mobile application.
Also, web applications have environmental limitations, such as the limit of 6 requests that can be requested simultaneously in HTTP/1.1.
In response to these situations, an architecture has emerged that places the server responding to each client request on the front end, acting as a bridge with the backend API server. This is because BFF has advantages such as building HTML and reducing the number of requests.
In this way, an architecture called "BFF" was born.
Front-end engineer or back-end engineer, who is in charge?
BFFs are usually developed by front-end engineers responsible for the client. Since BFF is a server, it may be thought that it will be developed by back-end engineers, but since it is a server that helps build and operate the UI, it is the responsibility of front-end engineers.
In the BFF architecture, backend engineers are responsible for managing resources based on the API.
When to use the BFF architectural pattern and when not to use it
The BFF architectural pattern has the effects of "making UI construction easier through a dedicated front-end server" and "dividing the architectural level and clarifying roles through the boundary between the front and back ends". It can make the front and back ends easier to develop independently.
The BFF architectural pattern is very effective when "have back-end and front-end teams, each developing independently". BFF can also combine APIs when "multiple clients need to be supported and each client uses the same API". In web applications, it can also be used to build HTML.
The opposite is true when BFF mode is not used. Carrying out the development of Monolithic Pattern and expanding the scope of responsibilities of developers can shorten the development cycle and improve development efficiency. When there is only one type of client, it's up to the backend server to build the HTML or build the API for a specific client, and it's ok without BFF.
The adaptability of BFF varies according to the organizational structure and development goals of the development team. Therefore, whether to adopt BFF can be tailored to local conditions.
BFF Case Studies - Netflix, Twitter, Recruit
Here are some specific cases of BFF.
Netflix case
Netflix used a similar architecture before it was named BFF. As of 2012, Netflix's technical blog "Embracing the Differences : Inside the Netflix API Redesign" introduces it under the name "Client Adapter".
The architecture under the name BFF has only recently become popular. In fact, many companies have been practicing it for a long time. For Netflix in particular, it runs on a wide variety of clients, including devices like PCs, mobile devices, game consoles, and car navigation systems. Due to the diversity of clients, it is quite difficult to use an API to adapt to all clients ("one size fits all"), so this Client Adapter mode is introduced.
twitter case
Twitter has created an application for the mobile web called "Twitter Lite", which is also built using the BFF architecture.
The backend API is built as microservices using Scala technology. When the web application displays pages, Node.js is used to organize the back-end API.
Twitter was originally built using Ruby on Rails as a Monolithic Server. As time goes by, the scale of users continues to expand, and the original architecture gradually cannot meet the expansion of scale. So Scala was used to refactor the backend into microservices, and BFF was used as a mechanism to optimize UI/UX to conform to the latest trend of the current architecture.
Recruit case
Recruit is already on the way to practice BFF. For example, a product called "Booking Form" was built with BFF. In addition, SNS, questionnaire applications, and schedule management applications are also BFF architectures.
Basically, it is usually built with the following diagram.
The BFF layer is built using Node.js, which is responsible for putting together the API and rendering HTML. There are several reasons for this, but the main reason is that Node.js and front-end JavaScript use the same syntax. Backend APIs are usually developed in languages like Java and Go, which are typed and easy to manage data.