According to the translator
When studying BFF, the translator had the honor to read the series of articles written by furukawa Yosuke, and gained a lot. Since THERE is no similar Chinese material on the Internet, I want to translate it into Chinese and share it with my friends.
preface
In this series, “Front-end Development in the Age of Microservices/apis,” we will cover the much-discussed BFF(Backends For Frontends). In this article, we will introduce five typical use cases of BFF.
In the previous post [Front-end Development in the Microservices /API era] BFF Super Primer –Netflix, Twitter, Recruit’s Reasons for choosing BFF, I gave an overview and case study of BFF.
It may be difficult to understand what a BFF does, but in a nutshell, the API server takes care of the logical parts of the business domain, and the BFF is the server that supports the user interface. If Web applications can be created simply using domain logic, then BFF is not required. But in the era of microservices/apis, front-end development increasingly requires “summary apis” and “server-side rendering.” (For more on domain-driven design DDD, see my DDD column.)
So, this time, we’ll introduce five typical use cases for BFF.
- API Gateway
- Server Side Rendering
- Session Management
- File upload
- WebSocket, Server Sent Events, and Long Polling
Use cases for BFF can be divided into two categories: those that substitute for client functionality like Server Side Rendering, or those that act as an intermediary between back-end API Server and client and simplify API implementation.
However, it is an anti-pattern to do anything with BFF. The BFF is used for the use cases described in this article, but it is also important not to make the BFF as thick as possible by changing the server-side or client-side implementation of the back-end API. I’ll talk more about anti-patterns next time.
API Gateway
An API Gateway, as the name suggests, is an entry point to an API. Act as a bridge to back-end apis, aggregating multiple apis into one, or translating the response results of the API into the format required by the client.
The API Gateway provides the following functions:
- API Aggregation that integrates the back-end API
- Translate API data for customers
- The API query results are stored in the API Cache in the Cache
- An API Filter that filters information in AN API response to reduce the size of the data
In this article, we will explain API Aggregation as a typical feature.
When a client is built using microservices, a function may be implemented by multiple apis (multiple microservices). For example, “When displaying the page, get the list information of the diary from the diary list API, and get multiple comments from the comment list API at the same time.” In this case, multiple apis need to be requested simultaneously.
However, there is a limit to how many requests a browser can make simultaneously. With HTTP / 1.1, a maximum of six connections can be established at a time. Even if you want to request the API in bulk, you will receive this limitation. In addition, checking the session and establishing a TCP connection each time a request is made adds to the cost of connecting to the server.
BFF can merge this API into one request. This is not limited by the number of browser requests. In addition, because only one session check and TCP connection is required, network resources can be accessed more efficiently.
For details about other functions of the API Gateway, see API Gateway Pattern.
Server Side Rendering
Taking JSON from the server and building the HTML on the client side is called “client-side rendering,” while building the HTML using common code on both the client and server is called server-side rendering (SSR).
Today’s Web applications not only return HTML, but in many cases build the HTML on the client side using JSON as a data format, but there are still many cases where the server is required to render the HTML, especially for “search engine optimization” and “accelerated initial display.”
Search engine optimization
Search engine crawler represented by Google has the function of executing JavaScript and can create index after constructing HTML through Client Side Rendering. However, search engine crawlers are not perfect, and JavaScript execution is not always efficient. Some crawlers do not support the new JavaScript syntax. If it is an infinitely scrolling web page, the content will only be refreshed when the page is scrolling. Since crawlers cannot scroll the page, they cannot obtain the updated content after scrolling.
For SEARCH engine optimization, it is recommended to build the information you want to put into the search engine in HTML from the start (see: Google SEO recommends pre-rendering sites using the JS framework).
Acceleration initial display
In addition, in Client Side Rendering, JavaScript needs to be loaded first to build HTML, which takes more time. In Server Side Rendering, HTML is present from the beginning, so initial Rendering is faster.
Universal Application
Server Side Rendering typically builds HTML using a common mechanism that works on both Client Side and Server Side. If you focus solely on implementation, you might build views on both the client and server side, which could easily lead to repetitive development. To avoid this, you need to use the same mechanism (JavaScript in the case of a Web application) for rendering on both the server and client sides. This mechanism is called “universal application”.
There have been a number of recent cases where react. js or Vue. Js has been used for rendering on both the client and server. React.js has a “next.js” framework for server-side rendering. Server-side rendering is also relatively easy in vue.js using frameworks such as “nuxt.js”.
Session Management
Session management is the function of retaining user information.
A session management session refers to a user session during two-way communication between a client and a server. In order to manage user sessions, the server needs to know who the client is. In many cases, we provide cookies to visiting users and manage the “user information” associated with the cookies. The user information includes the user ID, name, profile picture, and “Logged in or not”.
This user information is frequently accessed and requires high-speed access. Therefore, it tends to be stored in a cache such as Redis or memcached. If BFF can retrieve information such as “who is the client” from the high-speed data store, the back-end server does not need to maintain the state of the user, and the IMPLEMENTATION of the API server becomes simple.
Let’s think specifically about EC (e-commerce) services that use shopping carts. In EC services, the following operations are often performed.
- Displays the items to be purchased
- Add the items you want to buy to your shopping cart
- Pay at the cashier
Since the purchase has not been established at the time of the step 2 action, we store the item data in the shopping cart into the session rather than sending a request to reduce the item inventory to the back-end API. When you perform the actions in Step 3, the process is complete and the request to reduce the inventory of the item is made to the back end.
In this way, session management is used to maintain a temporary state for the client.
If you don’t have BFF, you can use client-side storage, such as cookies, local storage, and index databases. In this case, however, you cannot manage a large number of states, and you need to be aware of security issues.
In addition, if you let the back-end API server manage the session, you need to store the same state on all the other microservice API servers, which increases repetitive processing. Using BFF for session management reduces security risks while making back-end apis simpler to implement.
Upload a file
File uploading refers to the function of uploading media files such as pictures and videos and text files such as TXT and CSV. When a file is uploaded, it is often chunked up based on its size and sent bit by bit, so it is difficult to implement through simple request/response processing, which is relatively difficult to implement as an API. Having the BFF responsible for this layer simplifies the implementation of the API server.
File uploads also tend to be inefficient if they are built using only client and API servers without BFF. A particularly common practice is to encode the contents of a file in such a way as Base64 on the client side, convert it into text information, and then POST it to the server as JSON.
When encoded in Base64, it is converted to text containing padding and newline characters, so the capacity increases to about 1.4 times. If it is a 5MB file, it will be sent in 7MB size, which is very inefficient.
To reduce the amount of data transferred, you can block files, send them bit by bit as binary data, or send them as multi-parts of a FORM rather than, say, text-based JSON. In this case, you can’t use a simple JSON-based API.
Therefore, BFF will be responsible for the primary receiver of file uploads. It accepts files using form/multi-part instead of JSON, chunks large files, receives the chunked data bit by bit, and saves the files to the server.
By doing so, you simply pass the file storage path to the back-end API, keeping the IMPLEMENTATION of the API simple.
As such, the API proxy between the backend API server and the client is also one of the roles of the BFF. File uploads are an example, and the following WebSocket is a similar example.
WebSocket, Server Sent Events, and Long Polling
WebSocket, Server Sent Events, and Long Polling are HTTP extensions for instant communication between clients and servers. In particular, WebSocket is a communication mode suitable for chat, synchronous editing and other real-time applications, and is widely used in SNS and other applications. Similarly, Server Sent Events and Long Polling are a communication method used when receiving instant notifications and performing processing.
These implementations are quite different from API servers that use JSON format for simple interactions. You need to set up an Endpoint that accepts WebSocket, where data is exchanged in real time and stored in database tables. With BFF as the endpoint, the implementation of the back-end API server becomes much simpler.
The following figure shows the real-time communication between the API server and the client for which BFF is responsible
The browser acting as the client performs “Establish a connection with WebSocket and send a message”. The sent message is received by the BFF, and the BFF performs 2. Put the message into the message queue.
Message queuing performs “3. Send messages to all BFF instances” (As the number of clients simultaneously connected to the BFF server increases, BFF instances need to be created on multiple servers to maintain high availability).
After receiving the message in the queue, it sends a message to the recipient. 4. Another client receives the message. After completing these real-time synchronization processes, BFF performs the “5. Register messages on the backend server” process.
Similar to the previous File Upload, a back-end API is read here.
How do I get started with BFF
In this article, we introduce 5 typical cases.
- API Gateway
- Server Side Rendering
- Session Management
- File upload
- WebSocket, Server Sent Events, and Long Polling
In addition, there are other use cases, such as the “Circuit Breaker” feature that returns temporary data when the back-end API is interrupted and the “API cache” feature.
However, if everything is put on the BFF, the load will be concentrated on the BFF and it may not be able to perform its original duties. BFF is the server at the user interface layer, and because of the architectural pattern of building microservices and rich Web applications, it is not recommended to implement too much functionality on BFF.
It is suggested to start with typical usage such as API Gateway and Server Side Rendering and gradually increase functions. So in the next article, I’ll show you how to get started with BFF.