我們在低代碼領域探索了很多年，從2015 開始研發(fā)低代碼前端渲染（amis），從 2018 年開研發(fā)后端低代碼數(shù)據(jù)模型，發(fā)布了愛速搭低代碼平臺，這些年調研過了幾乎所有市面上的相關技術和產品，發(fā)現(xiàn)雖然每家產品細節(jié)都不太一樣，但在底層技術上卻只有少數(shù)幾種方案，因此我們認為不同產品間的最大區(qū)別是實現(xiàn)原理，了解這些實現(xiàn)原理就能知道各個低代碼平臺的優(yōu)缺點，所以本文將會介紹目前已知的各種低代碼實現(xiàn)方案，從實現(xiàn)原理角度看低代碼。

— 1 —

本文里的「低代碼」指的是什么？

在討論各個低代碼方案前，首先要明確「低代碼」究竟是什么？

這個問題不好直接回答，因為低代碼是非常寬泛的概念，有很多產品都聲稱自己的低代碼，但我們很容易反過來回答另一個問題：「什么是低代碼產品唯一不可缺少的功能？」

我認為這個功能是可視化編輯，因為非可視化編輯就是代碼編輯，而只有代碼編輯的產品不會被認為是低代碼，因此可視化編輯是低代碼的必要條件，低代碼其實還有另一個更清晰的叫法是可視化編程。

既然可視化編輯是低代碼的必要條件，那從實現(xiàn)角度看，實現(xiàn)可視化編輯有什么必要條件？

我認為可視化編輯的必要條件是「聲明式」代碼，因為可視化編輯器只支持「聲明式」代碼。

解釋一下什么是「聲明式」，除了聲明式之外還有另一種代碼模式是「命令式」，我們分別舉兩個例子，如果想繪制一個紅色區(qū)塊，用「聲明式」來實現(xiàn)，可以使用 HTML CSS，類似下面的方法：

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

而換成用「命令式」來實現(xiàn)，可以使用 Canvas API，類似下面的方法：

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

雖然最終展現(xiàn)效果是一樣的，但這兩種代碼在實現(xiàn)思路上有本質區(qū)別：

• 「聲明式」直接描述最終效果，不關心如何實現(xiàn)。
• 「命令式」關注如何實現(xiàn)，明確怎么一步步達到這個效果。

從可視化編輯器的角度看，它們的最大區(qū)別是：

• 「聲明式」可以直接從展現(xiàn)結果反向推導回源碼
• 「命令式」無法做到反向推導

反向推導是編輯器必備功能，比如編輯器里的常見操作是點選這個紅色區(qū)塊，然后修改它的顏色，在這兩種代碼中如何實現(xiàn)？

如果是「聲明式」的 HTML CSS，可以直接改 style 的 background 值，而基于 Canvas 的命令式代碼則無法實現(xiàn)這個功能，因為無法從展現(xiàn)找到實現(xiàn)它的代碼，命令式代碼實現(xiàn)同樣效果的可能路徑是無數(shù)的，除了前面的示例，下面這段代碼也可以實現(xiàn)一樣的效果：

const ctx = canvas.getContext('2d');ctx.beginPath();ctx.moveTo(0, 0);ctx.lineTo(50, 0);ctx.strokeStyle = '#ff0000';ctx.lineWidth = 100;ctx.stroke();

甚至有可能這個顏色是多個字符串加隨機數(shù)拼接而成，即便通過靜態(tài)分析也找不到來源，從而無法實現(xiàn)可視化修改。

「命令式」代碼無法實現(xiàn)可視化編輯，而可視化編輯是低代碼唯一不可少的功能，所以我們可以得到結論：所有低代碼平臺必然只能采用「聲明式」代碼，這也是為什么所有低代碼平臺都會有內置的「DSL」。

既然低代碼都是聲明式，那我們可以通過分析其它「聲明式」語言來了解低代碼的優(yōu)缺點，其實在專業(yè)研發(fā)里，聲明式語言在部分領域已經是主流了：

• HTML CSS 是一種頁面展現(xiàn)的 DSL
• SQL 是一種數(shù)據(jù)查詢及處理的 DSL
• K8S 的 YAML 是一種服務部署的 DSL
• NGINX conf 是一種反向代理的 DSL

上面這些方案目前都是主流，但它們早期并不被看好，比如十幾年前還曾經爭論過到底是用 B/S 還是 C/S 架構，CSS 2 的功能主要是面向圖文排版，并不適合用來構建應用界面。

SQL 最開始也不被看好，下面引用《硅谷簡史》這本書里的部分文字：

1970年，IBM研究員特德·科德（Ted Codd）發(fā)表了一篇里程碑式的論文，《大型數(shù)據(jù)庫的系統(tǒng)模型》，介紹了關系數(shù)據(jù)庫理論。

當時大多數(shù)人認為關系數(shù)據(jù)庫沒有商業(yè)價值，因其速度太慢，不能滿足大規(guī)模數(shù)據(jù)處理或者大量用戶存取數(shù)據(jù)，雖然關系數(shù)據(jù)庫理論上很漂亮而且易于使用，但它的速度太慢。

上面兩段其實說的是 Oracle 的發(fā)家故事，可以看到當時關系型數(shù)據(jù)庫并不被看好，因為大家都覺得慢，這點很好理解，數(shù)據(jù)庫在查詢前還得先解析 SQL語法、估算各種查詢的代價、生成執(zhí)行計劃，存儲也只能使用通用的數(shù)據(jù)結構，沒法根據(jù)不同業(yè)務進行定制。

綜合來看這些「聲明式」語言有以下優(yōu)點：

