Landing practice of front-end SSR

The full text is 3268 words, and the expected reading time is 8 minutes

Directory:

I. Explanation of nouns

Ii. Business Background: New service market business line

Dilemma: server-side rendering is dominated by the back end, and the front end is only responsible for the output of static (browser-side execution) JS files

Start over: the front end can also do server-side rendering, js can also generate HTML on the server side

1: Introduce Node.js as the service rendering layer
2: Determine the SSR technical scheme node-VUE-SSR

Fifth, new challenges: node. js and SSR join, isomorphic logic miscellaneous

Vi. Reasonable stratification: disassemble the complexity of different ends, and develop multiple ends at one time to improve development efficiency

Configurable development: How does each layer of development unit work to the next layer

1: Node layer: data fetching and SSR rendering
2. Front-end engineering: bridge between client and server
3: Data configuration layer, consistent data maintenance
4: State processing layer: filter the obtained data
5: Page layer: render

Viii. Others:

Ix. Conclusion:

advantage
disadvantages
Comparison: the comparison between the static output of RD machine and the indicators constructed by SSR on Node machine after transformation
1: indicates the total loading duration
2: Comparison of other indicators
Future and Outlook

I. Explanation of nouns:

Ii. Business Background: New service market business line

With the development of Baidu Aiprocurement, we are committed to building our own business ecology, with aiprocurement as the core, based on search traffic, to create a service market platform. Service market is committed to serving the whole network B end business. Search traffic is our cornerstone, and we need server-side rendering to improve our search rankings, but server-side rendering can also improve part of the user experience.

Dilemma: server-side rendering is dominated by the back end, and the front end is only responsible for the output of static (browser-side execution) JS files

We are the front-end team of Aipurchasing. The overall technical design of Aipurchasing is to use PHP service at the back end and Smarty rendering engine at the C end. The front-end is engineered to produce Smarty engine source files. As a result, the front end is not completely separated from the front end, the front end relies too much on the rendering of the back end, and the overall optimization and efficiency improvement are too limited. The new system is expected to inherit the advantages of the old system, throw away its baggage, and start over where it falls short.

The flow chart is as follows:

Start over: the front end can also do server-side rendering, js can also generate HTML on the server side

After investigation and analysis, Node.js can also support server-side rendering, and its performance is not inferior to that of Smarty rendering engine of PHP. Under the premise of efficiency improvement and cross-platform collaboration in the whole department, node.js is selected as the rendering engine of the technology of the whole service market, in order to enhance the front-end ability to achieve cross-platform and cross-platform improvement.

The flow chart is as follows:

1: Introduce Node.js as the service rendering layer

In itself, rendering is front-end workload. The introduction of Node.js layer to do rendering is mainly to reduce back-end concerns, make the back-end only as a data layer, so that the back-end is more focused. The front-end can intervene in the server, connect the server and the client, and enhance engineering capabilities.

2: Determine the SSR technical scheme node-VUE-SSR

Thanks to technological advances, the existing Node.js server rendering has many technology options: NUxT, Node-VUe-SSR

Based on the node-VUE-SSR that the team has practiced and the existing VUE technology stack, node-VUe-SSR was finally selected.

For details about the implementation process of Node-VUE-SSR, see ssr.vuejs.org/zh/

Fifth, new challenges: node. js and SSR join, isomorphic logic miscellaneous

1. State judgment of SSR and CSR needs to be added into the status

2. Nuxt.js(a framework of VUE – SSR) keeps nodeJS and client data consistent through asyncData (a configuration function that both server and client run before each page rendering), which has great disadvantages

Low efficiency: For every page developed, it is necessary to write request logic (serial data and parallel data), network exception processing logic (network request failure, back-end exception status code, data not logged in to request login)

Poor scalability: It is difficult to implement cross-platform active pages for subsequent extensions (low efficiency, code coupling in a function, it is difficult to upgrade Lowcode)

In order to solve these problems, the problem was disassembled, and the data acquisition processing, layered (client and server code separation) multi-step execution, in order to achieve high scalability, efficient development, simple maintenance, fast locking problems and other advantages

Vi. Reasonable stratification: disassemble the complexity of different ends, and develop multiple ends at one time to improve development efficiency

Configurable development: How does each layer of development unit work to the next layer

1: Node layer: data fetching and SSR rendering

The Node layer obtains the routes accessed by users, preobtains the data of the data configuration layer according to the routing information, and obtains public data (user information) to the status processing layer.

2. Front-end engineering: bridge between client and server

