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

This article shows you what the full-stack development based on NodeJS is like, the content is concise and easy to understand, it can definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

With the rise of different terminals (Pad/Mobile/PC), the requirements for developers are getting higher and higher. The responsiveness of pure browsers can no longer meet the high requirements of user experience. We often need to develop customized versions for different terminals. In order to improve development efficiency, more and more attention has been paid to the separation of front and rear ends. The back end is responsible for business / data interface, and the front end is responsible for presentation / interaction logic. We can customize and develop multiple versions of the same data interface.

This topic has been discussed a lot recently, and some BU of Ali are also trying. After a long discussion, our team decided to explore a set of front-end separation scheme based on NodeJS, with some changing understanding and thinking in the process, recorded here, and hope to see students participate in the discussion to help us improve.

First, what is the front and rear separation?

At the beginning of the discussion in the group, I found that everyone had a different understanding of front-end separation, and in order to ensure that they could be discussed on the same channel, they first agreed on what "front-end separation" is.

An agreed example of front-end separation is SPA (Single-page application). All the presentation data used is provided by the back-end through an asynchronous interface (AJAX/JSONP), while the front-end only shows it.

In a sense, SPA does achieve front-end separation, but there are two problems with this approach:

SPA classes account for a small proportion of WEB services. In many scenarios, there is a mixed mode of synchronous / synchronous + asynchronous, and SPA cannot be used as a general solution.

In the current SPA development model, interfaces are usually provided according to presentation logic. Sometimes, in order to improve efficiency, the backend will help us deal with some presentation logic, which means that the backend is still involved in the work of the View layer, not the real separation of front and rear.

SPA-style front-end separation is distinguished from the physical layer (it is considered that as long as the client is the front-end, and the server-side is the back-end). This method can no longer meet the needs of front-end separation, and we believe that the division of responsibilities can meet our current usage scenarios:

Front end: responsible for the View and Controller layers.

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

Why to make this division of responsibilities will be discussed later.

Second, why should the front and rear be separated?

Yubo's article on this issue is very comprehensive in the evolution of the Web R & D model, so let's get a general idea:

2.1 applicable scenarios for existing development models

The several development models mentioned by Yubo have their own applicable scenarios, and none of them completely replaces the other.

For example, MVC, which is mainly based on the backend, is very efficient in doing some synchronous presentation, but it will be more troublesome to communicate with the back-end developers when it comes to pages that combine synchronously and asynchronously.

Ajax is the main SPA development mode, which is more suitable for developing APP-type scenarios, but it is only suitable for APP, because problems such as SEO are not easy to solve, and this development method is too heavy for many types of systems.

2.2 the responsibilities of the front and rear are not clear

In systems with complex business logic, we are most afraid of maintaining code mixed with front and rear, because there are no constraints, there may be other layers of code in each layer of M-V-C, which accumulates over time and has no maintainability at all.

Although front-end separation can not completely solve this problem, it can be greatly alleviated. Because it ensures that you can't do it on a physical level.

2.3 Development efficiency issues

The Web of Taobao is basically based on the MVC framework webx, and the architecture determines that the front end can only rely on the back end.

So our development model is still static demo written at the front end and translated into VM templates at the back end. The problem of this mode is ignored and has been complained about for a long time.

It is also painful to develop directly based on the back-end environment, and it is troublesome to configure, install and use it. In order to solve this problem, we have invented various tools, such as VMarket, but the front end still has to write VM, and relies on back-end data, so the efficiency is still not high.

In addition, the back end can not get rid of the strong focus on presentation, thus focusing on the development of the business logic layer.

2.4 limitations to front-end play

The space for performance optimization is very limited only in the front end, so we often need back-end cooperation to collide with sparks. However, due to the limitations of the back-end framework, it is difficult for us to use Comet, Bigpipe and other technical solutions to optimize performance.

In order to solve some of the problems mentioned above, we have made a lot of attempts and developed various tools, but they have not improved much, mainly because we can only play in the small piece of space that we have been allocated to us at the back end. Only when the front and rear ends are separated, can we completely solve the above problems.

Third, how to separate the front and rear?

In fact, the answer is already found in the * * section on how to separate the front and rear ends:

Front end: responsible for the View and Controller layers.

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

Just imagine, if the frontend has mastered Controller, we can do url design, and we can decide whether to render synchronously on the server or output json data according to the view layer data according to the scenario, and we can also easily do Bigpipe,Comet,Socket according to the needs of the presentation layer.

3.1 "full stack" development based on NodeJS

If we want to achieve the layering in the figure above, we must need a web service to help us do what we did at the back end, so we have the title "full-stack development based on NodeJS".

This picture looks simple and easy to understand, but it has not been tried, there will be a lot of questions.

In SPA mode, the back end has provided the required data interface, and the view front end can be controlled, so why add more NodeJS layer?

If you add one more layer, how is the performance?

If you add one more layer, does the workload of the front end increase?

If you add one more layer, you will have one more layer of risk. How can you break it?

NodeJS can do anything, so why JAVA?

