A reflection on the separation of front and back ends architecture triggered by React

Our app has nearly 100W users, 3K+ QPS, 500 million + single table data and trillions of capital flow, but it also faces many problems.

The first is the low level of appearance, the limited peels, and the inability to integrate better front-end frameworks and components. Then, the high coupling between the front and back ends prevents rapid response to business changes, and maintenance costs keep rising with the scale of applications. Performance is also limited, and communication costs increase. The second is the inability to cross terminals, rendering and jumping are strongly dependent on the back end, and the business logic is scattered. Finally, there is the strong state, a lot of data in the application is tied to the user’s session, resulting in no horizontal scalability, intelligence, automation, service is also limited.

After thinking, we think that the ideal state should be like this. The front end has the characteristics of high appearance level, personalized, multi-channel and multi-terminal. And the back-end needs to be able to achieve microservitization, horizontal scaling, high availability, automation and even intelligent.

In previous applications, the backend was Java and the front end was Browser. But now that Node is here, it’s included in the big front end to replace the MVC part, so that the back end can be detached from the purely servified part, and the front end can focus on the purely front-end domain.

The front-end Browser is responsible for data display and collection, event response and processing, DOM operation, request sending and response processing. Node handles functions such as page rendering, jumping, and data transfer that were previously implemented through the back end. The back-end aspect focuses on the encapsulation of business logic, provision of service interfaces, and serialization.

In general, the front end and back end interact in a servitization manner, passing data through Json. The front end is componentized and the back end is modular.

After trying many solutions, we chose React+Redux, because React has accumulated certain technology, and there are many successful cases in China. However, because Redux was too flexible, we chose to give it up after three weeks of exposure and instead used AntD, an open source presentation framework based on React, and Dva framework based on Redux encapsulation.

When a request comes in, the interface is presented via Component or Route. It also receives click events from the user. For each click event, dispath triggers an Action, which then produces two results.

One is to directly change the state state through the reducers function to change the model associated with the foreground, so as to change the foreground page. The other is to call the background service and access the back-end service through FETCH. The data returned by the background service will be processed by the Effects function and then handed to the Reducers function to change the state state, thus triggering the front-end component refresh and rendering.

Finally, there is a subscriptions function that intercepts a URL request and triggers an Action, which then leads to the above two changes.

The logic behind the scenes is more complex, and we use a layered technical architecture. At the bottom level is the infrastructure that supports public clouds, private clouds and, of course, local servers. Then the technology platform layer is the generic architecture, including some system permissions, workflows, development frameworks and so on. Based on the general service layer, there are some report services, printing services, document services and so on. Then up is the service module, including account management, task management, self-service center, etc. Finally, the top layer is the interface Services layer, which is based on Web services and Restful Services.

In addition to the main framework above, we also have the service gateway module, which is mainly used for flow control, security monitoring, load balancing, service degradation and fuse, etc. The other is the security operation and maintenance module, which is used to deal with identity authentication, access control, encryption and decryption, audit logs, operation and maintenance tools and so on.

At present, Fetch is used for most business form data and background interaction. In addition, due to some legacy system problems, the AJAX method is still retained, and it has been improved. File operations such as upload and download currently use Form submission.

We originally used Jsonp to solve this problem, but the problem with Jsonp is that it only supports GET requests and the parameters are exposed. For the sake of security, we choose the current mainstream CORS method, which only deals with cross-domain on the server side without involving the client side.

The strong state of the application is due to over-reliance on sessions. The principle of a Session is that some data is stored in the Session, and the Session is used as a cache; Another important responsibility is to maintain contact with the client so that the back end can determine which client sent the request. Now we use Token to identify clients, and the responsibility of cache is replaced by distributed cache.

The front-end Router replaces the forward or redirect redirect and transmits parameters on the backend. Data is transmitted through PayLoad. If a jump depends on a state at the back end, you only need to get a message from the back end, and the front end will determine the direction of the jump based on this message.

Our experience is that the backend unified exception error capture, then classification, through the exception error message dictionary to uniformly feedback the error message to the front desk. After the foreground receives an error message from the background, it prompts the front-end interface and jumps to the error page.

Token is used for identity authentication. In addition, to prevent the Token from being valid all the time, the Token is deregistered when the console actively logs out. In addition, the background automatically deregisters inactive callback calls according to the configured callback expiration time. Message encryption and decryption, system access control, including system function rights and data rights will also have special services.

The original unified test was separated, with the front and back end conducting unit tests with independent mock data, followed by joint test, which was followed by smoke test based on test cases. After the completion of the smoke test, the developer’s test is finished, and the subsequent integration test and UAT test will be handed over to professional testers.

Agile, fast response, improve efficiency, professional division of labor and collaboration, improve professionalism and RESEARCH and development efficiency, clear structure, reduce maintenance costs, the front and back end of independent expansion, free horizontal expansion.

Now we need to consider what further enhancements are needed, such as service gateways, security and operation features enhancements, further refinement and encapsulation of common components, performance and experience improvements, open source frameworks, etc.

That’s all for today’s sharing, thank you!