Thoughts on the evolution of large-scale website technology (17)--Website static processing-satisfying static front-end separation (9)

The topic of the separation of the front and back ends is finished, but the content of the separation of the front and back ends is not finished, this article will continue the problem of separation between the front and back end, but this separation of the front and back of the narrative will revolve around this series of theme site static. Before I talk about this topic, I need to correct some of the things that make friends misleading when it comes to separating the topic from the front and back ends, which is an evaluation of some of the Popular front-end separation schemes (no front-end separation schemes using Nodejs). In fact, I still feel that no matter what kind of front-end separation scheme as long as the successful implementation, and has produced good results, then it is a successful front-end separation scheme, before I in a critical perspective of these front-end separation scheme, do not want to deny them, But for a kind of nitpick attitude to re-examine these plans, I hope this review can make our design more excellent, but also in the process of the struggle to get their own technical ability to improve. In fact, those I criticized the technical solution may be in some specific scenarios it will become more excellent, I respected the technical solution in some scenarios may become pale and powerless, this situation is very likely to happen, do not say anything else, I criticized the front-end MVC, its selfishness is because it does not conform to the site static processing, If you put the front-end MVC content under the static theme of the site to talk about, the fate of the batch is inevitable.

Website static technology relative to the front and rear separation technology concern is much lower, if some companies in the industry because I read the article can have a new understanding of the site static technology, so as to consider the use of website static technology on their own website, but also want to achieve the front-end separation technology, then the new problems arise, Will there be any contradiction between the two technologies used at the same time? If there is a contradiction, how will we resolve these contradictions? To solve these contradictions, we can not do a good job of both, and do not happen that one side compromise on the other side, resulting in one of the parties did not fully exert their ability. To answer a series of questions above, the first thing I want to explore is the site static technology and the front-end separation of those aspects will create contradictions.

From my previous on the site static technology, we know that the site static technology best position should be the service side and not the browser side, the reason is because the technical basis of static Web site is dynamic separation and cache, these two aspects if the browser side will encounter a lot of difficult to solve the problem, Then we have to analyze these difficult problems, as follows:

Browser cache problem: The browser also has a cache, but the browser side of the cache that is not the memory cache, but the persistent cache, in fact, the browser side of the cache is very unreliable, will be a lot of non-technical factors, such as we manually delete the cache or use the seamless mode of the Internet, Then these persistent caches will expire, the user will visit the site again is the first time to visit the site, which makes a lot of good cache strategy in the browser-side implementation of the effect is greatly compromised.

Browser static and dynamic separation of the problem: the Web site is an important means of technology is how to design dynamic separation strategy, pure static content This is nothing to say, but the dynamic content in a certain condition (for example: time, some business properties such as merchant properties) can be converted to static content, If these content can be effectively cached, the performance of the site is immeasurable, and this strategy can reduce the Business Server processing unnecessary requests, thereby reducing the pressure on the business Server, to improve the backend core business service side load pressure. But if we use the front-end MVC framework, a brain to move a lot of server-side functions to the front-end, then this method of static and dynamic processing is difficult to do, and many scenarios are basically not applied.

So I think that the front-end separation scheme uses Nodejs value is higher, because using Nodejs we can according to the site of static technology will need to remain on the service side of the function can continue to remain on the service side, so that can achieve both purposes. But if we think the introduction of Nodejs, the purpose of Nodejs is to do the site of the whole MVC structure of the C layer is the control layer, this idea is reasonable unreasonable? This question is still worth pondering, so we need to analyze the role of the C layer, the control layer, under the overall MVC architecture of the website.

