Experience of Front‑Back End Separation in the Vivo Mall Project

This article shares the experience of separating the front‑end and back‑end of the Vivo official online mall, describing the overall thinking, the concrete separation scheme, and the problems encountered during the process.

Background

Since its launch in 2015, the Vivo mall has grown rapidly, but the monolithic front‑back architecture could no longer keep up with fast business iteration and multi‑device expansion. In 2019 the team decided to upgrade the architecture by adopting a front‑back separation strategy, upgrading front‑end technologies and standardising APIs.

Basic Idea

The business modules form a tree‑like hierarchy: each functional module contains sub‑modules, which in turn may contain further sub‑modules. The page URLs reflect this hierarchy, making it possible to control the request of a specific module and route it to a new front‑end while leaving other requests to the old system.

For example, by intercepting requests under /my/order the order module can be switched to a new static resource server while other modules continue to use the legacy pages.

Step‑by‑Step Separation Scheme

The project uses Nginx as the unified gateway. By configuring location blocks with the longest‑match rule, the team can gradually redirect traffic of specific modules to the new front‑end.

location /my/order { # Match all requests starting with /my/order # Example: https://shop.vivo.com.cn/my/order/list will be intercepted # Forward to the new static resource server proxy_pass http://new-download; }

Similarly, the whole personal‑center can be switched by a broader rule:

location /my { # Match all requests starting with /my # Example: https://shop.vivo.com.cn/my will be intercepted proxy_pass http://new-download; }

When all modules are separated, the root path can be intercepted to serve the new front‑end entirely.

Dual‑Track Development

The separation allows business iteration and module refactoring to proceed in parallel. Each release focuses on one or two modules, enabling simultaneous development of new features and migration of the selected module to the new architecture, which improves both development speed and testing efficiency.

Quality Assurance and Risk Mitigation

To control the risk of large‑scale refactoring, the team adopts:

Forward‑compatible back‑end APIs (new APIs are added while old ones remain functional).

Separate deployment order: back‑end API release → front‑end static resource release → Nginx configuration update.

Online‑offline comparison using HTTP/HTTPS dual access to verify page consistency.

server { listen 80; server_name shop.vivo.com.cn; # Existing configuration remains unchanged ... } server { listen 443; server_name shop.vivo.com.cn; # Separation configuration location /my { proxy_pass http://new-download; } }

Code‑coverage tools are used to ensure test completeness, and rapid rollback is achieved by disabling the Nginx interception rules if an issue arises.

Results

After a year of incremental releases (8 versions), the WAP side achieved full front‑back separation, resulting in:

Front‑end release speed increased by more than 10×.

Development efficiency doubled.

Foundation laid for native‑style multi‑channel expansion.

Technical experience accumulated and shared across teams.

Conclusion

The longest‑running challenge was balancing manpower, business demand, and technical upgrades. The case demonstrates that with careful planning, incremental separation, and rigorous risk control, a large‑scale e‑commerce platform can successfully transition to a modern front‑back separated architecture.