Understanding Low‑Code Implementation Principles: Front‑End Rendering, Back‑End Data Models, and Future Directions

Low‑code platforms rely on visual editing, which requires a declarative programming model; without visual editing a product cannot be considered low‑code.

The essential difference between low‑code products lies in their implementation principles. Understanding these principles reveals each platform's strengths and weaknesses.

What is low‑code? It is fundamentally a visual programming tool, where the indispensable feature is visual editing. Visual editing is possible only with declarative code, not with imperative code.

Declarative code describes the final result directly, while imperative code describes step‑by‑step procedures. For example, a red block can be created declaratively with HTML + CSS:

<div style="background:red; height:50px"></div>

or imperatively with the Canvas API:

const ctx = canvas.getContext('2d');
ctx.fillStyle = 'red';
const rectangle = new Path2D();
rectangle.rect(0, 0, 100, 100);
ctx.fill(rectangle);

Although both render the same visual result, the declarative version allows reverse‑engineering from the UI back to the source, which is essential for visual editors. Imperative code cannot be reverse‑engineered, making visual editing impossible.

Because all low‑code platforms must be declarative, they inevitably embed a domain‑specific language (DSL). Common declarative DSLs include HTML + CSS for UI, SQL for data queries, Kubernetes YAML for service deployment, and NGINX configuration for reverse proxy.

These declarative languages share advantages: easy to learn, support visual editing, easier performance optimization, and good portability. Their drawbacks are limited domain applicability, reduced flexibility, debugging difficulty, and strong dependence on the runtime environment.

From the front‑end perspective, the open‑source amis framework converts JSON into a custom React component tree, which is then rendered by React. Example JSON configuration:

{
  "type": "page",
  "title": "页面标题",
  "subTitle": "副标题",
  "body": {
    "type": "form",
    "title": "用户登录",
    "body": [
      {
        "type": "input-text",
        "name": "username",
        "label": "用户名"
      }
    ]
  }
}

is transformed into the following React component hierarchy:

<Page title="页面标题" subTitle="副标题">
  <Form title="用户登录">
    <InputText name="username" label="用户名" />
  </Form>
</Page>

Direct HTML + CSS can also be used, but it raises the entry barrier because users must understand HTML and CSS. JSON is preferred because it is easy to manipulate in JavaScript and supports bidirectional editing, unlike YAML which loses reference information when converted to JSON.

Back‑end low‑code must solve three problems: custom data storage, business‑logic execution, and workflow implementation. Five storage schemes are discussed:

Direct relational‑database tables (DDL generation). Example:

ALTER TABLE 'blog' ADD 'title' varchar(255) NULL;

Pros: direct external DB connection, high performance, familiar to developers. Cons: requires DDL privileges, DDL may lock tables, not all DBs support transactional DDL.

Document‑oriented databases (e.g., MongoDB). Data is stored in collections with meta‑information mapping fields to internal IDs.

Pros: simple implementation, good UX, widely used in zero‑code platforms. Cons: isolated data, limited SQL capabilities, MongoDB adoption is low in China.

Row‑instead‑of‑column (meta‑table) approach, exemplified by WordPress wp_postmeta :

CREATE TABLE wp_postmeta (
  meta_id bigint(20) unsigned NOT NULL auto_increment,
  post_id bigint(20) unsigned NOT NULL default '0',
  meta_key varchar(255) default NULL,
  meta_value longtext,
  PRIMARY KEY (meta_id),
  KEY post_id (post_id),
  KEY meta_key (meta_key)
) DEFAULT CHARSET=utf8;

Pros: simple, no DDL changes. Cons: poor query performance, cannot use advanced SQL features.

Meta‑information + wide table (pre‑allocated columns). Example meta table data with columns value0 … value4000 and a separate table_fields describing which column stores which logical field.

Pros: no DDL, works on SaaS. Cons: cannot support full SQL, high data‑leak risk, complex implementation.

Single‑file storage (Excel‑like). Data lives in a JSON file; front‑end handles filtering.

Pros: simple, low deployment cost. Cons: limited scalability, no row‑level permissions, no transaction support.

Business‑logic implementation options include:

Graphical programming (unsuitable for complex logic).

Fixed interaction behaviors (e.g., {"label":"弹框","type":"button","actionType":"dialog","dialog":{"title":"弹框","body":"这是个简单的弹框。"}} ).

Custom JavaScript (e.g., the JSONTraverse utility):

function JSONTraverse(json, mapper) {
  Object.keys(json).forEach(key => {
    const value = json[key];
    if (isPlainObject(value) || Array.isArray(value)) {
      JSONTraverse(value, mapper);
    } else {
      mapper(value, key, json);
    }
  });
}

While JavaScript offers flexibility, it cannot be visually edited, so it is not considered low‑code.

Workflow engines are typically graph‑based (BPMN‑like). A minimal flow is stored as a directed graph:

{
  "lines": [
    {"id":"d4ffdd0f6829","to":"4a055392d2e1","from":"e19408ecf7e3"},
    {"id":"79ccff84860d","to":"724cd2475bfe","from":"4a055392d2e1"}
  ],
  "nodes": [
    {"id":"e19408ecf7e3","type":"start","label":"开始"},
    {"id":"4a055392d2e1","type":"examine-and-approve-task","label":"审批节点"},
    {"id":"724cd2475bfe","type":"end","label":"结束"}
  ]
}

The engine determines the next node based on the current state and executes the associated action, handling approval rules, roll‑backs, and other edge cases.

Future trends suggest two directions: zero‑code platforms (high usability, low flexibility) and professional‑development‑oriented platforms (low usability, high flexibility). The author believes zero‑code will dominate in volume, while professional‑oriented solutions will remain niche for large enterprises.

In the author's own product 爱速搭 , the professional‑development path is chosen, leveraging the amis front‑end framework and a mix of the storage schemes described above.