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 focus on a summary and examples of BFF as a “super primer”. Part 2 will show you how to create the BFF, and Part 3 will show you the process of creating microservices/apis using the BFF by the front-end developer.

The target audience is those with Web application development experience, front-end developers, and those who are building microservices.

What is BFF(Backends For Frontends)?

As the name implies, it is the back end (server) of the front end. A server that calls apis specifically for the front end, or generates HTML. You might look at this and think, “How is this different from a traditional Web application server?” . It’s essentially the same, it’s just different to build it specifically for the front end.

First, Web application servers serve several purposes:

  • Get and update data from databases and middleware such as full-text search engines
  • Create a page
  • Gets input information from the user as an HTTP interface

Here, the portion of obtaining and updating data from databases and full-text search engines is intended for administration while ensuring data integrity and reliability. The part that builds the page and the part that gets user input corresponds to the user interface (UI) and is intended to improve the user experience (UX).

The former acts as the Backends and the latter Frontends to allow developers to focus on their respective areas of expertise, an architectural design known as the “BFF.”

The outline is shown below

graph LR
Browser --> ReverseProxy[Reverse Proxy] --> BackendsForFrontends[Backends For Frontends] --> UserAPI[User API]
BackendsForFrontends --> DiaryAPI[Diary API]
BackendsForFrontends --> ImageAPI[Image API]

As such, BFF tends to take a “set between the reverse proxy and the back-end API server” configuration. A reverse proxy is a server that replaces a Web application server for static file compression and caching. Back-end API servers mainly cooperate with databases, full-text search engines and other middleware to operate resources and manage data.

The BFF is responsible for UI/ UX-related functions, such as creating a page between the two servers that accepts user input and sends it to the back end.

Sam Newman, author of Building Microservices, explains this in detail.

The technical background and historical background of BFF

In order to understand why BFF is needed, it is necessary to understand the context of how the internal structure of an application changes over time.

Traditional Web applications are based on HTML and have relatively simple functions. Especially when it comes to CGI, a lot of applications are made mostly of HTML, and JavaScript just does some interaction. The Web application server of this era is typically a Monolithic application, where everything from database interaction to HTML building is done on one server.

graph LR Browser --> node1[Monolithic Web Application] --> node21[Database] node1 --> node22[Full Text Search] node1 -->  node23[NFS]

In the early 21st century, the concept of Ajax communication using JavaScript for HTTP requests became popular, and Web applications became richer and more interactive. As the number of rich Web applications increases and more processing is concentrated on the client side, the server side is increasingly using apis that simply send and receive data.

graph LR
Browser --> node1[Backend API] --> node21[Database]
node1 --> node22[Full Text Search]
node1 --> node23[NFS]

In addition, as the number of clients other than Web applications (such as mobile applications) increases, the server side needs to build an API that focuses on one domain. It has evolved into an “architecture dedicated to specific resources,” as it is called microservices.

graph LR Browser --> node11[User API] Browser --> node12[Diary API] Browser --> node13[Image API] Mobile[Mobile App] -->  node11 Mobile --> node12 Mobile --> node13 node11--> node21[Database] node12 --> node22[Full Text Search] node13 --> node23[NFS] node12--> node21 node13--> node21

However, as clients become more diverse, it becomes increasingly difficult to create AN API server that meets the needs of all clients. The UI you create for mobile apps and Web apps will be different, and the content you need to display on different clients will be different. For example, if you create a Web application, the information users can see may be different on a PC and a smartphone due to the screen size, or even the UI may be completely different from that of a mobile application.

In addition, Web applications have environmental limitations, such as a 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 that responds to each client request on the front end, acting as a bridge to the back-end API server. This is because BFF has the advantages of building HTML and reducing the number of requests.

graph LR