• 容易上手，因為描述的是結果，語法可以做得簡單，非研發(fā)也能快速上手 HTML 及 SQL。
• 支持可視化編輯，微軟的 HTML 可視化編輯 FrontPage 在 1995 年就有了，現(xiàn)在各種 BI 軟件可以認為是 SQL 的可視化編輯。
• 容易優(yōu)化性能，無論是瀏覽器還是數(shù)據(jù)庫都在不斷優(yōu)化，比如可以自動改成并行執(zhí)行，這是命令式語言無法自動實現(xiàn)的。
• 容易移植，容易向下兼容，現(xiàn)在的瀏覽器能輕松渲染 30 年前的 HTML，而現(xiàn)在的編譯器沒法編譯 30 年前的瀏覽器引擎代碼。

而這些語言的缺點是：

1、只適合特定領域，命令式的語言比如 JavaScript 可以用在各種領域，但 HTML CSS 只適合渲染文檔及界面，SQL 只適合做查詢，所有這些語言都。

2、靈活性差，比如 SQL 雖然內置了很多函數(shù)，但想只靠它實現(xiàn)業(yè)務是遠遠不夠的，有些數(shù)據(jù)庫還提供了用戶自定義函數(shù)功能（UDF），通過代碼來擴展。

3、調試困難，遇到問題時如缺乏工具會難以排查，如果你在Firefox出現(xiàn)前開發(fā)過頁面就會知道，由于IE6沒有開發(fā)工具，編寫復雜頁面體驗很差，遇到問題要看很久代碼才發(fā)現(xiàn)是某個標簽沒閉合或者 CSS 類名寫錯了。

4、強依賴運行環(huán)境，因為聲明式只描述結果而不關注實現(xiàn)，因此強依賴運行環(huán)境，但這也帶來了以下問題：

1. 功能取決于運行環(huán)境，比如瀏覽器對 CSS 的支持程度決定某個屬性是否有人用，雖然出現(xiàn)了CSS Houdini 提案，但 Firefox 和 Safari 都不支持，而且上手成本太高，預計以后也不會流行。
2. 性能取決于運行環(huán)境，比如同一個 SQL 在不同數(shù)據(jù)庫下性能有很大區(qū)別。
3. 對使用者是黑盒，使用者難以知道最終實現(xiàn)，就像很少人知道數(shù)據(jù)庫及瀏覽器的實現(xiàn)細節(jié)，完全當成黑盒來使用，一旦遇到性能問題就不知所措。
4. 技術鎖定，因為即便是最開放的 HTML 也無法解決，很多年前許多網站只支持 IE，現(xiàn)在又變成了只支持 Chrome，微軟和 Opera 在掙扎了很多年后也干脆直接轉向用 Chromium。同樣的即便有 SQL 標準，現(xiàn)在用的 Oracle/SQL Server 應用也沒法輕松遷移到 Postgres/MySQL 上。低代碼行業(yè)未來也一樣，即便出了標準也解決不了鎖定問題，更有可能是像小程序標準那樣發(fā)展緩慢，功能遠落后于微信。

因為低代碼就是一種聲明式編程，所以這些「聲明式」優(yōu)缺點，其實就是低代碼的優(yōu)缺點，了解聲明式的歷史及現(xiàn)狀就能更好理解低代碼，因為：

• 低代碼的各種優(yōu)點是「聲明式」所帶來的。
• 低代碼被質疑的各種缺點也是「聲明式」所導致的。

— 2 —

低代碼的實現(xiàn)方案

說完了聲明式，我們就對低代碼有了全面認識，接下來進入正題，開始介紹已知的各種低代碼實現(xiàn)原理，將會分為前端和后端兩部分。

— 3 —

生成代碼的方案算不算低代碼？

在討論各種方案前，有一種方案比較特別，它雖然也有配置規(guī)范或 DSL，甚至有可視化編輯，但最終應用運行是通過生成代碼的方式實現(xiàn)的，不依賴依賴運行環(huán)境。

這個方案最大的優(yōu)點是可以和專業(yè)開發(fā)整合，因此靈活性強、可以使用原有的開發(fā)流程，本質上和專業(yè)開發(fā)一樣。

但也有如下缺點：

• 強依賴研發(fā)，無法做到給非研發(fā)使用，因為后續(xù)代碼需要編譯上線。
• 無法持續(xù)可視化編輯，因為代碼無法可視化編輯，生成代碼后只要有修改就沒法再反向還原成低代碼的形式，后續(xù)只能代碼編輯。
• 難以實現(xiàn)完全用低代碼開發(fā)應用，因為不能生成太復雜的代碼，使得這種方案一般不包括交互行為，通常是只有前端界面支持可視化編輯。
• 無法做到向下兼容，因為生成的那一瞬間代碼依賴的框架版本就固定了，目前還沒見過哪款前后前端框架做過到完全向下兼容。

因此我認為生成代碼的方案不算真正的低代碼，本質上它還是一種開發(fā)輔助方式，一種高級點的腳手架工具，和大部分IDE的生成樣板代碼能力一樣，使用這種方案無法做到持續(xù)可視化開發(fā)，我還沒見過有人將 HTML CSS 編譯成 C 代碼后二次開發(fā)。

— 4 —

前端代碼實現(xiàn)原理 – 界面渲染

前面提到前端 HTML CSS 可以看成一種描述界面的低代碼 DSL，因此前端界面實現(xiàn)低代碼會比較容易，只需要對 HTML CSS 進行更進一步封裝，這里以我們的開源項目 amis 為例進行介紹。