It is not easy to explain these questions clearly. Let's talk about my understanding process.

3.2 Why add a layer of NodeJS?

At this stage, we mainly develop the mode of back-end MVC, which seriously hinders the efficiency of front-end development and prevents the back-end from focusing on business development.

The solution is to allow the front end to control the Controller layer, but it is difficult to do so under the existing technical system, because it is impossible for all front ends to learn from java, install the back-end development environment, and write VM.

NodeJS can solve this problem very well, we do not need to learn a new language, we can do what developers did for us before, everything seems so natural.

3.3 performance issu

Layering involves communication between each layer, and there must be a certain degree of performance loss. But reasonable layering can make responsibilities clear and facilitate collaboration, which will greatly improve the efficiency of development. The loss caused by layering must be made up for by the gains in other aspects.

In addition, once we decide to layer, we can reduce the loss to * as much as possible by optimizing communication methods and communication protocols.

For example:

After Taobao Baby details page is static, there is still a lot of information that needs to be obtained in real time, such as logistics, promotions, and so on. Because these information are in different business systems, the front end needs to send 5 asynchronous requests to backfill these contents.

With NodeJS, the front end can proxy these five asynchronous requests in NodeJS and can easily do Bigpipe. The optimization of this piece can greatly improve the overall rendering efficiency.

On PC, you may think it's okay to send five hundred and six asynchronous requests, but on the wireless side, it's expensive to set up a HTTP request on a customer's phone, and with this optimization, the performance is improved several times.

Taobao details based on NodeJS optimization we are in progress, after the launch I will share the optimization process.

3.4 has the workload of the front end increased?

It must be a little more than just cutting pages / doing demo, but there are joint debugging and communication links in the current mode, which is very time-consuming, easy to bug and difficult to maintain.

Therefore, although the workload will increase a little, the overall development efficiency will be greatly improved.

In addition, testing costs can be saved a lot. Previously developed interfaces are aimed at the presentation layer, so it is difficult to write test cases. If the front and rear ends are separated, or even the tests can be separated, a group of people specialize in testing interfaces and a group of people focus on testing UI (this part of the work can even be replaced by tools).

3.5 how to control the risk caused by adding the Node layer?

With the large-scale use of Node, students from the system / operation and maintenance / security department will certainly join in the infrastructure, and they will help us to improve the problems that may arise in each link and ensure the stability of the department.

3.6 Node can do anything, so why JAVA?

Our original intention is to do front-end separation, and it would be a bit contrary to our original intention to consider this issue. Even if we use Node instead of Java, there is no guarantee that we will not have the problems we encounter today, such as unclear responsibilities. Our goal is hierarchical development, professional people, and focus on doing professional things. The JAVA-based infrastructure is already very strong and stable, and is more suitable for doing what the current architecture does.

Fourth, Taobao front and rear separation based on Node

The picture above is my understanding of Taobao's front and rear separation layers based on Node, as well as the terms of reference of Node. A brief explanation:

The top end is the server, which is what we often call the back end. For us, the back end is a collection of interfaces, and the server provides a variety of interfaces for us to use. Because there is a Node layer, there is no need to limit what form of service it is. For back-end developers, they only use interface implementations that care about business code.

Below the server is the Node application.

In the Node application, there is a layer of Model Proxy to communicate with the server. At present, this layer is mainly to smooth out the way we call different interfaces and encapsulate some of the Model needed by the view layer.

The Node layer can also easily implement requirements such as the original vmcommon,tms (referencing Taobao content management system).

It is up to the developer to decide what framework to use in the Node layer. However, it is recommended to use the combination of express+xTemplate, xTemplate can be common to the front and back end.

It's up to everyone to decide how to use Node, but the exciting thing is that we can finally use Node to easily achieve the output mode we want: JSON/JSONP/RESTful/HTML/BigPipe/Comet/Socket/ synchronous, asynchronous, whatever you want, depending on your scenario.

The browser layer has not changed in our architecture, and we don't want to change the perception you used to develop in browsers because of the introduction of Node.

The introduction of Node only puts the part that should be controlled by the front end under the control of the front end.

We already have two projects under development in this model, although it is not online yet, but we have already tasted the benefits in terms of development efficiency and performance optimization.

5. What else do we need to do?

Integrate the Node development process into Taobao's existing SCM process.

Infrastructure construction, such as session,logger and other general modules.

* Development practice

Online success stories

Everyone's understanding of the concept of separation between front and rear of Node

Safety

Performance

...

Technologically, there will not be much need for innovation and research, there has been a lot of ready-made accumulation. In fact, the key is the opening of some processes and the accumulation of general solutions. I believe that with more project practice, this piece will gradually become a stable process.

VI. Midway Island

While the NodeJS-based full-stack development model is exciting, there is still a long way to go to make Node-based full-stack development stable and acceptable to everyone, and the "Midway Island" project we are working on is to solve this problem. Although we started not long ago, we are getting closer and closer to the goal!

The above is what full-stack development based on NodeJS is like. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

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.