Shulou(Shulou.com)06/01 Report--

This article mainly introduces "what is the necessity of web front-end separation". In daily operation, I believe that many people have doubts about the necessity of web front-end separation. Xiaobian consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful for you to answer the doubt of "what is the necessity of web front-end separation?" Next, please follow the editor to study!

Unseparated period

MVC, the blogger will not explain much. The structure diagram in the early JSP+SERVLET is as follows.

Roughly all requests are sent to the Servlet as the controller, which accepts the requests and distributes them to the appropriate JSP based on the request information to respond. At the same time, Servlet also generates an instance of JavaBeans according to the requirements of JSP and outputs it to the JSP environment. JSP can get the data in the JAVABeans by calling the method directly or using UseBean's custom tag. To be clear, this View can also use template engines such as Velocity, Freemaker, and so on. The use of these template engines can make the division of labor in the development process more clear, but also improve development efficiency. So, during this period, there are two ways of development:

Method 2:

Just to be clear, mode two has been phased out. There are two main reasons:

(1) the front end relies heavily on the back end in the development process. If the back end is not completed, the front end cannot work at all.

(2) due to the trend problem, there are fewer and fewer front-ends who can JSP and understand velocity,freemarker.

As a result, mode 2 is gradually not adopted. However, I have to say that way one, in fact, many small traditional software companies are still using it. So, what are the common shortcomings of mode one and mode two?

The front end cannot be debugged separately.

After the project was launched, there were some problems. For example, if there is something wrong with the style, because the front end does not have a project development environment, then the following dialogue may occur

Front end: "I have no problem here. Back end, is it normal there?" Back end: "I'm not normal here. Why don't you come and have a look?" Front end: "I can't see the problem for a while, and I don't have an environment. What should I do?" Back end: "you don't have the environment, sit on my side." Then, the front end is upset with the code on your face. Some of the back-end with low EQ just press the cell phone next to it, really.

Summary, because the front end cannot be debugged separately. On the one hand, the development efficiency is reduced. On the other hand, it may also lead to conflicts among people within the company.

II and front end will inevitably encounter background code.

For example, the front end may encounter code with the following structure

As the front end, see the background code in the page, the heart must be very unhappy, this way of coupling is too strong. So, even if you use template engines such as freemarker, you can't write JAVA code. The front end will inevitably have to relearn the template syntax of the template engine, which needlessly increases the learning cost of the front end. Just as our back-end developers don't want to write the front end, how do you feel if you embed the front end code in your background code? Therefore, this approach is very inappropriate.

Some other problems caused by III and JSP itself

For example, JSP is slow to run for the first time because it contains a step that translates to Servlet. For example, because of synchronous loading, when there is a lot of content in jsp, the page response will be very slow.

Semi-separation period

The front end is responsible for developing the page, and the front end is responsible for developing the page, obtaining data through the interface (Ajax), binding the page with dom operation, and finally rendering the page by the front end. This is how Ajax is combined with SPA apps (single-page apps) as mentioned in other blogs. Its structure is as follows

The steps are as follows:

(1) browser request. Cdn returns the html page.

(2) the js code in html requests the restful interface in the background by ajax.

(3) the API returns json data, and the page parses json data, and renders the page through dom operation.

Ps: bloggers used jquery's ajax request in the early days, and then did so.

Why is it semi-separated?

Because not all pages are single-page applications, in the case of multi-page applications, because the frontend does not master the controller layer, the frontend needs to discuss with the backend. Do we want synchronous output or asynchronous json rendering? Therefore, at this stage, it can only be regarded as semi-separation.

What are the advantages and disadvantages of this approach?

First of all, the advantages of this approach are obvious. The front end does not embed any background code. The front end focuses on the development of html, css, and js, and does not depend on the back end. You can also simulate json data to render the page. Found that bug, can also quickly identify whose problem, there will not be mutual evasion phenomenon.

However, under this framework, there are obvious drawbacks. The most obvious points are as follows:

(1) there is a lot of redundancy in js. In the case of complex business, the code of the rendering part of the page is very complex.

(2) when the data returned by json is relatively large, the rendering is very slow, and the page stutters will occur.