amis 核心原理是將 JSON 轉成自研的 React 組件庫，然后使用 React 進行渲染。

比如下面這段 JSON：

{ "type": "page", "title": "頁面標題", "subTitle": "副標題", "body": { "type": "form", "title": "用戶登錄", "body": [ { "type": "input-text", "name": "username", "label": "用戶名" } ] }}

可以理解 amis 原理就是轉成了下面這樣的 React 組件樹，最終由各個 React 組件庫渲染 HTML：

<Page title="頁面標題" subTitle="副標題"> <Form title="用戶登錄"> <InputText name="username" label="用戶名" /> </Form></Page>

雖然也有低代碼平臺直接使用 HTML CSS 來實現(xiàn)更靈活的界面控制，但這樣做會導致用起來復雜度高，因為通常需要多層嵌套 HTML 才能實現(xiàn)一個組件，使用者還必須熟悉 HTML 及 CSS，上手門檻過高，因此大部分低代碼平臺都是類似 amis 那樣使用 JSON 進行簡化。

這里有個小問題，為什么大家?guī)缀跞际褂?json？我覺得有兩方面原因：

1. 低代碼平臺編輯器幾乎都是基于 Web 實現(xiàn)，JavaScript 可以方便操作 JSON。
2. JSON 可以支持雙向編輯，它的讀取和寫入是一一對應的。

第二點怎么理解？可以對比一下 YAML，它有引用功能，導致了不好實現(xiàn)雙向編輯，比如下面 YAML 示例：

paths: root_path: &root val: /path/to/root/ patha: &a root_path: *root

轉成了對應的 JSON 數(shù)據(jù)后，就變成了：

{ "paths": { "root_path": { "val": "/path/to/root/" }, "patha": { "root_path": { "val": "/path/to/root/" } } }}

可以看到之前的引用關系沒了，而是復制出了一部分，如果直接基于這個數(shù)據(jù)進行可視化編輯，編輯器在修改的時候就只會改一處，也沒法再還原成之前的 YAML 了，要想實現(xiàn) YAML 可視化編輯就不能先轉成 JSON，而是要對 YAML 解析后的樹形結構進行操作，前端界面實現(xiàn)成本很高，因此目前還沒見過 YAML 的可視化編輯器。

但 JSON 的優(yōu)點就是它的缺點，因為它的用途是數(shù)據(jù)交換而不是人工編寫，導致基于 JSON 構建 DSL 不方便編輯，會有以下 3 個問題：

• 不支持注釋
• 不支持多行字符串
• 語法過于嚴格，比如不支持單引號，不能在最后多寫一個逗號

其中我們對這個注釋問題進行了特殊支持，開發(fā)了帶注釋的 JSON 解析，存儲的時候將注釋內嵌到一個特殊的字段中，在代碼顯示的時候將它提取出來變成注釋。

另外許多低代碼平臺會將這個 JSON 配置隱藏，只提供界面編輯，但在 amis 可視化編輯器里提供了直接修改 JSON 的功能，因為對于熟悉的開發(fā)者，直接編寫 JSON 要比在屬性面板里找半天效率高，還可以直接將 amis 文檔中的示例粘貼進來快速創(chuàng)建。

amis 開始編輯器里 JSON 編輯模式

前面提到聲明式容易向下兼容，amis 自己就是最好的例子，在 amis 誕生的 2015 年前端框架和現(xiàn)在有大量區(qū)別：

• Vue 還是 1，現(xiàn)在已經到 3 了，不向下兼容。
• Angular 還是 1，現(xiàn)在已經 13 了，不向下兼容。
• React 雖然整體用法沒變，但有大量細節(jié)不向下兼容，加上 hooks 推出后，許多第三方庫改成了 hooks 版本，導致舊的類組件形式沒法直接使用。

而 amis 早期的界面配置現(xiàn)在還能繼續(xù)使用，不受框架升級影響。

— 5 —

交互邏輯的實現(xiàn)

前面說到前端界面低代碼是比較容易，但交互及邏輯處理卻很難低代碼話，目前常見有三種方案：

• 使用圖形化編程
• 固化交互行為
• 使用 JavaScript

先說第一種圖形化編程，這是非常自然的想法，既然低代碼的關鍵是可視化，那直接使用圖形化的方式編程不就行了？

但我們發(fā)現(xiàn)這么做局限性很大，本質的原因是「代碼無法可視化」，這點在 35 年前沒有銀彈的論文里就提到了。

為什么代碼無法可視化？首先想一想，可視化的前提條件是什么？

答案是需要具備空間形體特征，可視化只能用來展現(xiàn)二維及三維的物體，因為一維沒什么意義，四維及以上大部人無法理解，所以如果一個事物沒有形體特征，它就沒法被可視化。

舉個例子，下面是一段 amis中 代碼，作用是遍歷 JSON 并調用外部函數(shù)進行處理：

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); } });}

雖然只有 10 行代碼，卻包含了循環(huán)、調用函數(shù)、類型檢測、分支判斷、或操作符、遞歸調用、參數(shù)是函數(shù)這些抽象概念，這些概念在現(xiàn)實中都找不到形體的，你可以嘗試一下用圖形來表示這段代碼，然后給周圍人看看，我相信任何圖形化的嘗試都會比原本這段代碼更難懂，因為你需要先通過不同圖形來區(qū)分上面的各種概念，其他人得先熟悉這些圖形符號才能看懂，理解成本反而更高了。

代碼的這些抽象思維難以像積木一樣進行拼接，積木拼接這種方式只適合用來實現(xiàn)簡單的邏輯，比如 Scratch。

