It has been a long time since we wrote an article. This time, WE would like to share some optimization of the front-end architecture since we used Node. If you have read my last article about the front-end road of STATION B, you may know that we have gone through one year of iteration since we closed the use of Node last year. The number of visitors has also expanded from one million level to the current one hundred million level, this time add some dry goods ~
How does VUE implement hot update
We all know that for Node, front-end vue code iteration is very fast, maybe several times a week, but node iteration is not so common, maybe once a week or more, so it is very useful to reduce the number of Node service releases for the stability of node service. The configuration center is definitely needed, because the Node service needs to be notified to update the version number on the service by configuring different resource versions. So how do we modify the vue code to achieve hot updates? First, he defines a createRenderer method which calls the createBundleRender method of VUE-SSR to create a rendering function
The Vue project is separated from the Node project
In order to separate the front and back ends, we built a Node layer between the front end and the API layer, which is used to do server-side rendering to speed up the user’s first screen availability and be friendly to search engines. The project is initially placed in the same Git repository, in the client and server directories (or as in the official Vue example, the Node service may have only one sever. Because some of the resources in the client may be needed in the server, they have to be put together. Later, after configuring the central driver, client and server can be completely independent and connected through the configuration center. So it is perfectly possible to separate the client project from the server project.
(koa-webpack)
disaster
Since it is a Node service, we also need to have a corresponding disaster recovery solution for the service, otherwise how can we safely give it a large amount of traffic, so we need a degradation solution in case of need (the following content needs to be established on the basis of your understanding of Vuessr). First, vue server rendering has two entry files, If entryClient. js and entryServer. js are to support demotion, they need to do something about entryClient. js. Now add a client render container to index.temlate.html, a div called de-app (<! –vue-ssr-outlet–> is a placeholder for server rendering.
- Degrade the server render if the CPU usage of all Node processes exceeds the specified threshold. Degrade the server render if the CPU usage of all Node processes exceeds the specified threshold. Can greatly reduce the server side of the rendering pressure, of course, you can also manually set whether to downgrade, come and go
- Degrade.html. If a Node explodes, a configuration on the SLB layer, called nginx, is required to direct traffic to our implementation if the service returns code 5xx
- 3. If the page is configured with CDN cache and the CDN source fails, it will return to the previous cached page, then in extreme cases, there will still be a first screen page to show the user (data pockets will make this scheme more perfect, next opportunity to fill it) this time so much. Next time we’ll probably add some other optimizations and react tricks