Difficult problems in front-end development Multi-end
applications, different types of clients have personalized requirements for data and APIs
Service aggregation, a single back-end provides interfaces for multiple front-end teams, leading to inefficient cross-team collaboration and difficult resource coordination
issues: services Is the interface designed for the terminal oriented to UI or general service?
BFF
solution: Backends For Frontends, referred to as BFF.
The most suitable scenario for BFF, providing customized APIs and other differentiated scenarios for third parties, each user experience (client) corresponds to a backend,
As the user experience adaptation layer, BFF combines and processes the back-end interface and performs data cropping, formatting, aggregation, and orchestration.
In the BFF concept, the most important point is: service autonomy, who uses who develops, so it is generally maintained by the front end.
The BFF implementation does not limit the specific technology and can be freely selected: Java / Node / PHP / Python, but most front-end teams will choose Node.js.
The evolutionary process of
BFF BFF and gateway (API Gateway) are two important concepts in the microservice architecture. The emergence process of BFF can be explained by the following example
Service-oriented architecture V1
realizes the deconstruction and separation of single-block applications, microservices are initially completed, and the front-end user experience layer is mainly traditional server-side Web applications. The service-oriented architecture is as follows:
Service-based architecture V2
With the popularity of wireless applications, in addition to Web applications, services also need to provide interfaces and data for new wireless native apps. First, the following service architecture is adopted:
The problems with such an architecture are:
The wireless app is strongly coupled with the internal microservices. The
wireless app needs to know the details of the internal service address and other details. The
wireless app needs to perform a large amount of aggregation tailoring and adaptation logic on the interface data.
Service-oriented architecture V2.1
In order to solve this problem, at the user experience layer and The BFF layer is introduced between the internal microservice layers to adapt the backend microservices. It is expected that the user experience layer exposes the number and unified API to facilitate wireless devices to access the backend services.
This architecture solves the above problems:
The wireless App is decoupled from the internal microservices and can be changed independently on both sides. The
wireless App only needs to know the address of the BFF, and the service interface is unified. There is no need to care about the address and details of the internal complex
microservices. With logic, these steps are completed in BFF,
but as the number of access devices increases, there will be some problems:
There is only one BFF. The increase in access equipment leads to the consideration of matching issues. The high cost of communication and coordination between teams.
BFF not only includes the aggregation and tailoring, adaptation and business logic of each business line, but also needs to introduce a lot of cross-section logic, such as Security certification, log monitoring, current limiting and fusing, etc., these codes are mixed together, resulting in increased code complexity.
If an error occurs, all applications will be unavailable.
Microservice architecture V3
To solve this problem, API Gateway was introduced
Under this architecture:
BFF is decoupled and split according to teams and business lines, and is split into several BFF microservices. Each business line develops and delivers its own BFF microservice
gateway in parallel . Generally, an independent team is responsible for operation and maintenance, focusing on cross-sections. Functions, including
routing, routing requests from wireless devices to a microservice BFF cluster
authentication on the back end, centralized authentication and
monitoring of API access involving sensitive data, performance monitoring of API calls, and
current limiting and fusing, the gateway can Carry out current limiting and fusing, protect back-end services,
secure anti-climbing, collect access logs, analyze malicious behavior in the background, and block malicious requests. The
gateway introduces another layer between the client and BFF, allowing both sides to change independently.
Microservice architecture V4
The V3 architecture can be optimized, and the traditional server-side Web application mode can be changed to a front-back separation architecture. The front-end uses H5 single-page technology to provide users with a better experience.
At the same time, it increases the ability of which third-party application to open the API
Expanding new access channels and forming a completed modern microservice architecture, from outside to inside: end user experience layer-> gateway layer-> BFF layer-> microservice layer
The specific implementation of
subdivision strength
requires that a large backend be split into multiple small backends. There are three ways
User experience level (UI)
end level
Team level It is
generally recommended to split according to user experience level
Connect downstream services (microservices)
(1) How to connect different downstream services of multiple technology stacks
RPC protocol call
(2) How to manage and combine calls
Use RXJava, Finagle and other event mechanisms to simplify these asynchronous process control
(3) How to ensure availability when a call fails
Fault tolerance at the BFF layer, while the front end is guaranteed to accept incomplete corresponding content
Multiplexing problem After
splitting, redundant codes will be generated between multiple BFFs, which is inevitable.
API gateway layer can be added to put general back-end logic (authorization, authentication, current limiting) into it
If you want to eliminate redundancy, and do not want to cause tight coupling between BFFs because of the separation of reusable code, there is a compromise attitude: tolerate redundancy between BFFs and eliminate redundancy within a single BFF. That is to allow a certain degree of redundancy between BFF
Ant Wealth BFF Practice
In 2016, Tang Yao introduced the practice of BFF in the Ant Wealth project.
Before the introduction of BFF, Ant Wealth's business also encountered the problems mentioned above, mainly because the experience layer API often changes, resulting in low development efficiency.
So the introduction of BFF, the main purpose is to carry out data: cutting, formatting, aggregation, arrangement.
An ideal model is as follows:
In the actual landing process, the following structure was formed:
During the actual combat, they mainly solved the following problems:
(1) Communication between Node.js and Java
Data: Cross-language serialization protocol hessian
services: Node weak type, Java strong type, how to call
This calling process is generally done through the RPC protocol, rather than through the HTTP protocol.
Since I have no contact with Java, and the information is only his PPT at that time, there is no detailed explanation, and there is no way to understand how it is implemented. And I am afraid that for most front-end development engineers, communication with Java is also a more serious challenge in the BFF landing process, and this is based on the front-end developers have better Node development capabilities.
(2) Multi-App adaptation
At the API gateway layer, handle the common logic of multiple apps, such as error code management, data consistency, login-free, and business logs.
(3) Aggregation
Pass the data needed to the client, simplify the client logic, reduce network overhead,
avoid meaningless transparent transmission
Sensitive information filtering
(4) Interface design guidelines
Basic service interface: (microservices?)
Fine-grained,
general - purpose functions may be used by multiple BFFs.
Provide mock real data with various states, easy to synchronize development (how to achieve?)
BFF API design
Reasonably design the number of interfaces, too many are not easy to maintain
Provide mock real data with various states, the page does not rely on server development (how to achieve?)
Multi-protocol publishing (how to achieve?)
Specification data format
in the process of landing BFF, from a technical perspective Look:
The front-end and BFF are completed by the same person. The
front-end needs to have server-side skills.
Fast application release capability (docker?)
TWA's concept and practice
In 2018 SEE Conf, Ant Financial's best (knowing ID: dead horse) is right. The TWA (Techless Web Application) development system developed on the basis of BFF is introduced (video and PPT).
Traditional layering:
BFF is responsible for aggregating the underlying business data, providing an interface to the client, adhering to the concept of who uses who maintains, generally maintained by the front-end team.
The business is actually divided into three layers: front-end (HTML / CSS / JS) + BFF (Node.js interface aggregation layer) + back-end service (Java)
BFF on Chari is self-developed by ants, based on the BFF framework of Egg.js, it has opened up the RPC communication link from Node to Java
Egg.js has been open source (Egg.js is based on Koa), need to build its own BFF framework based on Egg.js
RPC means that two applications that are not in the same memory space are implemented with the help of the network, calling remote functions like local functions
BFF is not a silver bullet and has its own problems:
R & D costs rise: the front-end team has to develop both the client and the BFF, and the staff is not enough. The
process is cumbersome: after the introduction of BFF, the front-end and server-side R & D processes must be taken at the same time
. The main
reason is that the front-end engineers have insufficient experience in operation and maintenance (which has caused great troubles to the business team). Although the division of responsibilities is becoming more and more clear, because the front-end and back-end release systems are inconsistent, the front-end team still needs to develop based on different code warehouses 'S release process
Ideal development process:
The solution TWA (Techless Web Application) launched by Ant Financial is a full-stack R & D framework
TWA is a progressive solution launched to improve the developer's R & D experience. Developers complete the R & D of the client and BFF layer based on the TWA framework under a code warehouse. The process support provided by the Basement R & D platform does not need to be concerned. Application, construction, deployment, process and other details, you can deploy the application to each operating terminal with one click, and complete independent operation and maintenance and monitoring of the application on the R & D platform
The disassembly of TWA is divided into three major directions: framework, R & D platform, and runtime
Framework: Provides a unified front-end and back-end framework, through a customized gateway to smooth out the differences between multiple terminals and access forms, so that a set of code can run under different terminals (?)
R & D platform: Basement, providing TWA R & D iteration, independent operation and maintenance, and monitoring simplify and standardize the H5 APP R & D process.
Runtime: Provide a stable and reliable operating environment for client code and server code through basic services and Docker
The framework
is a progressive framework, you can choose to use some of the capabilities
The client, server directory, and dependencies are all independent of each other.
Complex terminal environment, there are different access links (possibly through the gateway to take TCP long connection communication), different authentication schemes. If the BFF system of each service has to be connected to each system to complete access and authentication, it is very complicated.
The solution is: TWA gateway layer + client RPC Client,
The TWA gateway layer uniformly completes the access and authentication of all terminals. BFF does not need to be connected to each terminal, but only needs to be connected to the gateway to make the BFF interface unified
The client's RPC Clinet is a request library, which is connected to the gateway, hides the client's authentication and access details, and can automatically select the access link
This can call services under the directory in the server in the client directory, just like calling local methods
R & D platform
Basement, a one-stop operation and maintenance platform, based on Docker, supports the entire application R & D process, completes automated testing and deployment
The communication
between Node and Java is related to the microservice framework used. It can be HTTP or RPC.
Practice of Ant Financial
Data: Cross-language serialization protocol hessian
service: Node PRC
open source framework:
sofa-bolt-node: Antjs protocol Bolt ’s Nodejs implementation
sofa-rpc-node: a general-purpose Nodejs RPC module Great
practice – HTTP
can use the service registry:
First of all, when the Java application service starts, it will register the service with the service registration center. The service registration center here may be ETCD or Zookeeper. Then, when the Node application starts, it will first pull the service list from the service registration center, and then Node It will establish a long TCP link with the Java service. In addition, Node also needs to be responsible for Hession protocol analysis and load balancing.
The above method Node has heavy responsibilities and high requirements for Node development. Youzan has made improvements on this basis:
An intermediate proxy layer Tether is added between Node and Java. Tether is a local proxy written in Go language. Tether will expose an HTTP service. For Node, it only needs to call the local service through HTTP. However, other service-related service discovery, protocol analysis, load balancing, and long-chain establishment and maintenance are all handled by Tether. In this way, the Node layer is very lightweight. When Node calls Java services:
const Service = require('../base/BaseService');
class GoodsService extends Service {
/ **
* Get product details based on product alias
* @param {String} alias product alias
* /
async getGoodsDetailByAlias (alias) {
const result = this.invoke (
'com.youzan.ic.service.GoodsService' ,
'getGoodsDetailByAlias',
[alias]
);
return result;
}
}
module.exports = GoodsService;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
The advantages of this way:
It is simple to use and very friendly to front-end development. It only needs to call the local Tether service through HTTP;
multi-language access is low in cost. If there are other languages (Python, Ruby) in the later period, it also needs to access the entire service system, like Like Node, they only need to call the HTTP service exposed by the local Tether, and there is no additional development cost.
Later, it is more convenient to optimize the protocol layer, because this way Tether is actually an agent. If you need to optimize the performance of the protocol layer later, you only need to optimize the performance of Tether.
Summary
About TWA
TWA is self-developed by Ant Financial. It integrates a set of BFF progressive front-end + Node aggregation layer development system. It not only includes the introduction of BFF, but also includes front-end and back-end code management, deployment, operation and maintenance. And other functional frameworks.
But unfortunately, TWA is not open source. There is still a process of hard work for the introduction of BFF from 0 and the realization of TWA functions.
In fact, we introduced BFF, not to develop TWA completely, but to realize the function of Chari BFF first.
Benefits of accessing BFF
For the team:
More business support,
less communication and collaboration, and
faster problem solving.
For individuals:
More reasonable division of labor.
Doing BFF can expand the knowledge
. The disadvantage of accessing BFF: the
organization determines the complexity of the architecture. The
early learning cost is high, and it becomes a resource bottleneck in the short term.
Possible problems and possible solutions.
Node and Java communication – Hessian (data) , RPC (service) (sofa-rpc-node) / (grpc-node)
front-end code and BFF segment code management – Egg.js (same warehouse, different directories, different dependencies, separately packaged, separately configured)
front-end application release , Operation and maintenance capabilities-Docker
server-side cooperation-Services: microservices (?), Personnel: (?)
Front-end capabilities improved-front-end capabilities (JavaScript + HTML + CSS) + Node (server skills) + Java (how to communicate with Java ) + Operation and maintenance capability (Docker)
reference
Pattern: Backends For Frontends @ samnewman
Why do Internet companies start using node.js as middleware for web services? What's good? @ Know almost
Backend For Frontend @ Yu Qing Yang dark
BFF practice .pdf @ alipayobjects ant wealth of
micro-services architecture: BFF Gateway and how evolution out of the @ 10
Developer Experience First - TWA idea and practice @ know almost columns
Techless Web Application concept and practice —
Busi @ 优 酷02_SEEConf_TWA concept and practice_ 不 四 .pdf @ 语 雀
The practice of Node in praise @digging
Talk about Node.js RPC (1) — Protocol @ 语 雀
Talk about Node.js RPC (2) — Service discovery @ 语 雀
———————————— ————
Copyright Statement: This article is an original article of CSDN blogger "Dorasky", which follows the CC 4.0 BY-SA copyright agreement. Please attach the original source link and this statement to reprint.
Original link: https://blog.csdn.net/duola8789/article/details/89332064