Scratch

而前面圖形化是低代碼唯一不可少的功能，這就使得低代碼不適合做復雜的抽象邏輯處理，這是圖形化缺陷決定的，因此在復雜邏輯處理方面低代碼永遠無法徹底取代專業(yè)代碼開發(fā)。

但如果是面向特定領域，低代碼平臺可以先將這個領域難以圖形化的算法預置好，讓使用者只需做簡單的處理，比如在 Blender 中將 PBR 算法封裝了，使用的時候只需要調整參數(shù)就行。

Blender 中的材質節(jié)點編輯

如果真要用節(jié)點實現(xiàn)這個算法會非常復雜，大概長這樣：

在復雜邏輯下，圖形中的連線反而變成了視覺干擾，比如下面的例子：

來自 UE4 Blueprints From Hell 里的一張圖

想象一下假設客戶做出了上面這個圖的復雜邏輯，然后找你排查問題，而客戶的程序是部署在內網的，沒法導出，只能通過微信拍屏幕給你看……

因此我認為圖形化不適合用來實現(xiàn)業(yè)務邏輯，只適合用來做更高層次流程控制，比如審批流，審批流是現(xiàn)實真實存在的，沒有復雜的抽象邏輯，因此適合圖形化。

在愛速搭中，我們除了實現(xiàn)流程功能，還實現(xiàn)了樹形結構的 API 編排功能，它本質上是模仿代碼結構，將會在后面進行介紹。

說完了圖形化編程，接下來談第二種方案：固化交互行為，這是不少低代碼平臺的做法，我們還是以 amis 為例進行介紹。

amis 將常用的交互行為固化并做成了配置，比如彈框是下面的配置：

{ "label": "彈框", "type": "button", "actionType": "dialog", "dialog": { "title": "彈框", "body": "這是個簡單的彈框。" }}

除了彈框之外還有發(fā)起請求、打開鏈接、刷新其它組件等，使用固化交互行為有下面兩個優(yōu)點：

• 可以可視化編輯
• 整合度高，比如彈框里可以繼續(xù)使用 amis 配置，通過嵌套實現(xiàn)復雜的交互邏輯

但這個方案最大的缺點是靈活性受限，只能使用 amis 內置的行為。

要實現(xiàn)更靈活的控制，還是得支持第三個方案：JavaScript，目前有的低代碼平臺只在界面編輯提供可視化編輯，一旦涉及到交互就得寫 JavaScript，這和 30 年前的 C Builder 本質上是一樣的：

RDA Studio 11 的界面編輯

但第三個方案的最大缺點就是無法可視化編輯，因此不算是低代碼。

— 6 —

后端低代碼的方案

前端討論完了，接下來是后端部分，后端低代碼需要解決以下三個問題：

1、如何自定義數(shù)據(jù)存儲？

低代碼平臺需要支持用戶存儲自定義數(shù)據(jù)，因為每個應用所需的字段是不一樣的。

自定義數(shù)據(jù)存儲是后端低代碼最重要的功能，使用什么方案將直接影響這個產品的適用范圍，目前我們已知有 5 種方案，每種都有自己的優(yōu)缺點。

存儲的實現(xiàn)方案 1：直接使用關系型數(shù)據(jù)庫

這個方案的原理是將數(shù)據(jù)模型的可視化操作轉成數(shù)據(jù)庫 DDL，比如添加了一個字段，系統(tǒng)會自動生成表結構變更語句：

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

這個方案的優(yōu)點是：

• 所有方案里唯一支持直連外部數(shù)據(jù)庫，可以對接已有系統(tǒng)。
• 性能高和靈活性強，因為可以使用高級 SQL。
• 開發(fā)人員容易理解，因為和專業(yè)開發(fā)是一樣的。

但它的缺點是：

• 需要賬號有創(chuàng)建用戶及 DDL權限，如果有安全漏洞會造成嚴重后果，有些公司內部線上帳號沒有這個權限，導致無法實現(xiàn)自動化變更。
• DDL 有很多問題無解，比如在有數(shù)據(jù)的情況下，就不能再添加一個沒有默認值的非 NULL 字段。
• DDL 執(zhí)行時會影響線上性能，比如 MySQL 5.6 之前的版本在一個大數(shù)據(jù)量的表中添加索引字段會鎖整個表的寫入（但也有數(shù)據(jù)庫不受影響，比如 TiDB、OceanBase 支持在線表結構變更，不會阻塞讀寫）。
• 部分數(shù)據(jù)庫不支持 DDL 事務，比如 MySQL 8 之前的版本，導致一旦在執(zhí)行過程中出錯將無法恢復。
• 實現(xiàn)成本較高，需要實現(xiàn)「動態(tài)實體」功能，如果要支持不同數(shù)據(jù)庫還得支持各種方言。

盡管這個方案有很多缺點，但它的優(yōu)點也很突出，因此愛速搭里實現(xiàn)了這個方案，因為我們覺得能連已有數(shù)據(jù)庫是非常重要的，其它方案都只適合用來做新項目，這個方案使得可以逐步將已有項目低代碼化，不需要做數(shù)據(jù)遷移。

愛速搭里的數(shù)據(jù)庫模型

實現(xiàn)這個方案的關鍵是「動態(tài)實體」，在專業(yè)開發(fā)中實體（Entity）定義都是靜態(tài)的，以 Java 為例，它從 2006 年開始就有專門的 JPA 規(guī)范，但這個規(guī)范是定義基于 Java 代碼注解，使得需要經過編譯才能使用，畢竟它的定位是面向專業(yè)開發(fā)，只有寫在代碼里才能支持代碼提示，提升開發(fā)體驗。

