Understanding Low‑Code Implementation Principles: Declarative Frontend, Backend Storage, and Workflow Engines

We have been exploring low‑code for many years, starting in 2015 with the front‑end rendering engine amis and later adding back‑end data‑model support in 2018; after surveying almost every product on the market we found that the essential difference between platforms lies in their implementation principles, and understanding these principles reveals the strengths and weaknesses of each low‑code solution.

What does “low‑code” actually mean? The indispensable feature of a low‑code product is visual editing, which implies a declarative programming model. Declarative code describes the desired result without specifying how to achieve it, whereas imperative code describes step‑by‑step instructions.

For example, drawing a red block declaratively can be done with simple HTML + CSS:

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

In contrast, the same visual can be produced 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);

Declarative code can be reverse‑engineered from the rendered result, while imperative code cannot, which makes visual editing feasible only for declarative languages. This leads to the conclusion that all low‑code platforms must rely on declarative DSLs such as HTML + CSS, SQL, Kubernetes YAML, or NGINX configuration.

These declarative languages share common advantages (easy to learn, support visual editing, easier performance optimization, and portability) and disadvantages (domain‑specific, limited flexibility, debugging difficulty, strong runtime dependence, and potential vendor lock‑in).

Front‑end implementation – interface rendering – The open‑source project amis converts JSON into a custom React component library, which then renders HTML. A typical amis page definition looks like:

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

which is transformed into the following React component tree:

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

JSON is chosen because it is easy to manipulate in JavaScript and supports bidirectional editing, unlike YAML which loses reference information when converted to JSON.

Back‑end storage solutions – Five major approaches are described:

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

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

Pros: high performance, direct external DB integration, familiar to developers. Cons: requires DDL permissions, can impact live performance, limited transactional DDL support, high implementation cost.

Document‑oriented databases (e.g., MongoDB). Example workflow: create a collection per custom table, assign a fileId to each field, store meta‑data separately.

Pros: simple implementation, good UX, widely used in zero‑code platforms. Cons: isolated data islands, limited SQL capabilities, limited adoption of MongoDB in large enterprises.

Row‑instead‑of‑column (meta‑table) pattern, 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 CHARACTER SET utf8 COLLATE utf8_general_ci;

Pros: no DDL changes, suitable for SaaS. Cons: poor query performance, cannot use full SQL features, security risks due to shared tenant data.

Meta‑information + wide table (pre‑allocated columns). Example meta‑data table and data table structures are shown in the article.

Pros: simple implementation, works with existing relational DBs. Cons: cannot support all SQL features, high risk of data leakage, complex indexing and consistency handling.

Single‑file storage (Excel‑like). Data lives in a JSON file and is filtered on the front‑end.

Pros: extremely simple deployment, tolerant to errors. Cons: limited scalability, no row‑level permissions, no transaction support.

Back‑end logic execution – Options include graphical logic (rarely effective), fixed CRUD actions, JavaScript custom scripts, and simplified DSL formulas for expression evaluation. The article also introduces an “execution tree” model that aggregates multiple API calls, similar to a BFF layer.

Workflow implementation – Most platforms adopt BPMN 2.0 for visual process design. The engine stores the workflow as a directed graph, e.g.:

{
  "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 strategies, roll‑backs, and parallel execution.

Future of low‑code platforms – Two directions are identified: zero‑code (high usability, low flexibility, suitable for many small customers) and professional‑developer‑oriented (low usability, high flexibility, targeting larger enterprises). The author believes the market will favor zero‑code solutions, especially “online‑Excel” style products, while professional‑oriented platforms will remain niche.

Conclusion – Low‑code is fundamentally declarative programming; its benefits and limitations stem from this nature. Front‑end UI is naturally declarative (HTML + CSS), while back‑end storage has multiple trade‑off‑laden approaches. Selecting a platform requires careful evaluation of these trade‑offs.

Author – Wu Duoyi, Baidu Intelligent Cloud Chief Architect, with over 14 years of experience, creator of the amis low‑code framework and lead of the “爱速搭” low‑code product.