Velocity is a Java-based Web page template engine. More than a decade ago, Velocity separated Java code from Web pages, enabling developers to parallelize Web development and Java development. With the wave of separation of the front and back ends of the decade, looking back and facing these old Velocity-based systems, there will be many problems in both the back-end and front-end maintenance:
(1) Back-end personnel maintenance: not familiar with the front-end development mode, it takes a lot of effort to learn UI and Js framework;
(2) Front-end personnel maintenance: Velocity rendering relies on the Java environment, requiring a lot of effort to learn Maven projects and environment configurations, and the front-end MVC framework version is old, resulting in low development efficiency.
This situation widely exists in some old systems in retail, and the continuous iteration of business requirements will lead to higher and higher system maintenance costs. For page modules that require frequent iterations, a common countermeasure is to adopt a front-end and back-end separation scheme to refactor the page as a whole, but after this, the cost of the overall refactoring is huge, mainly reflected in the following points:
(1) Need to cover all business scenarios and requirements;
(2) Lack of test materials covering all scenarios;
(3) Page refactoring itself does not bring business value.
Our team undertook the B-side business. Due to the early start of the business, it is inevitable to maintain these Velocity systems.
Aiming at the pain point of difficult maintenance of the old system, we have explored a technical route with low intrusion to the old system and gradual upgrade of the technical architecture in practice. It is divided into 4 steps, which are (1) build Velocity+MVC+MVVC hybrid Architecture; (2) Establish Velocity single-file componentization capabilities; (3) Create a Velocity local sandbox environment; (4) Separate the front and back ends of Velocity pages. The following are detailed descriptions respectively:
1. Build Velocity + MVC + MVVC hybrid architecture
Most of the Velocity systems still use Js frameworks such as JQuery, and the development efficiency is low, which needs to be improved urgently. Compared with the MVC framework and the MVVC framework, the MVVC framework encapsulates the logic of the view layer, and the development efficiency is significantly improved.
Therefore, the first step is to introduce the MVVC framework into the Velocity page to realize the coexistence of the two technical architectures. We introduced Vue and the supporting UI component library. The main factors for considering Vue are as follows:
(1) Vue supports the introduction and use of Js resource links, that is, adding a line of script tags to the Velocity page can be used out of the box;
(2) Velocity's page writing syntax is very close to Vue's template syntax.
Inside the hybrid architecture, template rendering needs to be performed in two steps: first, the Velocity template is rendered as a Vue template on the server side, and the Vue template is rendered as the final page on the client side.
The problem with the hybrid architecture is that because some key parameters in the session are directly output from the server, Vue cannot directly obtain these parameters. Therefore, the solution for passing parameters is to bury some placeholders in the page in advance. When Vue executes, it accesses the DOM to get.
When the subsequent requirements are iterated, the business logic can be gradually migrated from the old MVC technology stack to the new MVVC technology stack to improve development and maintenance efficiency.
2. Establish Velocity single-file componentization capability
When the project scale is large, there may be some similar functions or logic between different modules, the problem before us is how to achieve module-level function reuse.
Therefore, the second step is to introduce componentization capabilities into the Velocity system to realize cross-page code reuse. Because the Velocity system relies on the Java environment for rendering, it is difficult to apply the NodeJs-based front-end engineering capability, and cannot directly use Vue's single-file componentization capability. Fortunately, Velocity's inclusion (#include) and parsing (#parse) capabilities can be used in conjunction with Vue's API interface to implement an innovative Velocity+Vue single-file componentization technology.
If you are familiar with Vue, you must be familiar with Vue single-file components, that is, a file whose file name ends with a .vue suffix, which describes a Vue component. The internal structure of the three axes: template, script, style, simply put Describes the template rendering, logic interaction, and css style of the component respectively.
The organization method of Velocity single-file components refers to this hierarchical structure. A file whose file name ends with .vm suffix is used to describe a Velocity component. Due to the lack of engineering capabilities, the differences are: (1) In order to be compatible with lower version browsing browser, you need to use the script tag to host the template; you can also use the template tag directly if you don’t consider browser compatibility. (2) It is necessary to manually call Vue.component to perform component registration.
After realizing single-file componentization, Velocity pages can be assembled layer by layer through smaller-grained components, further reducing the degree of business coupling of the system.
3. Create Velocity local sandbox environment + front-end engineering
The first two steps have greatly optimized the overall system architecture, but there is still a pain point that has not been resolved: Velocity rendering relies on the Java environment, and front-end students who are used to local development will be speechless: to fix a small problem requires local blind development -> online deployment Container -> see the effect -> continue to modify blindly, and a few hours will pass.
Therefore, the third step is to realize the Velocity local compilation and development environment, and introduce engineering technology to realize hot update.
The core idea to solve Velocity local compilation is to simulate the environment variables of Server and support Velocity syntax compilation. We built a set of front-end sandbox projects based on Velocity. The former is implemented by mocking server-side variables in the project, and these environment variables are carried in the local JSON data source; the latter is based on Velocity grammar AST refactoring, and a A set of parsing engine Velocity-loader, which supports real-time parsing of files in webpack and injecting environment parameters.
After the introduction of the sandbox capability, the development process has changed to local real-time development of Velocity, and hot updates have reached the millisecond level. The development experience is only one word: cool.
4. Separation of front and back end of Velocity page
In fact, compared with the first three steps, we are very close to the complete separation of the front and back ends of the Velocity page.
The fourth step is to truly realize the front-end independent construction and deployment of Velocity pages, and permanently get rid of the dependence on server-side rendering. However, because Vue-loader actually parses the template syntax into a render function during project compilation, which has destroyed the structure of the template syntax, it cannot support dynamic parsing of Velocity on the client side, and needs to solidify the rendering environment variables. The dynamic data rendering part of Velocity needs to be rewritten into Vue syntax to achieve, relying on client-side Ajax to refresh dynamic data and pages.
So far, we have fully realized the gradual evolution from the back-end application of Velocity to the front-end engineering. There is a long way to go, and I will explore it up and down, and welcome all readers to discuss together.
Author: Jingdong Retail Chen Zhen
Content source: JD Cloud developer community