Web Development Trilogy

The Bronze Age

In the early days of the Internet, the web was just a vehicle for carrying static information, displaying only static text and pictures. This static page can’t read the data in the background database, so it’s a completely closed ecosystem. Let’s call this the “Bronze Age” of Web development.

The silver age

In an effort to make the Web more dynamic, developers have repeatedly attacked the high ground of the dynamic Web, with the main goal of allowing Web developers to write dynamic pages quickly. At this stage, the dynamic page technology represented by PHP, JSP and ASP.NET was born one after another. In front of these dynamic page technologies, the Web is no longer static, according to different people, different regions, different time period to present different data results, from then on, the Development of the Web entered its “silver age”.

Golden age??

Then websites mushroomed, complexity exploded, and it became more and more difficult for programmers to both draw pages and control business logic, so the concept of separating the front and back ends came up. The core concept is to “let professional people do professional things” **. The career of programmers then came to a bifurcation point, and the choice between programmers who specialize in drawing pages and those who specialize in controlling business logic has been a point of debate to this day.At this stage, the front end does not need to participate in the background data processing, he just needs to use the agreed interface to get the appropriate data, and then render the page. One benefit of this is that the development schedule is not blocked, and back-end development does not need to wait for the front-end to complete before continuing, as long as it mocks the complete data.

Challenges of front and rear end separation

Is this the “golden age” of the Web?

I don’t think so.

The separation of the front and back ends is a very good idea, but the beautiful vision of professional people doing professional things has been challenged in the actual process. For example, the front-end interface usually presents data logically, and sometimes the back-end encapsulates data according to the data structure required by the front-end to improve efficiency. This means that the back end is still doing the view layer’s work, contrary to the original intention of separating the front and back ends.

The middle tier of the Web system architecture

In order to solve this problem, it was suggested that the Controller and View should be moved to the front end, and the back end should handle only the data and underlying logic of the Model. So Node middle layer this solution was put forward, this solution is good we do not table, first to say what is the function of this middle layer and what the architecture is.

Middle tier architecture

What the middle layer has to do is very simple.

Originally, the client sends a request directly to the Server. After receiving the request, the Server layer computs and returns the result to the browser. The browser now sends the request to the Node layer, which goes through a round of processing and then sends the request to the Server layer. The Server layer returns the response to the Node layer, and the Node layer returns the data to the browser. Because of the Node layer, the Server layer can only focus on the business itself, without having to pay attention to the special requirements of the front end for fields.

Moreover, due to the addition of the NodeJS layer, the interface presentation logic of each front-end is maintained by the NodeJS layer itself. If the product manager wants to change the interface in the middle of the process, it can be maintained by the front end and not by the back end. The back end focuses on its own business logic development, while the front end focuses on product effect development. This allows for a more complete separation of the front and back ends.

Does this look perfect at first glance? But is this really the case?

There is nothing new under the sun

If you pay close attention to the figure in the article, you will find that the whole system is becoming more and more complex. The complexity of the system will bring many problems, such as the increase of staff communication costs, the decline of the overall performance of the system, and the increase of security risks. These are all old stories, these are always going to happen when you add layers to the system, any other questions?

Let’s think about one thing: are these things non-Node can’t do?

Apparently not. In theory, these problems can be solved by designing the hierarchical architecture in the service layer. So why are people still advocating the Node middle layer these years?

Some would say Node is good for SSR (server-side rendering). Yes, this is an advantage of Node, but the question remains, does it have to be Node?

Now using Node to do SSR, do not feel the design concept and many years ago JSP is very similar?

So what is it that drives so many people to explore this path?

Here’s my bootleg.

My point of view

Declare in advance, the following content, purely personal point of view, do not like spray.

Let’s start with a joke: “PHP is the best language in the world.”

I believe that the people who hear this sentence will find it very funny, although it has become a joke, but reflects an objective existence of the situation — the chain of contempt.

Contempt, like a food chain, is a vicious circle. In this cycle, everyone is at the end of the chain.

And the reason why there will be such a chain of contempt, and the difficulty of work and pay has a lot to do with.

A good system is high availability, high concurrency, and high performance, all three of which are usually the domain of the back-end programmer, whose role is limited. The work that stem is not important, treatment nature cannot raise, despise chain also arises at the historic moment.

So, in order to fight back, the study of low cost, can quickly start NodeJS was front-end programmers, began to take over some back-end programmers are not willing to do live at the edges (data format conversion, field calibration), thinking of the front-end is responsible for the function is no longer such a foundation drawing page, importance will gradually.

At the end of the day, it’s because the front end needs to increase its proportion in the business and thus improve its position. Whether Or not NodeJS is a viable alternative to traditional server-side languages seems less important. Maybe after the development of the Node middle layer in the future, it will decouple and split.

Then you will find that the front of the students in the company tend to push back end on the grounds of architectural design personnel in the whole system design to add a Node layer, so that they, as for the backend staff may not want to put these pieces of work to a Node layer staff to do it is debatable (backend are, after all, there are a lot of solution for the data requirements, GraphQL is one of them).

To paraphrase a line from the grave robbery notes

“The most complicated thing is not the software system, but the human mind.”