而低代碼平臺中需要將這個實體定義抽象成配置，在運行時動態(tài)生成實體，如果使用 JPA 就需要生成 Java 代碼后進行編譯，這很容易出錯，不太適合低代碼平臺，所以使用這個方案需要實現(xiàn)「動態(tài)實體」功能，是整個方案最大難點。

存儲的實現(xiàn)方案 2：使用文檔型數(shù)據(jù)庫

文檔型數(shù)據(jù)庫不需要預先定義表結構，因此它很適合用來存儲用戶自定義數(shù)據(jù)，這個方案實現(xiàn)起來比較簡單，以 MongoDB 為例，可以這樣做：

1. 用戶創(chuàng)建一個自定義表的時候，系統(tǒng)就自動創(chuàng)建一個 collection，所有這個表的數(shù)據(jù)都存在這個 collection 里。
2. 用戶新增字段的時候，就隨機分配一個 fileId，后續(xù)對這個字段的操作都自動映射到這個 fileId 上，用 fileId 的好處是用戶重命名字段后還能查找之前的數(shù)據(jù)，因為所有數(shù)據(jù)查詢底層都基于這個 fileId。
3. 查詢的時候先找到對應的 collection，再通過 meta 信息查詢字段對應的 fileId，使用這個 fileId 來獲取數(shù)據(jù)。

這個方案的優(yōu)點是實現(xiàn)簡單，用戶體驗可以做得更好，是目前大部分零代碼平臺的選擇，使用這個方案的產品也很好識別，只要看一下它的私有部署文檔，如果有要求裝 MongoDB 就肯定是。

但這個方案也有顯著缺點：

• 無法支持外部數(shù)據(jù)庫，數(shù)據(jù)是孤島，外部數(shù)據(jù)接入只能通過導入的方式。
• MongoDB 在國內發(fā)展緩慢，接受度依然很低，目前還沒聽說有哪家大公司里最重要的數(shù)據(jù)存在 MongoDB 里，一方面有歷史原因，另一方面不少數(shù)據(jù)庫都開始支持 JSON 字段，已經能取代大部分必須用 MongoDB 的場景了。
• 不支持高級 SQL 查詢。

你可能會問，現(xiàn)在 MySQL、Postgres 等數(shù)據(jù)庫都支持 JSON 字段類型了，是否可以用這個字段來實現(xiàn)低代碼？

答案是不太行，只適合數(shù)據(jù)量不大的場景，雖然 JSON 字段可以用來存用戶自定義數(shù)據(jù)，但無法創(chuàng)建字段索引，比如在 MySQL 要想給 JSON 創(chuàng)建索引，還是得創(chuàng)建一個特殊的字段，這又需要 DDL 權限了，沒有索引會導致這個方案無法支持大量數(shù)據(jù)查詢。

在愛速搭中我們也實現(xiàn)這個方案，目前是基于 MySQL JSON 字段，后續(xù)可能也會支持存儲使用 MongoDB，目前它的使用場景是流程執(zhí)行過程中的數(shù)據(jù)存儲，因此數(shù)據(jù)量不會很大，我們希望流程功能用起來可以更簡單些。

它的最大特點是界面編輯和數(shù)據(jù)存儲是統(tǒng)一的，當你拖入文本框到頁面后就會自動創(chuàng)建對應的字段，不需要先創(chuàng)建數(shù)據(jù)模型再創(chuàng)建界面，因此用起來更簡單。

愛速搭里的表單模型

存儲的實現(xiàn)方案 3：使用行代替列

這是很多可擴展平臺里使用的技術，比較典型的是 WordPress，它的擴展性很強，裝個擴展就能變成電商網站。而整個 WordPress 只有 12 個表，它是怎么做到的？方法是靠各種 meta 表，比如用于擴展文章的 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;

其中的關鍵就是 meta_key 和 meta_value 這兩個字段，相當于將數(shù)據(jù)庫當 KV 存儲用了，因此可以任意擴展字段名及值。

這個方案的優(yōu)點是實現(xiàn)簡單，但缺點也很明顯：

• 查詢性能低，如果有 10 個字段就要查 10 行。
• 無法支持 SQL 高級查詢，因為數(shù)據(jù)是按行存的。

這個方案主要用于成熟項目的擴展，比如在 CRM 產品中允許用戶擴展字段，但因為性能較低，并不適合通用低代碼平臺。

存儲的實現(xiàn)方案 4：元信息 寬表

早期數(shù)據(jù)庫不支持 JSON 字段的時候，有些開發(fā)者會預留幾個列來給用戶擴展自定義屬性，比如在表里加上 ext1、ext2、ext3 字段，讓用戶可以存 3 個定制數(shù)據(jù)，基于這個原理我們可以進一步擴展，通過預留大量列來實現(xiàn)應用自定義存儲。

這個方案最早出現(xiàn)在 force.com，具體細節(jié)可以閱讀它架構說明文檔[1]。

實現(xiàn)它有兩個關鍵點：元數(shù)據(jù)、預留列，這里簡單說明一下原理，首先系統(tǒng)預先創(chuàng)建一個 500 列的表，比如就叫 data：

tenant_id	table_id	uuid	value0	value1	……	value 4000

也可以創(chuàng)建更多，但注意有的數(shù)據(jù)庫對列的數(shù)量有限制，比如 MySQL 最多是 4096 列。

上面的 data 表里主要有 4 類字段：