Solve a set of code development through engineering, multi – terminal operation. The code can run on the server to generate HTML nodes, and the code can run JS in the browser to generate HTML interactively.

3: Data configuration layer, consistent data maintenance

According to the configuration information of the data configuration layer, the same data is obtained from node.js side and client side. This ensures that when accessing the same route, the data is the same and the build rendering results are the same whether the client build or the server build.

Configuration information:

Export default {// title": "service market ", "name": "home", // Route matching "path": "/", // Whether to build" SSR ": true, // request parameters "ajax": [/ / parallel interface {" path ":"/home/info ", "children" : / / serial interface [{" path ":"/home/getProductConf ", "params" : {/ / dependent on the parameters of the parent interface "name" : "the parent. Data [0]. Data. The name '}}}], / / parallel interface {" path" : "/ home/getProductConf"}]}Copy the code

From the configuration of the engineering layer, we strengthen the configuration file, so that all pages of the project support three flexible configurations:

1. SSR construction is adopted for those with high requirements for client experience and SEO requirements

2. The data prefetch mode is used when the user experience requirements are relatively common

3, for static pages using client-side JS display

4: State processing layer: filter the obtained data

The page of a project has many states. For example, the user center needs to log in. If not, the login interface should be displayed. If data acquisition fails, the failure page is displayed.

In this state, there was a lot of redundant code in previous projects.

The state processing layer processes data according to the configuration of the page. The state processing layer delivers only successful data to the page layer. If the login fails or data fails to be obtained, the corresponding status is displayed.

5: Page layer: render

Thanks to proper layering and logical disassembly, the entire page layer is used only for interaction and page data rendering.

Viii. Others:

Flexible configuration: support server rendering, data direct rendering, and client CSR rendering.

Disaster recovery solution: In the case of bugs in server rendering, it can flexibly switch to client rendering.

Log collection: Collects each request, records the current CPU and memory performance parameters, and alarms in time when problems occur

Problem locking: For each request per render, generate a unique LoGID from back end to front end for quick problem locking on problematic requests

Ix. Conclusion:

Advantage:

SSR rendering at the front end gives our project vitality, more flexible configuration, better user experience, more powerful functions, better iteration, higher security and fault tolerance rate.

Disadvantages:

The introduction of the Node.js layer increases costs

Comparison: the comparison between the static output of RD machine and the indicators constructed by SSR on Node machine after transformation

(1) Total loading time

Figure 1: Total loading time of progressive CSR is 1.7s

Figure 2: The total SSR loading time of 1.2s increased by 30%

(2) Comparison of other indicators

Figure 1: Progressive CSR rendering after the first rendering 243ms, the first content rendering is 943ms, and the final rendering is 1243ms

Figure 2: SSR rendering first volume rendering and content rendering 427ms, the end of rendering 1027ms

First Paint (FP) is drawn for the First time

FCP (First Contentful Paint) First content painting

Largest Contentful Paint (LCP) Maximum content rendering

DCL (DomContentloaded): Resolved

Future and Outlook:

Through the performance comparison, the overall benefits are far beyond the present. In the future, we expect to expand the buying and selling ecology with love and procurement as the core, continue to implement configuration, describe each page with data, and drive each page with Node.js based rendering service to realize front-end micro-service and cross-platform active page customization.

I. Explanation of nouns:

Ii. Business Background: New service market business line

Dilemma: server-side rendering is dominated by the back end, and the front end is only responsible for the output of static (browser-side execution) JS files

Start over: the front end can also do server-side rendering, js can also generate HTML on the server side

1: Introduce Node.js as the service rendering layer

2: Determine the SSR technical scheme node-VUE-SSR

Fifth, new challenges: node. js and SSR join, isomorphic logic miscellaneous

Vi. Reasonable stratification: disassemble the complexity of different ends, and develop multiple ends at one time to improve development efficiency

Configurable development: How does each layer of development unit work to the next layer

1: Node layer: data fetching and SSR rendering

2. Front-end engineering: bridge between client and server

3: Data configuration layer, consistent data maintenance

4: State processing layer: filter the obtained data

5: Page layer: render

Viii. Others:

Ix. Conclusion:

Advantage:

Disadvantages:

Comparison: the comparison between the static output of RD machine and the indicators constructed by SSR on Node machine after transformation

(1) Total loading time

(2) Comparison of other indicators

Future and Outlook:

Related Posts

XML parsing

React Hook Libraries

I learned a lot from last night’s live telecast!!