preface

Recently, I hit a wall. In a new project developed by the company, I boldly proposed the complete separation of the front and back ends, and replaced the complicated mixed business logic of the front and back ends with JavaScript template engine, Ajax, routing and other technologies. Halfway through the project, my predecessors proposed that the power of the front end alone could not meet the company’s requirements for SEO. Do you abandon your previous work and go back to the back-end Velocity templating engine to render pages, shifting the focus to the Java back end, or do you stick to the full back-end separation route but take a different path? Finally came the bold decision to build an intermediate layer with nodeJS to render the data, making up for SEO friendliness that front-end template engines and routing could not do. Youth is optional, ha ha ^_^

Separation of front and rear ends (refer to Taobao)

What is front end separation

A commonly agreed example of the separation of the front and back ends is SPA(Single-Page Application), where all presentation data is provided by the back end via an asynchronous interface (AJAX/JSONP) and the front end just presents it. In a sense, SPA does achieve front and back end separation, but there are two problems with this approach:

• The proportion of SPA classes in WEB services is very small. There are also synchronous/synchronous + asynchronous mixed patterns in many scenarios, and SPA cannot be a one-size-fits-all solution.

• In the current SPA development model, interfaces are usually provided in accordance with presentation logic, and sometimes the back end handles some presentation logic for us to improve efficiency, which means that the back end is still involved in the View layer, rather than the real separation of the front and back ends.

Spa-style separation of front and rear ends is to distinguish from the physical layer (as long as the client end is the front end and the server end is the back end). This division can no longer meet our requirements for separation of front and rear ends. We believe that division of responsibilities can meet our current use scenarios:

• Front end: Responsible for the View and Controller layers.
• Back end: Only responsible for Model layer, business processing/data, etc.

Why do we separate the front and back ends

Applicable scenarios for existing development patterns

Different development patterns have their own application scenarios, and no one completely replaces the other.

• For example, the back-end oriented MVC has high business efficiency in doing some synchronous presentation, but it will be more difficult to communicate with the back-end development when it comes to the page combining synchronous and asynchronous.
• Ajax mainly spa-type development mode, more suitable for the development of APP type scenarios, but only suitable for APP, because SEO and other problems are difficult to solve, for many types of systems, this development mode is too heavy.

Unclear responsibilities at the front and back ends

In a system with complex business logic, we are most afraid of maintaining the code mixed up at the front and back ends. Because there is no constraint, each layer of M-V-C may have other layers of code, accumulated over a long period of time, and there is no maintenance at all. Separation of the front and back ends does not completely solve this problem, but it can be greatly alleviated. Because there’s a physical guarantee that you can’t do that.

Development efficiency problem

E-commerce website Web is basically based on MVC framework WebX, which determines that the front-end can only rely on the back-end. So our development model is still static demo written on the front end and TRANSLATED into VM template on the back end. The problem of this model is not mentioned, which has been teased for a long time.

Developing directly based on a back-end environment is also painful, and cumbersome to configure, install, and use. In order to solve this problem, we invented various tools, such as VMarket, but the front-end still wrote VM and relied on back-end data, which was still inefficient.

In addition, the back end cannot escape the strong focus on presentation to concentrate on the development of the business logic layer.

Limitations on front-end play

Performance optimization is limited on the front end, so we often need back-end cooperation to hit the ground running, but due to the limitations of back-end frameworks, it is difficult to use Comet, Bigpipe and other technical solutions to optimize performance.

We tried a lot and developed tools to solve some of the problems mentioned above, but we never really got anywhere, mainly because we were limited to the small space we were given at the back end. Only by truly separating the front and back ends can we completely solve the above problems.

How do you separate the front and back ends

Front end: Responsible for the View and Controller layers. Back end: Responsible for Model layer, business processing/data, etc.

Imagine, if the front end master Controller, we can do URL design, we can decide whether to synchronize render on the server side according to the scene, or output JSON data according to the view layer data, we can also make Bigpipe,Comet,Socket and so on easily according to the presentation layer requirements. It’s all about requirements.

Based on NodeJS “full stack” development

If we want to achieve the layering above, we need a Web service to do what the back end used to do, hence the title “Full stack NodeJs-based development.”

This graph looks simple and easy to understand, but without trying, there are many questions.