• tenant_id 是租戶 id，用于隔離不同租戶
• table_id 是自定義表的 id
• uuid 是具體這一行數(shù)據(jù)的 id
• 后面的 value0 到 value500 都是預留的列，用于存儲實際數(shù)據(jù)，一般使用變長字符串類型

當用戶給這個表新增一個字段的時候，怎么知道這個字段放哪？這就需要另一個用于描述字段信息的元數(shù)據(jù)表，比如增加一個「標題」字段時，使用另一個 table_fields 表來描述這個字段的信息，示例如下：

tenant_id	table_id	field_id	value_index	name	type
1	1	0	0	標題	string

在這個 table_fields 表里：

• tenant_id 和 table_id 和前面一樣。
• field_id 對應的是給這個「標題」字段分配的 id。
• value_index 對應前面那個 data 表里預覽列的位置，比如這個值是 0，就意味著 value0 列被分配給了這個「標題」字段。
• name 用來存名稱，type 用來標識類型，這樣查詢和寫入數(shù)據(jù)的時候，首先從這里查詢 value_index 是什么，然后再去前面那個預留列的表中查詢對應列的值。

最終在實際查詢的時候需要根據(jù)元數(shù)據(jù)表做一下轉換，比如 select 標題 from blog 要轉成 select value0 from data where tenal_id = 1 and table_id = 1。

要完全實現(xiàn)這個方案還有很多細節(jié)問題得解決，由于篇幅原因這里不詳細介紹，感興趣可以閱讀前面提到的 force.com 技術白皮書，這里列舉其中幾個問題：

• 因為存儲只能是字符串，所以對于日期、數(shù)字等其他類型，因此讀取的時候需要根據(jù)類型使用數(shù)據(jù)庫里的函數(shù)進行轉換，比如 STR_TO_DATE。
• 需要單獨處理唯一性功能，因為這個數(shù)據(jù)表是所有租戶共用的，沒法設置表級別的唯一性索引，這時就需要新建一個表來單獨做，壞處是數(shù)據(jù)多份容易產生不一致，需要在所有更新操作都加事務。
• 需要單獨處理索引功能，同樣是因為字段是字符串，因此沒法直接在 data 表里加索引，如果數(shù)據(jù)存儲的是數(shù)字，排序就是錯的，為了解決這個問題需要另外創(chuàng)建一個一個包含常見字段的索引表，數(shù)據(jù)更新的時候。
• 自增字段需要自己實現(xiàn)。
• 元數(shù)據(jù)信息需要緩存，不然每次查詢前都需要先查詢元數(shù)據(jù)信息，然后再去查詢真正的數(shù)據(jù)。

這個方案比前面幾個方案的優(yōu)點是：

• 比起第一種原生數(shù)據(jù)庫表方案，它不需要 DDL 操作，不容易出問題，跟適合 SaaS 產品。
• 比起第二種文檔型數(shù)據(jù)庫方案，它的存儲使用更為成熟的關系型數(shù)據(jù)庫，相關的運維工具多。
• 比起第三種行代替列方案，它的查詢性能好，因為是讀取一行數(shù)據(jù)。

但它也有許多缺點：

• 無法支持 SQL 所有功能，比如 force.com 的 SOQL 無法 select *、沒有視圖、不支持寫入和更新數(shù)據(jù)，通過這個特點就能識別出使用這個方案的產品，這類產品雖然看起來很像在用傳統(tǒng)數(shù)據(jù)庫，也支持使用 SQL，但這個 SQL 一定是受限的。
• 數(shù)據(jù)泄露風險高，因為所有租戶的數(shù)據(jù)都存在一張表里，而數(shù)據(jù)庫都不支持行級別權限的賬號，所以意味著所有租戶其實共享一個數(shù)據(jù)庫賬號，只要有某個功能的查詢漏了加租戶過濾就能查到所有租戶數(shù)據(jù)。相比之下前面提到的原生表及文檔型數(shù)據(jù)庫方案都能直接使用數(shù)據(jù)庫自帶的賬號進行有效隔離。
• 一些數(shù)據(jù)庫高級字段難以支持，比如坐標數(shù)據(jù)、二進制類型等，只能用單獨的表存，導致了查詢開銷。
• 整體實現(xiàn)成本高，其中很多細節(jié)需要處理好，比如保證數(shù)據(jù)一致性，因為為了實現(xiàn)唯一性、索引等功能需要拷貝數(shù)據(jù)，更新的時候要同時更新。

愛速搭中沒有實現(xiàn)這個方案，我們曾經考慮過但后來放棄了，我認為這個方案雖然很適合 SaaS 類的低代碼產品，但它的用戶定位比較尷尬，一方面是有一定復雜度導致不能做到零代碼平臺那樣的易用性，另一方面是有不少限制導致專業(yè)研發(fā)不喜歡，所以最終是兩邊都不討好，這種產品想做成需要依賴廣泛使用的平臺。

因此 Salesforce 才能做成，而國內類似情況我能想到的唯一成功案例是微信小程序，盡管有很多限制，但因為微信廣泛使用，所以才成功了，如果是一個獨立的小程序平臺肯定沒人用。

這里說一段小歷史，在十幾年前，當時云計算領域最先推出的是谷歌 2008 年發(fā)布的 App Engine，這是谷歌的第一個云產品，而當時類似 AWS EC2 那樣的虛機產品國內都還沒有，畢竟 KVM 也才剛發(fā)布。

如果你當時問云計算的專家，云計算的未來是 App Engine 還是虛擬機，我聽到不少專家的回答是 App Engine，因為這看起來更有前景，你只需要寫代碼，不用操心運維，平臺會自動水平擴展，這才是云該有的樣子，當時國內不少公司都推出了類似產品。

