How Haro’s “Lego” System Revolutionizes Multi‑Team Mobile Page Development

Background

Haro’s rapid growth from two‑wheel to four‑wheel services has pushed its app DAU beyond 10 million, spawning dozens of business units and a complex matrix of scenarios such as ride‑hailing, delivery, hotels, and more. The platform operations team manages critical entry points like the app launch and home page, acting both as a traffic distributor and a platform for new business development.

Key Challenges

Core pages require coordination across multiple teams, leading to high development complexity and collaboration costs.

Business units need rapid iteration to validate product directions, but existing processes are slow.

Pages must support dynamic, strategy‑driven operations while guaranteeing user experience and stability.

Solution Overview – The “Lego” System

The Lego system is an end‑to‑end dynamic page publishing platform built to address the above problems. It follows a container‑based, modular architecture that separates concerns into three layers:

Product‑ops configuration backend for online orchestration and approval.

Configurable aggregation service with metadata‑driven data pipelines.

Mobile‑side Lego container framework that renders modular components dynamically.

Design Components

1. Product‑Ops Backend

Provides permission approval, multi‑environment publishing (test, pre‑release, gray, production), and page‑level dynamic composition of modules, components, styles, and content.

Integrates with experiment platforms and data services to enable personalized (“thousands of faces”) experiences.

2. Aggregation Service (Backend)

Metadata‑driven configuration portal manages data source bindings, parameter mapping, and dynamic scripts.

Implements a BFF layer that visualizes data orchestration, supports fault‑tolerance, observability, and graceful degradation.

3. Mobile Lego Container (Frontend)

Adopts adapter‑pattern and dependency inversion to register modules via annotations, centralizing them in a module repository.

Defines a generic Adapter Protocol, isolates business logic from dependencies, and supports hot‑plug modules.

Abstracts layout data, state management, lifecycle, and event bus to create reusable components and reduce code duplication.

Integrates Haro’s internal “Wukong DSL” for fine‑grained UI rendering, enabling dynamic content updates without redeployment.

System Architecture

The architecture is visually represented (image omitted) and emphasizes the three‑layer separation: product‑ops backend, aggregation service with metadata, and mobile container framework, each exposing configuration‑driven APIs to the next layer.

Mobile Container Details

The container splits a page into modular pieces, assembles them according to abstract rules, and assigns each module its own lifecycle, data flow, and event bus. Structured data (data + container + module tree + render nodes) drives the composition, allowing business teams to focus solely on functional modules while the platform handles dynamic publishing.

Stability and Observability

Stability is ensured through Grafana dashboards, UItron alert panels linked to DingTalk bots, and end‑to‑end monitoring that supports gray releases, automatic rollback, and alerting.

Release Process

Product creates a page, assembles modules, and assigns tasks.

Frontend and backend developers configure or develop modules, link them to data models, and notify QA.

Testing validates functionality; product approves and moves to pre‑release.

Approved changes are gray‑released with incremental traffic ramp‑up.

Real‑time monitoring observes business and technical metrics.

On anomaly detection, automatic downgrade or rollback occurs, followed by alert notifications.

Development Process – Mobile

Three scenarios are supported:

Static modules: developed traditionally and then configured for dynamic orchestration.

Dynamic modules: leverage Wukong DSL for on‑the‑fly UI rendering, cutting development time by more than half.

Component modules: reusable common components (grid, banner, waterfall) are abstracted into a component pool for instant consumption.

Development Process – Backend

Three usage patterns for the aggregation service:

Ready‑to‑use scenario: query and display logic already exist; developers only select required units.

Partial reuse: data source exists but display differs; developers add lightweight processing logic.

New integration: developers onboard a new data source and create processing logic, which later becomes reusable.

Efficiency Comparison

A visual comparison (image omitted) shows reduced cycle time and effort after adopting the Lego system.

Current Status and Outlook

The Lego system is already deployed on Haro’s home page, search, wallet, and other core scenes, handling tens of millions of DAU, hundreds of modules, and billions of renders daily. Future plans include expanding to more business cores, standardizing page construction, and further empowering product operations with dynamic orchestration.