Browser --> node01[Web App's BFF]
Mobile[Mobile App] --> node02[Mobile App's BFF]
node01 --> node11[User API] 
node01 --> node12[Diary API]
node01 --> node13[Image API]
node02 --> node11
node02 --> node12
node02 --> node13
node11--> node21[Database]
node12 --> node22[Full Text Search]
node13 --> node23[NFS]
node12--> node21
node13--> node21

Thus, an architecture called “BFF” was born.

Front end engineer or back end engineer, who is responsible?

BFF is usually developed by the front-end engineer responsible for the client side. Since the BFF is a server, you might expect it to be developed by a back-end engineer, but since it is a server that helps build and manipulate the UI, that is the responsibility of the front-end engineer.

In the BFF architecture, backend engineers are responsible for managing resources based on the API.

How to make a BFF will be explained in detail in the next article, “How to Make a BFF”.

When to use and when not to use BFF architectural patterns

The BFF architectural pattern has the effect of “making IT easier to build UI with dedicated servers on the front end” and “defining roles by dividing architectural hierarchies with boundaries between the front and back ends”. This makes it easier to develop the front and back ends independently.

The BFF architectural pattern works well when “you have back-end and front-end teams, each developing independently.” BFF can also group apis together 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.

When the BFF pattern is not used, the opposite is true. By developing the Monolithic Pattern and expanding the scope of developers’ responsibilities, the development cycle can be shortened and the development efficiency can be improved. When there is only one type of client, the backend server builds the HTML or builds the API for a particular client without BFF.

The suitability of BFF varies according to the organizational structure and development goals of the development team, so whether or not to adopt BFF can be tailored to local conditions.

BFF case Studies -Netflix, Twitter, Recruit

The following are some specific cases of BFF.

Netflix case

Netflix used a similar architecture before naming it BFF. As of 2012, Netflix’s technology blog, “Embracing the Differences: Inside the Netflix API Redesign,” introduced it as “Client Adapter.”

The architecture under the name BFF has only recently become popular. In fact, many companies have been doing this for a long time. For Netflix in particular, it runs on a variety of clients, including PCS, mobile devices, game consoles and car navigation systems. Due to the diversity of clients, it is quite difficult to fit all clients with one API (” one size fits all “), so this Client Adapter pattern was introduced.

Twitter case

Twitter has created an application for the mobile web called Twitter Lite, which is also built using the BFF architecture.

The back-end API is built as a microservice using Scala technology. Node.js is used to organize the back-end API when presenting the Web application page.

Twitter was originally built using Ruby on Rails as a Monolithic Server. As time went on, the scale of the user grew, and the initial architecture became increasingly inadequate. Refactoring the back end into microservices in Scala and using BFF as a mechanism to optimize UI/UX to keep up with current architectural trends.

See Twitter’s tech blog “How We Built Twitter Lite” for details.

Recruit case

Recruit is already on its way to practicing BFF. For example, a product called “Reservation Table” is built with BFF. Social networking services, questionnaire applications, and schedule management applications are also BFF architectures.

Basically, it is usually built with the following figure.

The BFF layer is built using Node.js and is responsible for putting apis together and rendering HTML. There are several reasons for this, but the main reason is that Node.js and the front-end JavaScript use the same syntax. Back-end apis are typically developed in languages such as Java and Go, which are typed and easy to manage data.

The reservation application uses technologies described in the 2016 Node Gakuen festival and Recruit Lifestyle blog for reference.

The next article explains how to build the BFF in detail.

Next, how do front-end engineers do BFF

In this chapter, we explained the definition, background and cases of BFF. BFF is not new. Some companies have been using it for a long time, and some are doing it.

I think the name BFF has emerged in recent years in the context of “on the one hand the server side as a microservice is reducing its functionality and on the other hand the client side is increasingly demanding.” At the same time, front-end engineers are no longer just developing the client side, but also getting involved in the development of the server side.

However, I don’t think many people are used to it yet, so I’ll look at “how to do it” with a real case in the next article. Stay tuned.