in the previous article I have summed up the role of the C layer, the control layer in the MVC framework, which is: routing, message format conversion and page rendering, but I have a precondition for this function, That is, the C-layer is the control layer as the front and rear communication medium under the premise. If the front-end separation scheme is introduced into the front-end components of the control layer, then the control layer of the former side of the joint problem is the people's internal contradictions, are relatively good solution, but the control layer is only used to connect the front and back a role? For the control layer in the site architecture, there is an unavoidable function that is as the back end of the service side of the role of the security portal, that is, the control layer is to do the request security check and safety monitoring of the place, and many security checks will be related to the business, such as checking whether the message has been tampered with, anti-phishing function, If these features are the front-end to bear, first of all do not talk about the front-end technician will do these, but at least a little problem is going to happen, front-end engineers in the care page began to write the service side of the business logic, anyway, these features migrated to the front end is not too appropriate. When the site evolved into a very large site, large sites are often a lot of small and medium-sized web site projects, in order to reduce the overall heterogeneity of the site, we often put the different modules of the portal integration under a large control layer project, this large control layer project is generally called Gateway project, its role and network gateway very similar. In addition, some of the site's control layer is very special, such as some third-party payment of the site, so that the website project itself is a large gateway, and this gateway is very special, its backstage service is the system of other banks, its routing work will become extremely complex, for example: According to the user's use of the Bank, Control layer to assemble different message information, and these functions are belong to the control layer, such a scene undoubtedly greatly enhance the control layer and model layer docking technical difficulty, and the increase in difficulty and model layer coupling degree is very high, thus, the Web application of the whole MVC control layer than we think more complex.

Back to the theme of using Nodejs instead of control layer, let's take a look at the actual scene, if our site control layer relatively simple, good, this time we talk to the leader or the boss said "now very popular back and forth separation, our project also use the next front and rear end separation technology", the leader or boss a listen may spirits, Then you will be asked "what to do then", you said to him, "first the control layer with Nodejs rewrite", the leader or the boss heard the answer he would agree with you to do so? One will not add any new features to the site, while not very directly and effectively improve the performance of the site, and the implementation of it will be a great risk of the plan, the chief will agree? Well, if you finally find a reasonable reason to persuade the bosses, then if our site is already large, the control layer has become a gateway project, the control layer itself is very complex, you dare to rewrite the Gateway project with Nodejs? So say Nodejs directly as a control layer, in fact, practical difficulties, and Nodejs completely bear the control layer, its performance, it can be well used in cluster development it is difficult to control the problem. Analysis here, we seem to enter a dead end, then how to break this bureau?

The above problem only reflects the entire site MVC control layer In fact there are some functions and the service side of the model layer tightly coupled, so to solve this problem is the traditional control layer subdivision, belonging to the front end of the section to the Web front end as the Web front-end as the control layer, belonging to the service side of the portion left to the server , after such a split, when we introduced a Nodejs-based front-end separation scheme, the service side of the control layer is simply to remove the page routing, page rendering, and then modify the return data format can be, because do not modify the service side of the business code, the cost is very low, the chief is also very easy to accept such a scheme, and to support us in daring to try new technologies.

Server-side Web site static technology SSI and ESI, mainly based on the static and static separation strategy to the Web page will not be constantly changing the template cache, and then in the location of stationary resource server integration of dynamic resources, if we use Nodejs simply replace the original control layer, then these strategies are still problematic, So what can be done to make NODEJS compatible with SSI and ESI? Here I cite a practical case, Nodejs has a template language called Jade,nodejs and there is a technology called HANDLEBARSJS, where Handlebarsjs and struts are similar tags, it can handle some simple business logic, We developed a template for writing pages using Jade, using HANDLEBARSJS to integrate Dynamic Data and templates, and when projects were published, project management tools such as grunt were used to compile the project, and the jade file became an HTML file. The Handlebarsjs translates into JavaScript code so that we can efficiently cache the generated HTML file on the server, and the JavaScript file generated by handlebars is responsible for consolidating the dynamic data. This allows the Nodejs to be compatible with SSI and ESI.

However, the introduction of Nodejs will allow the site to process the request to add a link, which may lead to partial performance loss, but my above example can have another way to circumvent this problem, because the Nodejs code is written in JavaScript language, Then this code can be run on the browser, then this will produce a processing method, that is, we do not need to deploy NODEJS in the production deployment, we put the static template on the service side or push to the CDN, Then HANDLEBARSJS generated by the JS code to send it to the browser side, because the JS code generated basically does not change, the browser can cache it, of course, the CDN or the static resource server can also cache it, in fact, it is in the browser runtime changes is nothing but to get a service-side data. In this way, the production of the Web front-end has turned into a front-end MVC form, but also the integration of static and dynamic things to the browser to complete, this is not only a balance of the site static requirements, but also let the dynamic integration pushed to the front of the browser side, this is not achieved a double-win effect.

All right, this is what I'm going to write about, and finally, good night, happy life.

Thoughts on the evolution of large-scale website technology (17)--Website static processing-satisfying static front-end separation (9)