How We Built a Low‑Code Page Builder for the 百瓶 App: Lessons & Architecture

Preface

Hello, I am the presenter Jun Er. Today I will share the practice of a low‑code page‑building platform at 百瓶. I will explain why we built this system and how we successfully completed it.

Our low‑code system serves our product 百瓶 APP , a professional whiskey community where users can share daily drinking experiences, buy and sell whiskey.

When meeting C‑end user needs, we found many e‑commerce promotion pages have low logical complexity and interaction but consume a lot of development resources. In backend management system development, similar pages need repeated development across scenarios, even with reusable components, leading to high cognitive load.

After researching existing solutions, we decided to adopt low‑code.

Pain Points of Traditional Mode

In traditional development, whether waterfall or agile, requirements go from operations or product to development, testing, and finally release.

Can we skip development, testing, and operations?

Mobile End

Developing mobile e‑commerce promotion pages requires fast delivery and low maintenance. Even with componentization (image, text, product list, coupon components), a single page can take one to three person‑days to develop and test.

Operational changes often require many backend configurations, yet they still cannot cover all maintenance scenarios.

Management Backend

Backend pages share similar patterns: data fetching, display, user input, validation, and submission. Even with reusable business components, the need for custom logic and configuration leads to high cognitive burden.

Platform Design Idea

We considered whether to modify an open‑source project or develop from scratch, choosing based on actual needs.

If the project focuses on presentation with few customizations, an open‑source low‑code project such as h5‑Dooring (mobile) or Ant Design Landing (PC) can be used.

Otherwise, self‑development is preferable.

Requirement Collection

Before self‑development, we prepared detailed requirements to avoid rework.

Our system mimics h5‑Dooring: a component library on the left, canvas in the middle, and property configuration on the right. We designed component libraries, configuration structures, data structures, and modular decomposition.

Determining Rendering Basis

As Pascal’s father said, Program = Data Structure + Algorithm . We start with data‑structure design.

After building a page, we can export either a DSL description file or page source code.

DSL description advantages:

Render‑independent : works with any renderer (Vue, React, etc.).

Easy deployment : can be published directly without building.

Second‑stage editing : description remains unchanged for further parsing.

Disadvantages:

Second‑development difficulty : custom components or logic are hard to insert.

Direct source code export eases second‑development but has drawbacks:

Higher DevOps cost : more effort for build‑deploy pipelines.

Legacy data handling : difficult when rendering framework changes.

Higher second‑edit cost : requires AST generation for edits.

We chose DSL description as the export base and solved custom component and logic injection via custom slot components and contextual logic calls.

BBCS Overview

After designing data structures, we split the system into major modules:

Editor

Free‑layout system

Behavior center

Data center

Renderer

The editor presents the component library, builds free layouts, configures components, describes virtual data, and orchestrates logic.

The renderer handles component rendering based on free layout, executes logic, and schedules data flow.

The data center stores runtime data; components read from and write to it.

The behavior center defines component actions; the editor’s logic orchestration generates behavior description files, which the renderer executes.

Overall workflow:

Editor fetches data structure or builds virtual data center description.

Define page logic and link atomic inputs/outputs to the virtual data center.

Build page structure, bind component fields to the data center, and attach events to behaviors.

Upload description file from mobile; export description from backend for further development.

Renderer consumes description file and renders the page.

How to Implement Free Layout

We use existing drag‑and‑drop libraries when suitable; otherwise we implement custom drag handling:

Make components in the library and canvas draggable.

Store component info during drag.

Canvas intercepts drag events and maintains position state.

Calculate drop position based on component type (container vs. non‑container) and event location.

Insert or move component according to calculated position.

Renderer recursively renders components, emphasizing the importance of context information for data binding.

Why a Data Center

The data center is a reactive object that provides data for component rendering and stores user input, acting as the source for behavior‑driven API calls.

It decouples static configuration from runtime state, allowing components to fetch data without knowing its origin.

What is the Behavior Center

The behavior center defines component actions. In the editor, behavior orchestration uses the AntV G6 engine; the output follows G6’s data structure.

At runtime, the renderer receives a behavior signal, locates the start node, executes logic (API request, prompt, comparison, etc.), and proceeds through linked nodes until completion.

Implementation and Practice

After roughly three person‑months of development, the mobile builder supports over 150 operational pages, covering 99% of needs, while the backend builder saves about 50% of development effort.

Drawbacks include the need for conventions and documentation, a steep initial development cost, and occasional cognitive gaps.

We recommend teams assess real value, ensure reliable personnel, allocate sufficient time, and have solid technical solutions before adopting.

Future Plans

We aim to expand template components and page templates to further reduce from‑scratch building costs, improve automation, and enrich the component library, moving from low‑code toward zero‑code and intelligent solutions.