Thinking and practice of front-end and back-end separation based on NodeJS (2) Template exploration_node.js

Foreword

When doing front-end and back-end separation, the first issue that we pay attention to is rendering, which is the work at the View level.

In the traditional development model, the browser side and the server side are developed by different front-end and back-end teams, but the template is in the fuzzy area between the two. Therefore, it is inevitable that more and more complex logic will be added to the template, which will eventually become difficult to maintain.

And we chose NodeJS as a middle layer between the front and back ends. Trying to use NodeJS to streamline the work at the View level.

Makes the division of labor between the front and back ends clearer, allowing the project to be better maintained and achieving a better user experience.

This article

Rendering accounts for a very large proportion of the daily work of front-end developers, and it is also the area where it is most likely to get entangled with back-end development.

Looking back on the development of front-end technology in the past few years, the work at the View level has gone through many changes, such as:

Form Submit full page refresh => AJAX partial refresh
Server-side rendering MVC => Client-side rendering MVC
Traditional page change jump => Single page application
It can be observed that in the past few years, everyone has tended to move rendering from the server side to the browser side.

The server side focuses on servitization and provides data interfaces.

Benefits of browser-side rendering

We all know the benefits of browser-side rendering, such as

1. Get rid of the coupling and confusion of business logic and presentation logic in the Java template engine.
2. For multi-terminal applications, it is easier to interface. Use different templates on the browser side to present different applications.
3. Page rendering is not just HTML. Front-end rendering can more easily provide functions in a componentized form (html js css), so that front-end components do not need to rely on the HTML structure generated by the server.
4. Get rid of dependence on back-end development and release processes.
5. Facilitate joint debugging.

Disadvantages caused by browser-side rendering

But while enjoying the benefits, we also face the disadvantages brought by browser-side rendering, such as:

1. Templates are separated into different libraries. Some templates are placed on the server side (JAVA), while some are placed on the browser side (JS). The front-end and back-end template languages ​​are not connected.
2. You need to wait for all templates and components to be loaded in the browser before rendering can begin, and you cannot view them immediately.
3. When entering for the first time, there will be a white screen waiting for rendering time, which is not conducive to user experience
4. When developing a single-page application, the front-end Route and the server-side Route do not match, which is very troublesome to deal with.
5. Important content is assembled on the front end, which is not conducive to SEO

Reflect on the definition of front-end and back-end

In fact, thinking back, when we moved the rendering work from the server side (Java) to the browser side (JS), our purpose was just to clearly divide the front-end and back-end responsibilities, and it did not mean that browser rendering was indispensable. .

Just because in the traditional development model, after leaving the server, it goes to the browser, so the front-end work content can only be limited to the browser side.

For this reason, many people believe that back-end = server side and front-end = browser side, just like the picture below.

In the Midway project currently being carried out by Taobao UED, by building a NodeJS middle layer between JAVA and Browser, we are trying to redefine the dividing line between the front and back ends based on work responsibilities rather than the hardware environment. To differentiate (server & browser).

So we have the opportunity to share templates and routes, which is also the most ideal state in the division of labor between the front and back ends.

Taobao Midway Midway

In the Midway project, we moved the line that separates the front and back ends from the browser side back to the server side.

With a Nodejs layer that is easily controlled by the front end and is common with the browser, the front-end and back-end separation can be completed more clearly.

You can also let front-end developers decide the most appropriate solution for different situations. Rather than everything being handled on the browser side.

Division of responsibilities

Midway is not a front-end project trying to steal the back-end jobs. The purpose is just to cut through the fuzzy area of ​​templates and obtain a clearer division of responsibilities.

Backend (JAVA), focusing on
1. Service layer
2. Data format and data stability
3.Business logic

Front-end, focus on
1.UI layer
2. Control logic and rendering logic
3. Interaction and user experience

No longer stick to the difference between the server side or the browser side.

Template sharing

In the traditional development model, the browser side and the server side are developed by different front-end and back-end teams, but the template is in the fuzzy area between the two. Therefore, it is inevitable that more and more complex logic will be added to the template, which will eventually become difficult to maintain.

With NodeJS, back-end students can focus on the development of business logic and data at the JAVA layer. The front-end students focus on the development of control logic and rendering. And you can choose whether these templates should be rendered on the server side (NodeJS) or the browser side.

Using the same template language XTemplate and the same rendering engine JavaScript

Render the same result in different rendering environments (Server-side, PC Browser, Mobile Browser, Web View, etc.).

Route Sharing

Because of the NodeJS layer, routing can be controlled in more detail.

If you need to do browser-side routing on the front end, you can configure server-side routing at the same time so that you can get a consistent rendering effect during browser-side page change or server-side page change.

At the same time, SEO issues were also dealt with.

Practice of template sharing

Usually when we render a template on the browser side, the process is nothing more than

Load the template engine (xtmpleate, juicer, handlerbar, etc.) in the browser
Load the template file in the browser, the method may be
Use to print on the page
Use module loading tools to load template files (KISSY, requireJS, etc.)
Others
Obtain data and use template engine to generate html
Insert html into the specified location.
It can be observed from the above process that in order to achieve cross-end sharing of templates, the focus is actually on consistent module selection.

There are many popular module standards on the market, such as KMD, AMD, and CommonJS. As long as the NodeJS template file can be output to the NodeJS side through consistent module specifications, basic template sharing can be done.

The subsequent series of articles will further discuss the proxy and sharing of Model.

Case Study

Because of the middle layer of Midway Island, some problems in the past have been better answered, such as

Case 1 Complex interactive application (such as shopping cart, order page)

Status: All HTML is rendered on the front end, and the server only provides interfaces.
Problem: When entering the page, there will be a brief white screen.
Answer:
When you enter the page for the first time, perform full-page rendering on the NodeJS side and download the relevant templates in the background.
Subsequent interactive operations are completed on the browser side with partial refresh
Using the same template produces the same results

Case 2 Single-page application

Status: Use the Client Side MVC framework to change pages in the browser.
Problem: Rendering and page changing are completed on the browser side. When entering the URL directly or refreshing with f5, the same content cannot be directly displayed.
Answer:
Share the same Route settings on the browser side and NodeJS side
When changing pages on the browser side, perform Route changes and page content rendering on the browser side
When the same URL is entered directly, the page frame and page content are rendered on the NodeJS side
Whether you change the page on the browser side or enter the same URL directly, the content you see is the same.
In addition to increasing experience and reducing logic complexity. It also solves the SEO problem

Case 3 Pure browsing page

Status: The page only provides information, with little or no interaction
Problem: HTML is generated on the server side, CSS and JS are placed in another location, and they are dependent on each other.
Answer:
Through NodeJS, unified management of html css js
If you need to expand it into a complex application or a single-page application in the future, it can be easily transferred.

Case 4 Cross-terminal page

Situation: The same application needs to present different interfaces and interactions on different endpoints
Problem: HTML management is not easy. Different HTML is often generated on the server side, and different processing is required on the browser side
Answer:
Cross-terminal pages are a rendering issue and are handled uniformly by the front end.
Through the NodeJS layer and back-end servitization, the best solution can be designed for this type of complex applications.

Summary

The emergence of AJAX, Client-side MVC, SPA, Two-way Data Binding and other technologies in the past were all attempts to solve the bottlenecks encountered in front-end development at that time.

The emergence of the NodeJS middle layer is also an attempt to solve a limitation of the current front-end being limited to the browser side.

This article focuses on front-end and back-end template sharing, and I hope it can inspire others to discuss how we can improve our workflow and how to cooperate with the back-end under the NodeJS middle layer architecture. The front-end does a better job.