但 13 年后的今天，國內 App Engine 平臺幾乎都關閉了，而虛機不但是主流，還更進一步出現(xiàn)了物理機產品。這個元信息方案給我的感覺和當年 App Engine 很像，看上去能完成增刪改查的簡單應用，但如果深入就發(fā)現(xiàn)缺少很多功高級功能，導致兩邊不討好：

• 技術薄弱的開發(fā)者不會用，比如因為 App Engine 是分布式部署，導致上傳文件不能放本地，必須改成對象存儲，所以沒法直接用 WordPress 沒法用，對于小站長來說還不如用虛擬主機。
• 對于有技術實力的開發(fā)者，又會覺得平臺能力受限，不利于自己后續(xù)發(fā)展，比如谷歌的 App Engine 直到 2019 年才支持 WebSocket。

整體而言我不看好這個方案在國內的發(fā)展。

存儲的實現(xiàn)方案 5：使用單文件

這個方案目前只在「仿 Excel」的零代碼平臺中見過，它和 Excel 類似，數(shù)據(jù)全都放一個文件里，查詢過濾完全靠前端，優(yōu)點是：

• 實現(xiàn)簡單，部署成本低，因為表的存儲就是單文件。
• 容錯性強，數(shù)據(jù)類型都是靠前端處理的，不會出現(xiàn)存數(shù)據(jù)庫導致。

缺點是：

• 如果要支持行列級別權限校驗，還得在后端實現(xiàn)一遍過濾，而每次都加載一個巨大的 JSON 文件對服務器內存有較高要求。
• 難以支持事務操作，尤其是支持行級別的操作。
• 目前看十萬級別數(shù)據(jù)處理可以只靠前端，但再大量的數(shù)據(jù)就不合適了，一次性加載太多對帶寬和瀏覽器內存要求比較高。
• 只能當成 Excel 的替代品，數(shù)據(jù)是孤島，不能直連外部數(shù)據(jù)庫。

這個方案比較特殊，主要工作量在前端，有大量細節(jié)體驗優(yōu)化，在愛速搭中沒實現(xiàn)，后續(xù)可能會考慮。

2、后端業(yè)務邏輯的實現(xiàn)

說完了存儲，接下來是第二個問題：如何實現(xiàn)后端業(yè)務邏輯？

前面提到過代碼難以圖形化，這在后端也是一樣的，因此大概有這幾種方案：

• 邏輯圖形化，這個目前看各個產品效果都不太理想，看上去還不如代碼易讀。
• 固定行為，主要是對數(shù)據(jù)存儲提供增刪改查操作。
• 支持 JavaScript 自定義。
• 簡化 DSL 語言，類似 Excel 中的公式。

前面兩種方案之前介紹過了，這里只討論后面兩種。

后端支持使用 JavaScript 是種常見做法，主要原因是 JavaScript 引擎容易被嵌入，而且啟動速度快，了解的人多，比如市值超過 1200 億美元的 ServiceNow 后端自定義業(yè)務邏輯就是基于 Rhino 引擎實現(xiàn)的。

簡化 DSL 語言的主要是使用場景是做表達式計算，比如在流程中的分支流轉規(guī)則判斷，需要用戶能自定義表達式，比如金額大于多少換成總監(jiān)審批，這時用公式會比 JavaScript 會更簡單，因為系統(tǒng)可以自動轉換數(shù)據(jù)類型，并自動處理異步函數(shù)的調用，目前愛速搭的流程里有實現(xiàn)，同時在 amis 里也提供了。

另外除了上面提到這四種，我們在愛速搭中還設計了另一個方案：執(zhí)行樹，它長這個樣子：

左側是樹形結構，右側是點中某個節(jié)點時的參數(shù)配置，左側的樹形結構其實是直接參考代碼的樹形結構：

• 默認從上往下執(zhí)行，但有個特殊的「并行執(zhí)行」節(jié)點可以并行執(zhí)行。
• 對于循環(huán)和分支會創(chuàng)建子節(jié)點，并且子節(jié)點可以無限嵌套，相當于代碼里的花括號。
• 節(jié)點可以折疊，這樣就能先將復雜的邏輯折疊起來方便看主流程，這是使用圖模式難以實現(xiàn)的，在圖里收起后無法修改其它節(jié)點的位置，導致空出一塊。

為了方便實現(xiàn)簡單邏輯處理，我們還增加了 JavaScript 節(jié)點和 SQL 節(jié)點。

但執(zhí)行樹這個方案目前的定位是聚合多接口，將多個后端接口數(shù)據(jù)合并后給前端，類似于 BFF 的作用，我們推薦復雜的后端邏輯還是用 Spring Boot 吧，成熟穩(wěn)定且好招人。

3、流程的實現(xiàn)

接下來是第三個問題：如何實現(xiàn)流程？這是大部分低代碼平臺標配的功能，流程的邏輯不像普通代碼那么抽象，因此適合用可視化編輯。

流程可視化存在很久了，著名的 BPMN 規(guī)范最早版本在 2004 就發(fā)布了，因此大部分產品都會支持 BPMN 2.0 規(guī)范。

但 BPMN 本質上是一種圖形規(guī)范，它的最大作用是給事件、動作及分支條件這些抽象概念分配了不同的形體，使得熟悉這個規(guī)范的用戶有了共同語言。

BPMN 不能解決平臺鎖定問題，在一個平臺開發(fā)的流程無法直接遷移到另一個平臺。

流程的核心是實現(xiàn)流程流轉引擎，以愛速搭為例，流程可視化布局后最終存儲的格式是有向圖，比如下面這個最簡單流程：