(3) seo is very inconvenient. Because the crawler of the search engine cannot climb down the data rendered asynchronously by js, there will be some problems in SEO for such pages.

(4) the resource consumption is serious. In the case of complex business, a page may have to initiate multiple http requests to render the page. Some people may not be convinced and think that it is okay to set up multiple http requests on the pc side. Have you ever considered the mobile terminal, and do you know how much resources it takes for the mobile terminal to set up a http request?

It is precisely because of the above shortcomings that the real front-end separation architecture was born.

Separation period

During this period, the scope of the front end was expanded. It is considered that the controller layer is also part of the front end. During this period

Front end: responsible for the View and Controller layers.

Backend: only responsible for Model layer, business processing / data, etc.

But the front end does not understand the background code? how to implement the controller layer?

This is the wonderful use of node.js. Node.js is suitable for scenarios with high concurrency, dense I _ Pot O and a small amount of business logic. The most important point is that the front end does not have to learn another language, and the front end is much more hands-on.

Therefore, the architecture of this period is as follows

What are the specific benefits of adding node.js as a middle tier?

(1) improvement of adaptability

In fact, in the process of development, we often develop a front end for PC, mobile and app. In fact, for these three ends, most of the business logic is the same. The only difference is that the interactive presentation logic is different. If the controller layer is in the hands of the backend, the backend maintains the controller on its own in order to display the logic on these different end pages, which only increases the cost of communicating with the front end.

If the node.js layer is added, the architecture diagram is as follows

Under this structure, the interface display logic of each front end is maintained by the node layer itself. If the product manager wants to change the interface or something, the front end can maintain it full-time, and the back end doesn't have to worry about it. The front and rear end each performs its own duties, the back end focuses on its own business logic development, and the front end focuses on product effect development.

(2) improve the response speed.

Sometimes, we encounter that the data returned by the back end to the front end is too simple, and the front end needs to perform logical operations on the data. Then when the amount of data is relatively small, it does not affect the operation of grouping and other operations. But when the amount of data is large, there will be obvious stutter effect. At this time, the node middle layer can actually put a lot of this code into the node layer to process, can also share some simple logic for the back end, and can use the template engine to control the foreground output. In this way, the flexibility and responsiveness are greatly improved.

(3) performance has been improved

Everyone should know the principle of single responsibility. From this point of view, when we request a page, we may have to respond to a lot of back-end APIs. When there are more requests, the natural speed slows down, and this phenomenon is even more serious on the mobile side. Using node as the middle layer, multiple back-end data needed by the page will be assembled directly in the intranet phase, and then uniformly returned to the front end, you will get better performance.

The shortcomings of separation

Before analyzing the shortcomings, the blogger blames himself. Bloggers take the salaries of low-level programmers and think about what architects and even departmental leader should consider. The blogger is guilty! ok, get to the point.

Come to a conclusion first, small and medium-sized software companies, be careful to use the front and rear separation architecture! Use it carefully!

(1) personnel issues

Pay attention to the level of companies that promote this structure. Small and medium-sized companies generally do not have such front-end resources to support such a structure. If you push such a separate architecture will lead to a consequence, the back-end is forced to learn vue.js,node.js these things, adding to the burden on the back-end in vain. If it is not handled properly in the end, there will be a scene in which the back end will leave one after another.

(2) the problem of product iterative cycle

Small and medium-sized software companies generally need a faster software iteration cycle. The separation architecture is adopted, and an interface formulation process and a front-end joint debugging process are added. In essence, it slows down the iteration cycle.

(3) the front end needs to learn business.

Originally, the front end only needs to be in charge of the visual interaction. Now because the controller layer is also managed by the front end, the front end must have an in-depth understanding of the company's business process in order to accurately write the display logic. But this will make the back end feel that the front end is seizing power and the front end is mixing KPI. The front end also has to learn boring business, but as the saying goes, there are gains and losses, so the front end can gain a foothold. Perhaps it is because of the emergence of the front-end separation architecture that the front end can move towards the architect.

At this point, the study on "what is the necessity of front and rear separation of web" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.