How MPM Revolutionizes H5 Page Data Modeling for Efficient Multi‑Platform Rendering

See the previous articles: MPM Mall Visual Builder – Element Design; MPM Mall Visual Builder – Architecture Process Design.

Preface

This is the third article in the MPM sharing series. In the previous article about architecture process design we only briefly mentioned data requests. In the MPM mall‑building scenario, page data requests are carefully designed and deserve a dedicated chapter. When facing numerous requests, component composition, and three‑end isomorphism, we needed an efficient, universal data‑request solution, which was recently presented at the 3rd Frontend Early‑Bird Conference.

Self‑Introduction

Hello everyone, I am Mu Tong, currently working in JD.com’s Jingxi front‑end team, responsible for the internal H5 mall visual builder – MPM.

Topic Introduction

The theme is how to design and implement data‑modeling for H5 page building. A data model is the layer that centralizes all page data requests. Early MPM versions let each floor handle its own requests, which later caused maintenance and performance problems. Subsequent iterations made data‑model design a core focus.

MPM Overview

System Overview

MPM is JD’s internal H5 mall visual builder, launched in 2016, now in its fourth year with over three major versions. It has over 1,400 users and more than 19,000 pages built. Over 80% of JD’s major promotional events are built with MPM.

Capability Overview

MPM offers a large material library (30+ components, 500+ templates) covering product, guide, marketing, etc. It supports three‑end rendering, page configuration (BI sorting, auto‑tracking, testing, performance), a smooth drag‑and‑drop editor, real‑time preview, health diagnostics, and full monitoring and fallback mechanisms.

Effect Demonstration

The editing interface uses a three‑layer configuration: component → template → properties. Users drag a component onto the preview area, then select a template on the right.

After configuring floor properties, the page is published, resulting in the final display.

System Architecture

MPM is built on four core elements – component, template, property, and data model – forming four parsing engines that transform PageData (a JSON configuration) into actual pages. The top layer includes the editing backend, management backend, and three rendering platforms.

Workflow

Operators drag floors, configure data, and save the page, generating PageData which is published to CDN/Redis. When a user opens the page, each engine fetches PageData, parses it, requests the necessary APIs, renders floors, and finally displays the complete page.

Data‑Layer Pain Points

Scattered Requests

In a mall scenario with many entry points, letting each component issue its own requests leads to chaotic, hard‑to‑maintain, and potentially interfering requests.

Redundant Duplicate Requests

Multiple components may configure the same reservation ID, causing N identical requests that degrade performance if not centrally managed.

High Interface Pressure

Although some APIs support batch calls, independent component requests prevent aggregation, increasing service load.

Variable Data Models

Different templates under the same component may request new‑user prices, subsidy prices, etc., making data‑model composition and maintenance challenging.

Three‑End Isomorphism Requirements

In Vue, data is often fetched in the

created

hook, which works for client‑side rendering but fails for server‑side direct output, necessitating a data‑model that supports three‑end rendering.

Data‑Request Solution

The solution targets three goals: unified management of all page requests, free composition of data models for components/templates, and adaptation for three‑end isomorphism.

Page Model Design

PageData is a JSON object describing page configuration, containing page‑level and component‑level settings. Page‑level config defines global requests (e.g., floor BI sorting, user identity checks). Component‑level config defines each floor’s template, data parameters, and parent‑child relationships.

The structure includes template selection, data configuration (API parameters), and component hierarchy.

Request Model Design

Data Source

A data source is the minimal unit describing a request action, with attributes such as API address, pre‑processing, post‑processing, parameter validation, aggregation strategy, and monitoring configuration.

Developers instantiate a data source via the

fetch

method, binding configuration data to the source identifier.

Higher‑level request models are built by freely composing data sources using functions, enabling both direct source calls and advanced model calls.

System Modules

The Data Center acts as a proxy for all page requests, handling aggregation and distribution. The Request Center parses request objects, performs deduplication, and returns responses.

Request Optimization Strategy

The Request Center maintains three lifecycle states: not‑started, pending, and completed. It uses MD5 hashing to detect duplicates, caches completed responses, and queues callbacks for pending requests, thus eliminating redundant calls.

For aggregation, the

batch

attribute defines

pack

(merge multiple requests),

unpack

(distribute responses), and

limit

(max number of requests). Requests are buffered each tick, packed, sent as a single request, then unpacked to the original callers.

Initial State Function

To support three‑end isomorphism, each MPM component floor now has an async initial‑state function that receives component configuration and returns the data needed for initial rendering.

During server‑side direct output, the engine collects all initial‑state functions, executes them, and uses the resolved data for rendering. On the client, the same functions run in the created hook, ensuring consistent data flow.

For scenarios where a component has a primary and secondary API, the initial‑state function can accept a second

callback

parameter. The first callback triggers server‑side rendering, while subsequent callbacks are ignored on the server but executed on the client, allowing primary data to be rendered immediately and secondary data to be fetched later.

Conclusion

The MPM data‑model solution, while tailored for H5 mall building, offers valuable insights for other page‑building scenarios. Key takeaways: rigorous design, strict standards, and a balance between independence and uniformity are essential for scalable, maintainable systems.

Thank you for watching, and feel free to follow our technical team WecTeam for more sharing.