簡化后的存儲數(shù)據(jù)格式是兩條連線和三個節(jié)點：

{ "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": "審批節(jié)點" }, { "id": "724cd2475bfe", "type": "end", "label": "結束" } ]}

流程流轉算法的核心就是根據(jù)當前狀態(tài)和這個有向圖，判斷出下個節(jié)點是什么，然后執(zhí)行那個節(jié)點的操作。

同時因為主要面向的是審批流，所以還需要處理審批場景特有的邏輯，比如有的審批是全部通過才算通過，有的審批是只需要一個人通過就算通過，還有回退、加簽等功能，并處理各種邊界條件，比如找不到審批人的時候怎么辦。

雖然目前業(yè)界有開源的流程引擎，但這些引擎大多是面向代碼開發(fā)，不太好改造成平臺模式，因此在愛速搭里自己實現(xiàn)了流程引擎，這樣才能更好定制功能。

— 7 —

低代碼平臺未來會怎樣？

前面提到了各種低代碼的實現(xiàn)方案細節(jié)，這里拋開具體細節(jié)，來整體討論一下未來低代碼平臺會怎樣。

最開始提到過低代碼唯一不可缺少的功能是可視化編輯，這是低代碼的最大優(yōu)勢，但是低代碼的最大缺陷，因為可視化難以表達復雜的抽象邏輯，因此長遠看低代碼并不會在所有領域取代專業(yè)開發(fā)，更多是和專業(yè)開發(fā)配合來提升效率。

從技術方案上看低代碼平臺主要有兩個方向：

1、偏向零代碼的方案，它的特點是：

• 易用性強
• 靈活性差
• 適合小公司，客單價低，但客戶數(shù)多
• 標準化程度高，導致功能都很類似，將面臨同質化競爭
• 產品使用簡單，客戶支持成本低

2、偏向專業(yè)開發(fā)的方案，它的特點是：

• 易用性弱
• 靈活性強
• 適合中大型公司，客戶數(shù)少，但客單價高
• 標準化程度低，每家都有各自的特點
• 產品使用復雜，客戶支持成本高

未來會怎樣呢？我的想法是：

偏向零代碼方案，因為功能類似支持成本低，可以同時支持很多用戶，容易出現(xiàn)贏者通吃的情況，但由于 toB 領域發(fā)展速度慢，所以還是有不少機會。

可以類比 BI 數(shù)據(jù)可視化產品，BI 這個領域的軟件出現(xiàn)至少 20 年了，比如 Qlik 1994 就發(fā)布了，現(xiàn)在市面上的 BI 軟件在基本功能上都大體相同，但沒有哪個產品占據(jù)絕大部分市場份額，我們的 Sugar 產品雖然兩年前才推出，但依然得到了不少優(yōu)質客戶，所以只要產品優(yōu)秀就有機會。

零代碼產品有好幾種形態(tài)，和去年一樣，我更看好「在線 Excel」，因為既然是面向非開發(fā)者，類 Excel 是上手成本最低的方案，而且這一年來許多「在線 Excel」的產品都加上了低代碼功能，比如 Airtable 的 Interface，在功能上和表單驅動的零代碼越來越接近了。

而偏向專業(yè)開發(fā)的方案，因為支持成本高導致沒法同時支持很多客戶，因此更難出現(xiàn)一家獨大的情況，而偏向研發(fā)會導致細節(jié)方案有很多區(qū)別，沒太多可比性。

以我們的愛速搭為例，目前產品選擇的方案是偏向專業(yè)開發(fā)，現(xiàn)有客戶都是知名企業(yè)，但也導致了支持成本很高，因為客戶問的問題都很專業(yè)，大多只有核心研發(fā)才能解答，在功能方面我們的特點是前端使用了我們開源的 amis 框架，這個其它家是不會提供的。

— 8 —

總結

前面字太多了，總結一下主要觀點：

• 低代碼都是一種「聲明式」編程，因為只有聲明式才能可視化編輯，而可視化編輯是低代碼唯一不可少的功能。
• 低代碼的優(yōu)缺點其實來自于「聲明式」本身。
• 編寫代碼是一種抽象思維，因此并不適合可視化，導致低代碼只能面向特定領域，復雜應用需要和專業(yè)開發(fā)配合。
• 前端界面的 HTML CSS 可以認為是一種低代碼 DSL，因此界面的低代碼比較容易實現(xiàn)，只需要在 HTML CSS 基礎上抽象一層。
• 后端存儲的低代碼有幾種方案，但沒有哪個方案是完美的，它們都有各自的優(yōu)缺點，這將決定一個低代碼平臺的適用范圍，建議在選型時重點關注。

— 9 —

在了解原理之后

前面介紹了各種低代碼實現(xiàn)原理，看起來都不難，但真正要實現(xiàn)還需要大量細節(jié)工作，以我們的 amis 為例，從 2015 年啟動至今一直在持續(xù)更新，下面是 amis 開源這兩年半來的提交歷史[2]，基本除了春節(jié)和國慶之外都在提交：

amis 的 contributors 頁面

但今天 amis 現(xiàn)在仍然有大量功能要做，比如本周將發(fā)布的 1.6.0 版本終于開始初步增強移動端 UI，下面是新版移動端日期選擇：

amis 1.6.0 里的日期選擇

除了無盡的功能要加，還有許多基礎工作要做，比如組件單元測試覆蓋率只有 40%，此刻還有 360 issues 要處理，感謝閱讀到這，有什么問題歡迎留言交流，我要去處理 issue 了……