In fact, I wanted to write this article a month ago, but I did not make any achievements in this year. All of them are routine things. Some of them cannot be shared publicly, so I finally selected the following contents to share
It’s also a testament to the year 2019.
Real-time rendering
In the last two years, the server rendering has been studied very much as we all know, SSR in fact, the server performance is relatively poor, logic complex a little page or DOM a little more pages QPS basically stay in dozens. SSR is CPU intensive because it uses the virtual DOM on the server side and requires a lot of traversal computation so all of a sudden the CPU goes up. Our solution was to add caches, component caches, page caches, interface caches, basically everything we could cache. But there are a lot of problems with caching. Because the timeliness of cached data is relatively poor, it will lead to slow page update. It may take an hour or two for a user profile change to take effect, and some pages with thousands of pages cannot be cached at all. In fact, each big factory also gave their own different solutions.
Although the details are different, there are no more than two ways of thinking.
1. The performance of string template rendering is far better than that of virtual DOM, so the idea is to transform the original virtual DOM rendering into string rendering through a series of transformations on the server side, so that the performance can be improved multiple times. The first one that is better is the extreme SSR shared by Duan Longxian on 2019Tweb
The second one is Alibaba’s Beidou, which is implemented based on React. I saw it shared on D2 in 2017. It should have been improved by now.
Github.com/alibaba/bei…His idea is to render a template with no data but placeholders using the React code and then render the data by rendering the string again, both of which somehow change the VNODE rendering to a string template rendering
2. The second idea is to render a Vue template with partial data through the server and mount the remaining data in the front end, such as iQiyi
I took a screenshot of a short section of his page. He rendered a template on the server side, which was an HTML tag itself, so things could be resolved during the first screen rendering. Then, when js was executed, data was bound to it through a series of operations of Vue to render corresponding nodes according to the data. (The above schemes are based on the PPT shared by them or my own research. There may be some differences with their schemes.)
We use the second similar scheme of the first scheme. On the server side, vue SSR just renders a string template with the placeholder ${item.name} and then uses the ES6 string template to render the real-time data. Of course, there are also a variety of if judgment data judgment and other details need to be carefully considered.
GRPC-WEB
GRPC, which I won’t go into much more detail, uses Proto files to define client and server data types and service interfaces. But GRPC’s end-to-end application architecture is missing a piece of the Web end-to-end server. GRPC – web (github.com/grpc/grpc-w…). Is the key to closing the last gap
Let me briefly explain how to use it.
The first step is definitely to provide a PB file at the back end.
The second step is to compile the PB file into JS GRPC-Web version through the Protoc tool
The third step is to initiate a request
As shown in the figure:
In fact, about solving the problem of front and back end interface conventions, you can also pay attention to the sharing of Tianzhu
And since it’s binary streaming, according to my data collection, the latency is reduced by about 40% and the bandwidth consumed by 25%, which seems like a good result.
However, after the proofing of my project, I found that grPC-Web has some difficulties to be solved.
1. Protoc compiled JS files will be large, about tens to hundreds of K plus the size of the PROTObuf NPM package, about 250K. This is not appropriate for pages that focus on the user’s first-screen response time, because the files that depend on it are too large. A bit of a pyrrhic gain. But it is very suitable for some asynchronous interfaces after page rendering.
2. Require an envoy Proxy service between the front-end JS interface and the back-end GRPC interface
3. Because the pB-compiled files introduced are too large and the response data is binary stream, the time for the code to run is increased when the data is first fetched.
But overall, GRPC-Web is really the future.
2020 plan
Finally, a simple plan for 2020.
The first is a simple architectural idea.
Want to set up a Node gateway so that all page renderers can be microservices. One microservice per page.
When the pressure on a page increases, the renderer service needs to be dynamically expanded.
At the same time, when some common logic needs to be handled, such as permission validation, it only needs to be added at the gateway layer.
This, of course, assumes that the gateway layer is sufficiently stable and has a reliable degradation scheme.
In the next few years, serverless is a major trend of development, and this architecture can also be well connected with the following serverless.
Then, vuE3 2020 should be released, it may be based on vuE3 update, to see if the existing front-end tools and development model need to be adjusted.
For my own words, 2019 is actually more distressed, because some of the projects, the development of the rules. I need a little breakthrough. I hope to be more systematic in both my own technology and the projects within the group. In 2020, I hope to break through my project bottleneck and technical bottleneck and make better things.
And finally… I really want to travel… Wherever it is, just get out
Denver annual essay | 2019 technical way with me The campaign is under way…
