How We Built a Custom Low‑Code Visual Editing Platform for Rapid Marketing Pages

1. Project Origin

In the summer of 2019 a brainstorming session generated the idea of a split‑screen editor: the left side shows a live preview, the right side fills data, and saving the data triggers a page update. A demo was built, but the project was postponed because an existing Blade template platform took priority.

Since 2020 the pandemic increased the volume of marketing activities. Existing Blade pages could only be customized as whole pages, which consumed a lot of development resources. The team revived the split‑screen concept and decided to build a more granular, composable, real‑time previewable template platform.

2. Requirements Clarification

2.1 Granularity of Customization

The platform is primarily used by operations staff, while developers build the components. Therefore each component should expose only a few parameters; all business logic stays inside the component implementation to keep learning and development costs low.

2.2 UI Requirements

Because the generated pages are compiled to to C, they must have a strong UI appearance and be written by developers. Simple back‑office or OA‑style components are acceptable, but generic components without custom UI are excluded.

2.3 Free Composition

All components occupy 100% width and can be reordered; nesting is unnecessary because the business targets mobile users.

2.4 Real‑time Preview

The previous Blade platform required publishing to a test or production environment to see changes, which was inefficient. The new platform must provide instant preview after each configuration change.

3. Technical Research

We evaluated existing low‑code solutions to avoid reinventing the wheel.

3.1 amis

Amis is a Baidu open‑source low‑code front‑end framework that uses JSON configuration. It targets B2B users, has a large number of configuration options, and a steep learning curve, making it unsuitable for our C‑end operators.

3.2 Luban H5

Luban H5 is a Vue 2.0 based drag‑and‑drop page builder that supports custom components and scripts. While it meets many functional needs, building complex component editors would be labor‑intensive.

3.3 pipeline‑page

pipeline‑page is an open‑source visual page builder on GitHub that separates editor, page, and backend. It uses JSON Schema to generate component property forms, solving many of Luban H5’s pain points. We adopted its architectural ideas but implemented a custom solution to fit our stack.

4. Technical Architecture

4.1 Front‑end

The front‑end is built on the D2Admin template, providing a simple admin UI with team and site management (future), page management, and component categories. The left pane lists components; clicking a component shows a floating detail panel. Adding a component displays it in the central preview area, while the right pane renders a form generated from the component’s JSON Schema. Example preview page: https://web.huajiao.com/jimu/3/index.html.

When a component is edited, the front‑end sends the component data to the back‑end and also posts a message via window.postMessage to the iframe preview. The preview renders the component dynamically, providing instant visual feedback without a full build.

4.2 Back‑end

The back‑end stores component data, page data, and component metadata. Upon a publish request it triggers a GitLab pipeline via the GitLab API to build and deploy the page. The server is built with NestJS, uses DTO validation, JWT authentication via passport‑jwt, and TypeORM for database access.

Key back‑end responsibilities:

Node framework based on NestJS for maintainability and extensibility.

Pipeline and DTO validation to replace verbose if‑else logic.

JWT‑based authentication with Nest route guards.

TypeORM for database connectivity.

4.3 Preview & Build

The preview implementation differs from pipeline‑page by avoiding a separate resource bundle. Instead we rely on GitLab CI/CD to compile and publish preview assets.

Component library structure mirrors a typical single‑page application. New components are added under components/xxx. Each component includes a Vue file (e.g., autoplay-video/index.vue) and a configuration file ( class.config.json) that defines the sub‑category.

Developers annotate component props with comments; a script yarn generate:schema converts these annotations into a JSON Schema file ( autoplay-video/index.schema.json) used by the front‑end to render the property form.

Local debugging is enabled by editing constants/devConfig.js to set componentList. After testing, changes are merged to master and a CI job runs node scripts/updateComponent.js to push component metadata to the server without affecting the normal development workflow.

components_update:</code><code>    image: registry.huajiao.com/gitlab-ci/dplt-core:0.1.5</code><code>    stage: components_update</code><code>    script:</code><code>        - node scripts/updateComponent.js</code><code>    only:</code><code>        changes:</code><code>            - src/js/components/**</code><code>    refs:</code><code>        - master</code><code>    except:</code><code>        - triggers

After publishing, the front‑end polls the GitLab pipeline status to show progress to the user.

{</code><code>