vivo Mall Frontend Architecture Upgrade: A Layered Architecture Exploration

Background:

One year ago, the vivo Mall still used Java as its core technology, with both frontend and backend handled by Java. Java was responsible for services, databases, and page rendering. While this development model worked well in the early stages, as business iteration accelerated and frontend technology evolved, the drawbacks became increasingly apparent:

Complex and outdated frontend technology stack, making it difficult to improve iteration speed By December 2018, due to accumulated requirements, different pages used different technologies: jQuery, Vue, FreeMarker, and artTemplate. The same content required development multiple times using different tech stacks, multiplying workload for development and testing.

Inability to meet multi-platform development requirements After WeChat launched mini-programs in 2017, various mini-programs emerged. Although vivo Mall launched its own WeChat mini-program, the native development approach couldn't achieve code that runs on multiple platforms.

Layered Architecture:

According to the book "Frontend Architecture: From Entry to Micro-Frontend," frontend architecture can be designed in four levels: System Level, Application Level, Module Level, and Code Level. Through these four levels, vivo Mall analyzed their architecture upgrade process and developed a full-stack architecture solution centered on Vue + Node.js.

1. System Level

Addresses how applications relate within the entire system, including backend communication and integration with other applications. Key areas explored include frontend-backend separation, multi-platform unification, BFF (Backend for Frontends), and SSR (Server-Side Rendering).

Frontend-Backend Separation: The first step in architecture upgrade was separating frontend from backend. Using Nginx to route requests to new static resource services after module separation improved frontend development efficiency by at least 2x.

Multi-Platform Unification: With increasing platforms (PC browser, mobile browser, App embedding, various mini-programs, server-side, client-side), frontend engineers faced a "matryoshka doll" trap. Multi-platform unification emerged as a future trend to solve this problem, enabling one technology stack to cover current and future platforms.

BFF (Backend for Frontends):

As platforms increased, interface quantity grew explosively. To solve whether interfaces should be UI-oriented or service-oriented, the BFF pattern was introduced. The key principle is "service autonomy, whoever uses it develops it," reducing communication costs and bringing flexibility and efficiency.

Key technologies include direct Dubbo integration using Dubbo2.js and GraphQL gateway integration, which provides: (1) Request only needed data, (2) Get multiple resources in one request, (3) Powerful API debugging tools.

SSR (Server-Side Rendering):

After frontend-backend separation, SPA with CSR (Client-Side Rendering) was adopted. While CSR saves backend resources and enables partial refreshes, issues include increasingly long first-screen rendering times and serious SEO problems. SSR solves these by having the server complete HTML structure and send it directly to the browser.

Main advantages: Better SEO (search engine crawlers can view fully rendered pages) and faster time-to-content, especially for slow networks or devices. Using the Nuxt framework with optimizations like page caching, component caching, API caching, and minimized rendering, pages can fully display within 500ms.

2. Application Level

Addresses external application architecture: how multiple applications share components, communicate, and develop common scaffolds. At this level, a UI library was developed for the mall, providing basic component support for other mall-derived projects.

Component Library:

While popular mobile component libraries like antd-mobile and vant are efficient for general Apps, most self-developed Apps have their own design style. Using popular libraries requires frequent source code modifications. The mall implemented its own UI library, now widely used in Mall, Flash Sales, vivo Internal Purchase, and V客 Alliance applications.

3. Module Level

Addresses internal module architecture: code modularization, data and state management. Key work includes extreme modularization for Vue, top-level page design, and data autonomy.

Extreme Modularization:

The solution abandons the official recommended file-type organization and instead organizes modules by function - a "pluggable" component design that aggregates code by functionality. One file package contains all implementations for that feature, including images, styles, scripts, data flow, components, etc.

├── api.js // Interface resources ├── components // Internal components │ ├── component1 │ │ ├── images │ │ ├── index.scss │ │ └── index.vue │ ├── component2 ├── images // Image resources ├── index.scss // Style resources ├── index.vue // Logic implementation ├── module.js // Data flow └── trackData.js // Tracking

Top-level Page Design:

All pages have common functions like skeleton screens before loading, error handling, data collection, pull-to-refresh, pagination, and iOS adaptation. A top-level page component was implemented where all pages inherit, managing common functions globally.

<template> <v-page :pageInit="true" :pageError="false" :pageMonitor="true" @pullDownRefresh="pullDownRefresh" @reachBottom="reachBottom" @pageScroll="pageScroll" > <template slot="header"> <Header /> </template> <template slot="skeleton"> <Skeleton /> </template> <template slot="footer"> <Footer /> </template> </v-page> </template>

Data Autonomy:

Following the principle of "whoever uses it is responsible," a global mixin for pages was developed to automatically register and unload page data, isolating data between pages.

import { mapState, mapGetters, mapActions, mapMutations } from 'vuex' export default (name, module) => ({ computed: { ...mapState(name, Object.keys(module.state)), ...mapGetters(name, Object.keys(module.getters)) }, created () { // todo: need to add judgment whether already registered, dynamically register module if (!(name in this.$store._modules.root._children)) { this.$store.registerModule(name, module) } }, methods: { ...mapActions(name, Object.keys(module.actions)), ...mapMutations(name, Object.keys(module.mutations)) } })

4. Code Level

When writing code, standards and quality must be considered. The purpose of standards is to improve maintainability, while quality is the face of development.

Standards:

Good standards should be simple, easy to remember, and easy to execute. The main standards include development standards and commit standards.

Development Standards: Include naming conventions, HTML standards, CSS standards, and JS standards.

Commit Standards: To standardize code commits, @vivo/commit was encapsulated for mandatory validation. Each commit consists of four parts: modification type (style, fix, feat, refactor, test, doc, conf, merge), affected module, tracking ticket number, and problem description.

Quality:

Quality is improved through code review and code coverage. A VSCode-based code review plugin was developed supporting GitLab with real-time notifications. A test code coverage platform was also built to clearly see how each line of code is executed during testing.

Summary:

This article introduced the background of vivo Mall's architecture upgrade and summarized the practices and explorations in the four levels of System, Application, Module, and Code. The exploration of frontend technology is not over; as the first article of the architecture upgrade series, more articles will follow to explain the difficulties and experiences in detail.