Preface
When separating front and back ends, the first issue I pay attention to is rendering, that is, work at the View level.
In the traditional development model, the browser and server are developed by two teams, both front and back ends, but the template is in the vague area between the two. Therefore, there are always more and more complex logics on the template, which are ultimately difficult to maintain.
And we chose NodeJS as the middle layer of the front and back ends. Try to use NodeJS to clear up the work at the View level.
This makes the division of labor between front and back ends clearer, makes the project better maintained and achieves a better user experience.
This article
The rendering work is a very large proportion of the daily work of front-end developers, and it is also the easiest part to be confused with back-end development.
Looking back on the past few years of front-end technology development, the work at the View level has undergone many changes, such as:
Form Submit Full Page Refresh => AJAX Local Refresh
Server-side continuation + MVC => Client-side rendering + MVC
Traditional page change jump => Single page application
It can be observed that in recent years, everyone has tended to move this thing from the server end to the browser end.
The server side focuses on service and provides data interfaces.
Benefits of browser rendering
We all know the benefits of browser-side rendering, like
1. Get rid of the coupling and confusion between business logic and presentation logic in the Java template engine.
2. For multi-terminal applications, it is easier to interface. Couple different templates on the browser side to present different applications.
3. Page rendering is not only HTML, but the rendering on the front end can easily provide functions in 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 the dependence on back-end development and distribution processes.
5. Convenient joint adjustment.
The disadvantages caused by browser rendering
But while enjoying the benefits, we also face the disadvantages of browser-side rendering, such as:
1. The template is separated in different libraries. Some templates are placed on the server side (JAVA), while others are placed on the browser side (JS). The front and back-end template languages are not connected.
2. You need to wait for all templates and components to be loaded on the browser before rendering can start, and you cannot read it immediately.
3. There will be a white screen waiting for rendering for the first time, which is not conducive to user experience
4. When developing a single-page application, the front-end Route does not match the server-side Route, which is very troublesome to handle.
5. All important contents are assembled at the front end, which is not conducive to SEO
Reflect on the definition of front and back ends
In fact, when we take the rendering work from the server side (Java) to the browser side (JS), our purpose is only to clearly divide the front and back end responsibilities, and it is not necessary to render the browser.
It is just because in the traditional development model, the server is released and the browser is reached, so the work content on the front-end can only be limited to the browser side.
Therefore, many people have determined that the backend = server frontend = browser side, just like the picture below.
In the Midway Midway project currently underway by Taobao UED, by building a NodeJS middle layer in the middle of JAVA Browser, we try to differentiate the front and back end division line again for work responsibilities, rather than for hardware environments (server & browser).
Therefore, we have the opportunity to share templates and routes, which is also the most ideal state in front-end and back-end division of labor.
Taobao Midway Midway
In the Midway project, we moved the line that demarcates the front and back ends from the browser to the server side.
With a Nodejs layer that is easily controlled by the front-end and common to the browser, the front-end separation can be completed more clearly.
It is also possible to allow front-end development to decide the most appropriate solution for different situations. Instead of everything being handled on the browser side.
Dividing responsibilities
Midway is not a project that the front-end tries to grab the back-end job. The purpose is to clearly cut the vague area of the template 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, rendering logic
3. Interaction, user experience
And no longer stick to the differences between the server or browser side.
Template Sharing
In the traditional development model, the browser and server are developed by two teams, both front and back ends, but the template is in the vague area between the two. Therefore, there are always more and more complex logics on the template, which are ultimately difficult to maintain.
With NodeJS, backend students can focus on the development of business logic and data in the JAVA layer. Front-end students focus on the development of control logic and rendering. And you can choose these templates yourself to render on the server side (NodeJS) or 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.).
Routing Sharing
Also because of the NodeJS layer, you can control routing more carefully.
If you need to do browser-side routing on the front-end, you can configure the server-side routing at the same time so that it can change pages on the browser-side or pages on the server-side, and you can get a consistent rendering effect.
At the same time, the SEO problem was also handled.
The practice of template sharing
Usually when we render a template on the browser, the process is nothing more than
Enter the template engine in the browser (xtmpleate, juicer, handlerbar, etc.)
Load template archives on the browser side, the method may be
Print on the page using <script type="js/tpl"> ... </script>
Use the module loading tool to load template archives (KISSY, requireJS, etc.)
other
Get data and use the template engine to generate html
Insert html into the specified location.
The above process can be seen that if you want 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 archive can be output to the NodeJS end 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 discussion
Because of the intermediate layer of Midway Island, there are better answers to some past questions, such as
Case 1 complex interactive applications (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:
Enter the page for the first time, render the full page on the NodeJS side, and download related templates in the background.
Subsequent interactions, complete partial refresh on the browser side
Using the same template produces the same result
Case 2 single page application
Status: Use the Client Side MVC framework to change pages in the browser.
Problem: Rendering and page replacement are both completed on the browser side. When you enter the URL directly into or refresh the f5, the same content cannot be directly presented.
answer:
Share the same Route settings on the browser side and NodeJS side
When changing pages on the browser side, change the Route and render the page content on the browser side.
When directly entering the same URL, use the page frame + page content rendering on the NodeJS side
Whether you change pages on the browser or directly enter the same URL, the content you see is the same.
In addition to increasing experience and reducing logical complexity. It also solved the SEO problem
Case Three Pure Browsing Page
Status: The page provides only information, less or no interaction
Problem: HTML is generated on the server side, CSS and JS are placed in another location, and they have dependencies between each other.
answer:
Through NodeJS, unified management of html + css + js
If you need to expand into complex applications or single-page applications in the future, you can also easily transfer them.
Case four-cross terminal page
Status: The same application needs to present different interfaces and interactions at different endpoints
Problem: html management is not easy, and different html will often be generated on the server side, and different processing will be done on the browser side.
answer:
Cross-terminal pages are rendering issues and are handled by the front-end.
Through the NodeJS layer and backend service, the best solutions can be designed for this type of complex applications.
Summarize
The emergence of technologies such as AJAX, Client-side MVC, SPA, Two-way Data Binding in the past were all attempts to solve the bottlenecks encountered in front-end development at that time.
The emergence of NodeJS intermediate layer is also an attempt to solve a limitation that the front-end is currently limited to the browser.
This article focuses on sharing front-end and back-end templates, and hopes to attract attention. Let’s discuss with you how to improve our workflow and cooperate with the back-end to do a better job in the front-end under the NodeJS middle layer architecture.