• In SPA mode, the back end already provides the required data interface, and the view front end is already controllable. Why add NodeJS layer?
• Add another layer. What’s the performance?
• Does adding another layer increase the front-end workload?
• One more layer means one more layer of risk. How do you break it?
• Why JAVA when NodeJS can do everything?

These questions are not easy to explain, so here is my understanding process.

Why add a layer of NodeJS?

At present, we mainly develop in 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 for the front end to be able to control the Controller layer, but it’s hard to do that with existing technology because it’s impossible for all the front ends to learn Java, install the back-end development environment, and write VMS.

NodeJS is a great way to solve this problem. We don’t have to learn a new language to do what developers used to do for us, and everything feels natural.

Performance issues

Layering involves communication between layers, and there are certain performance costs. But proper layering makes responsibility clear and collaboration easy, which can greatly improve development efficiency. What is lost in stratification must be made up for in gains elsewhere. In addition, once we decide to layer, we can optimize the communication mode and communication protocol to minimize the loss as much as possible.

Here’s an example:

After the static detail page of Taobao Baby, there are still a lot of real-time information to be obtained, such as logistics, promotion and so on. Because these information are in different business systems, the front-end needs to send 5 or 6 asynchronous requests to backfill these contents. With NodeJS, the front-end can broker the 5 asynchronous requests in NodeJS, and it’s also easy to do Bigpipe, which makes the overall rendering much more efficient. On a PC, you might think it’s ok to send 5 or 6 asynchronous requests, but on a wireless end, setting up an HTTP request on a client’s phone is expensive. With this optimization, performance is improved several times.

Has the front-end workload increased?

Compared to just cutting pages/doing demos, this is definitely a bit more, but in the current mode there are joint research and communication links, which are very time consuming, bug-prone and difficult to maintain.

So, although the workload will increase a little bit, the overall development efficiency will increase a lot.

In addition, testing costs can be greatly saved. Previously developed interfaces were for the presentation layer, making it difficult to write test cases. If you separate the front and back ends, even testing can be separated, with one team dedicated to testing the interface and another dedicated to testing the UI (which can even be done with tools).

How to control the risk of adding Node layers?

With the large-scale use of Node, students from the system/operation and maintenance/security departments will definitely join in the infrastructure construction. They will help us to improve the problems that may occur in each link and ensure the stability of the system.

Why JAVA when Node can do everything?

Our intention was to separate the front end from the back end, and to think about that kind of defeats our intention. Even with Node replacing Java, there is no guarantee that we won’t have the same problems we have today, such as unclear responsibilities. Our goal is to layer development, professional people, focus on doing professional things. The Java-based infrastructure is already strong and stable, and much better suited to doing what today’s architecture does.

Taobao is based on the front and back end separation of Node

• The top end is the server side, which is often referred to as 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 limit to what type of service it is. For back-end development, they only care about the interface implementation of the business code.

• Below the server is the Node application.

• A Node application has a layer of Model Proxy that communicates with the server. This layer is mostly about smoothing out the way we call different interfaces and encapsulating some of the Models that the View layer needs.

• Node layer can easily realize the original VMCommon, TMS (reference taobao content management system) and other requirements.

• The framework used for the Node layer is up to the developer. However, the combination of Express and xTemplate is recommended, because xTemplate is common to both the front and back ends.

• How to use the Node to decide, but the exciting is that we can finally use the Node easily implement we want to output mode: JSON/JSON/RESTful/HTML/indicate/Comet/Socket/synchronous, asynchronous, think how the whole is how the whole, completely according to your scene.

• The browser layer doesn’t change in our architecture, and we don’t want to change your perception of development in the browser by introducing Node.

• By introducing Node, you simply give the front-end control of what should be the front-end control.

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.
• Best development Practices
• Online Success Stories
• The concept of Node front-end separation
• security
• performance

There is not much need to innovate and research in technology, there is already a lot of ready-made accumulation. In fact, the key is to get through some processes and accumulate common solutions. I believe that with more project practices, this will gradually become a stable process.

conclusion

The full stack development mode based on Node taobao is a good example, open source technology, we can fully learn from their successful experience. Well, the text introduction we see may not be very cool, finally leave an online slide, also from Taobao, interested can have a look.

Separation practice of Front and rear End of Taobao