Doing BFF with Node.js is a well-known practice, but what exactly does the BFF layer do? Under what circumstances is suitable for BFF layer construction? This article will answer these questions.

Since its birth, Node.js has become a weapon in the hands of front-end engineers, expanding the boundaries of the front end. After all these years, what is everyone doing with Node.js? The header is my summary of the Node.js application scenario, and the dark green is the active Layout of Node.js.

The three application scenarios of Node.js include CLI/IDE, front-end r&d system server, and BFF layer of business system.

Our daily development of the system mainly has two kinds, one is business system, the other is research and development system.

Front-end research and development system, common Serverless research and development platform, low code platform, small program research and development platform and traditional construction and deployment platform. As the front-end students in the control of the scope, stability and other requirements are not so strict, naturally become the main use of Node.js. In such a system, Node.js is used as a server language, taking on the same responsibilities as traditional Java servers. These systems also often have CLI or IDE involvement on the side, which is another major scenario for Node.js, such as the familiar UMI, small program IDE and Serverless command-line tools.

Business system is the key to the development of the company. In the field of business code, Java is the main force of the service side, but some small and medium-sized companies choose Node.js, such as the familiar language of ants. Facing such enterprise-level scenarios, domestic Node.js ecosystem has egg.js, but foreign Nex.js tends to catch up with its powerful functions and rich ecology.

In the business code world, Node.js is currently active in the BFF layer, and the Midway team from Alibaba’s Node.js ecosystem told THE D2 conference that they are optimistic about Node.js’s future in the BFF layer, which means they are not optimistic about Node.js’s future in the business server side.

So let’s move on to BFF. BFF stands For Backends For Frontends, the layer between front-end applications and underlying services that provide services to the front-end.

Before exploring BFF, let’s take a look at another important concept — API Gateway.

Also between front-end applications and underlying services, API gateways are a common structure in the server ecosystem.

The BFF’s relationship to the API gateway can take many forms and can act as an API gateway, either before or after the API gateway. Being behind the API gateway is a common situation, and if you want to replace or set up in front of the API gateway, the BFF needs to have some API gateway capabilities. In addition, the main difference between BFF and API gateway is that BFF is thicker than API gateway and can be mastered by the business side at the code level.

So what can the BFF layer do?

I summarize it in three layers, page services, gateways, and aggregation.

  • Page services. Since the front and back ends have been separated, the front end’s page services are provided by separate services. BFF can provide page services, on this basis can also do SSR, greatly improve the performance of page loading. In addition, logical data can be passed to the base page to inject some basic configuration or state into the front end, which can be useful in some scenarios.
  • A gateway. You can refer to the functions of the gateway mentioned above. Common functions at the BFF layer include the identification and transparent transmission of user identity with SSO unified login service, flow control, attack defense, operation log, and cross-domain interface forwarding.
  • The aggregation layer. BFF is responsible for the aggregation and processing of interface data on the server. This section will focus on the adaptation scenarios of the aggregation layer.
  • The other. In addition to the above three main scenarios, there are several independent lightweight services suitable for BFF, such as image uploading and WebSocket services.

Focus on BFF layer polymerization. What is the purpose of BFF aggregation?

In order to improve efficiency, front-end and back-end interface docking has always been criticized. In the scenario of frequent interface changes, enabling the front-end team to achieve full stack can avoid a large number of interface docking. In addition, BFF architecture achieves the separation of front-end and back-end concerns, and back-end students can focus more on business model building and improve human efficiency through microservices. Front-end students can focus on user experience and use BFF to develop scenarios with frequent business changes and new terminals.

When is it appropriate to use BFF layer for interface aggregation?

  1. There are stable domain services on the back end that require an aggregation layer. This is common in today’s microservices era.
  2. Requirements change frequently, and interfaces often need to change. Back-end services serve multiple front-end projects, such as multiple ends, which are costly to change. BFF layer For a single project, data aggregation, tailoring and adaptation in the BFF layer can achieve minimal cost changes.

I understand that if there is one of these two conditions and the team has sufficient manpower, BFF can be considered for aggregation. However, a complete node.js service infrastructure, including logging, link tracing, exceptions, and performance monitoring, is also a prerequisite for implementing BFF to ensure stable and verifiable services.

Typical scenario analysis of BFF aggregation layer.

Can see from the share in the industry, ali’s gold and flying pigs is a universal business BFF, Scott scenario has long distance along the weather, the search and navigation Tips, etc., the weather, the content of geographic information, etc in certain scenarios aggregated query, comply with the above mentioned field service stability and the characteristics of the scene changes frequently. Feizhu mainly mentioned the aggregation of data sources such as content center, evaluation system and interactive data on the content details page.

In the field of middle and background, we can see the BFF practice introduction of ICBU cross-border supply chain team. One of their characteristics is that they are oriented to many users, and their stable back-end micro services make their BFF aggregation layer have a great use.

How should THE BFF layer be constructed?

The trend is to use Serverless, mainly because Serverless is a good fit for BFF because it is lightweight and easy to scale. See appendix “Serverless is your BFF”.

I hope this summary of the responsibilities and scenarios of the BFF model will be helpful.

Appendix:

  • Autonavi Serverless platform construction and practice
  • Flying Pig based on Serverless cloud + end practice and thinking
  • ICBU Cross-border Supply chain front-end architecture evolution and Serverless practice
  • Serverless is Your BFF