Due to compliance requirements, some terms and data in this article have been desensitized.

Background#

The first project I joined at Alibaba was an old business, with a tightly coupled frontend and backend. Most of the logic resided within backend Velocity templates.

As a frontend developer, trying to debug VM templates without backend environment support during development was an extremely painful experience.

Because for any requirement, it involved:

1. Modifying the VM code within the backend project
2. Deploying the backend project on Aone, a step that took about half an hour
3. Refreshing the browser for verification after successful deployment

In other words, the cost of modifying even a single line of code was at least half an hour. Moreover, development heavily relied on backend team members’ support. For example, if I wanted the frontend to display process A in a branching workflow, I’d need the backend team to provide the data for process A, then wait half an hour. If I wanted to display process B, it would be another half an hour. If backend team members were busy and couldn’t provide support, my frontend development would have to be put on hold.

After completing one requirement, I realized this entire development process was truly agonizing and incredibly inefficient. A task I thought would take two days ended up taking a full week, and I even had to pull an all-nighter just to barely catch up.

I also felt that Alibaba’s technology wasn’t as advanced as I had imagined, but this also presented an opportunity. So, I started thinking about potential solutions.

Solution#

After some research and discussions, we decided to use velocityjs for frontend rendering of VM templates to solve the VM debugging problem during local development. velocityjs parses VM templates using nodejs to produce html strings.

With velocityjs, things became much simpler. To debug a module, all we needed to do was find the mock data and the VM template, then render it and return it to the browser.

The final solution is as follows:

Implementation#

With the solution outlined above, our implementation became quite straightforward. For an incoming request, the processing flow is as follows:

1. The local Node service runs on port 3000.
2. Bind host: 127.0.0.1 xxx.alibaba.com.
3. For an online product URL like https://wholesaler.alibaba.com/xxx/xxx.html, replace wholesaler with xxx to get http://xxx.alibaba.com:3000/xxx/xxx.html.
4. After the local Node service receives the request, it first fetches the original HTML for that product from the online server, along with the PAGE_SCHEMA module data used for asynchronous rendering.

   PAGE_SCHEMA is specific to a certain website on the international station. When the backend renders a VM, it simultaneously returns the data for that VM module to the frontend, mounted under the global window variable.

5. Locate the VM template for the module to be debugged locally.
6. Render the VM template using mock data or the online PAGE_SCHEMA module data.
7. Replace the corresponding DOM node in the original HTML with the rendered VM template string, resulting in the reconstructed HTML.
8. Return the reconstructed HTML to the browser, achieving the goal of local debugging.

The final result: Once the environment is set up, for example, if we want to debug the module-xxx module, we can directly modify the VM template within the backend project locally, then refresh the browser to see the changes. Furthermore, only this specific module will be in debug mode; all other modules will appear as they do on the live site.

This reduced the cost of a single code change from half an hour to less than a minute. Moreover, frontend developers can now run the project directly without relying on the backend environment, and we no longer need to constantly bother backend team members for data assistance.

This significantly improved the development experience, making it far less painful.