低代码组件/平台从了解到实现（宏观笔记）

低代码是非常宽泛的概念，有很多产品都声称自己的低代码，但我们很容易反过来回答另一个问题：「什么是低代码产品唯一不可缺少的功能？」

低代码平台就是让用户通过图形界面和模型驱动的逻辑来创建应用程序（而非传统的手写代码），从而加快开发过程并降低技术门槛。

低代码开发平台（Low-Code Development Platform，简称LCDP）,也称为APaaS（Application Platform as a Service）应用平台即服务——开发平台提供的是一种服务。支持用户无需写代码或者只需写少量代码即可完成应用系统的搭建。

从1980年的时候，IBM就有快速应用程序开发工具（RAD）;在2000年出现了VPL（可视化编程语言）、低代码领域有显著成绩的OutSystems和Salesfoce等都成立了，就是国外其实在这一块的探索和投入是比较早的，所以国外低代码也相对更成熟一些。到2010年的时候，麻省理工推出了少儿图形化编程Scratch，很快就风靡全球；这时也有一些国内企业开始探索、或者专注在低代码领域。在2014年的时候著名的Forrester正式提出了低代码概念。在这之后2015年相当于一个爆发期，AWS、微软等世界巨头都进入了低代码领域。2018 Mendix被西门子收购，进一步把低代码推向了风口。

低代码相关产品已经许多了（比如《推荐20个开源的前端低代码项目》），我们团队的bk-lesscode、bk-vision也上线很久了，但是关于低代码 ，真的一篇《万字长文讲透低代码》、《低代码平台的“觉醒年代”何时来临？》能概括？当然不能，但我还是得做一下自己的笔记！

为什么需要低代码平台

核心诉求是让非专业开发者也能构建起现实可用的业务应用程序。比如产品、运营、运维能够快速搭建数据可视化页面（bk-vision的核心功能）

基本思路是帮助已经对业务流程拥有深刻理解的用户轻松参与到应用程序构建中来，通过将专业业务知识与 IT 团队的开发技能相结合，企业客户可以进一步加快创新速度。

从 Web 前端的视角出发，无论是基础的 UI 组件、业务 UI 组件、脚手架，还是 React、Vue 这些 UI 框架和 Webpack、Vite 这些构建工具，最终都是让前端开发者可以更专注也业务逻辑代码的编写，减少重复性或者不必要的代码编写。最终的目的还是为了减少代码的编写和提高开发效率。

所以低代码最直接的表现就是整合 UI 框架、组件、脚手架、权限、部署等等，让已有的工具一体化，最终实现一个可用的低代码编辑器（IDE），同时低代码 IDE 需要支持原生代码的编程方式，实现一些无法通过拖拽配置完成的复杂功能场景。

低代码领域两种大方向

• 中心化的“模型解释”——salesforce模式

• 去中心化的“代码生成”——mendix、outsystem模式。

传统的软件开发过程

代码生成和模型解释本质上的目标都是“写更少的代码，生成更多”，即“Write less code , Generate more”。

10年前，2010年国外就在讨论这个话题，详见Mendix CTO的博客《Introducing Code Generation and Model Interpretation》，其中有一位行业专家的评论印象很深，他是这么说的，“当然，归根结底，这是一个古老的问题编译还是解释，或者在更基本的层面上，是代码还是数据。只需记住，即使是手写的机器代码也只是数据：实际上是由CPU解释的0-255值数组！”(原文：Of course, at the end of the day this is the old question of compiling vs. interpreting, or on an even more basic level, code vs. data. Just remember that even hand-written machine code is just data: an array of values 0-255, which is actually interpreted by the CPU! )。

低代码平台通过抽象得到组件，再由组件搭建表单页面。

低代码平台核心功能

低代码平台其实就是一个可视化编程平台，就是可视化程序设计：通过少写代码，或者不写代码通过拖拽的方式生成。

可视化编程的特点就是所见即所得、一站式研发、技术收敛、而且专业门槛低，对程序员小白相对友好。

可视化程序设计最少要满足以下需求：

1. 可视化编辑：编辑器进行页面可视化搭建

2. 页面构建：构建和发布页面供用户浏览

低代码编辑器才是低代码平台的核心，而低代码编辑器在市场上可能包含属性配置引擎、表单引擎、CURD 模型引擎、流程引擎、模板引擎等等。

低代码实现原理：

细节层面，具体实现可以参看：

• https://github.com/woai3c/visual-drag-demo

• https://tencent.github.io/tmagic-editor/docs/guide/

本篇讲一些宏观层面的，首先看下《从DDD到DSL的一些认知总结》，核心原理就是通过DSL定义程序逻辑

具体步骤为：

1. UI可视化开发规范

2. 逻辑可视化开发规范

3. 统一的DSL语言和IDE

4. 生产与运行解决方案(解析、编译引擎，一码多端引擎)

参看鹅厂的核心引擎和底层库建设

界面实现

UI-Schema是核心，它是用来描述和定义UI界面所有内容的一个规范，包括页面、布局、组件的表现形式、属性范围、属性格式、值类型、样式、事件等内容。根据UI-Schema规范，我们在UI可视化模块实际维护的是一个UI-Data数据。

比如lesscode类，核心原理是将 JSON 转特定组件库，然后使用 vue进行渲染。

{
  "component": "div",
  "title": "普通组件",
  "body": {
    "type": "form",
    "title": "用户登录",
    "body": [
      {
        "type": "input-text",
        "name": "username",
        "label": "用户名"
      },
      {
        "type": "input-text",
        "name": "password",
        "label": "密码"
      }
    ]
  }
}

可以转换为：

<div>
  <form>
   <label>用户名</label> <input name="username" type="text"/>
   <label>密码</label> <input name="password" type="text"/>
  </form>
</div>

为什么采用json schema

低代码平台编辑器几乎都是基于 Web 实现，JavaScript 可以方便操作 JSON。

JSON 可以支持双向编辑，它的读取和写入是一一对应的。

但 JSON 的优点就是它的缺点，因为它的用途是数据交换而不是人工编写，导致基于 JSON 构建 DSL 不方便编辑，会有以下 3 个问题：

1. 不支持注释
   

2. 不支持多行字符串

3. 语法过于严格，比如不支持单引号，不能在最后多写一个逗号

其是 在存储的时候将注释内嵌到一个特殊的字段中，在代码显示的时候将它提取出来变成注释。

组件通用配置

低代码离不开组件结构协议设计，基本每个低代码平台都有自己的一套方案，这的确很难统一。

然后就是这么多的组件，如果每一个都定制处理，那将是一个庞大的工作量，也不适用于组件的定制拓展功能。

所以组件通用配置的关键在于两处：

• 组件结构协议，使用者在界面上配置的属性，最终会转为此结构，然后存储在数据库。

• 组件适配协议，即开发者可以根据已有组件，通过此协议可快速适配对应的低代码可用组件。

• 联动/交互协议，本人推荐数据驱动架构（事件驱动也类似），统一交互类数据接口协议。

组件结构协议

组件结构协议其实是在低代码里贯穿整个流程，大部分关键的功能基本都需要配合组件结构协议来设计。

组件结构协议其实和 DIV/JSX 结构是很类似的，不过需要特殊处理函数类型和变量的替换：

• 函数：

1. 返回组件的函数（如 antd，table columns render 方法）：通过标记属性为函数返回组件和参数变量的方式可以达到配置此类函数的效果。

2. 组件事件函数：比如联动、下钻等各类交互

• 变量：

1. 自定义变量值 ${custom}.xx

2. 接口变量值 ${xx}.xx

3. 映射值变量 ${mapping}.xx

4. 遍历变量值 ${map}.xx

5. 函数参数变量值 ${funArgs}.0 | ${funArgs}.1

6. 表达式（特殊的变量值）${expression} xx.xx | ${expression} ${funArgs}.0

组件适配协议

特指已有组件可根据此协议快速适配为低代码可用的组件，即低代码某个组件配置区域的渲染协议。

可以参考 https://lowcode-engine.cn/site/docs/specs/material-spec，然后制定适合自己平台的规范

联动/交互协议

其是就是Logic Schema规范建设。逻辑可视化建设中，Logic-Schema是核心，他是用来描述和定义一段逻辑的规范，包括各种控制语言、赋值语句、运算操作、I/O操作、网络操作、页面UI操作、组件调用等。

交互逻辑的实现

低代码平台中，最重要的就是如何将平时需要用if-else，赋值、while等代码才能表述的逻辑用可视化的方式表述出来。

目前常见有三种方案：

1. 使用图形化编程

2. 固化交互行为

3. 代码注入（直接执行用户给定的代码）

既然低代码的关键是可视化，那直接使用图形化的方式编程不就行了？ 

为什么代码无法可视化？

35 年前没有银弹的论文里就证明：代码无法可视化！

可视化的前提条件是什么？

答案是需要具备空间形体特征，可视化只能用来展现二维及三维的物体，因为一维没什么意义，四维及以上大部人无法理解，所以如果一个事物没有形体特征，它就没法被可视化。

随便一些例子，比如实现深度克隆（《深度克隆从C#/C/Java漫谈到JavaScript真复制》）

leetCode 中级的感觉基本都难以执行，能做的，感觉是适合少儿少儿编程这种级别，，比如：https://scratch.mit.edu/

https://github.com/scratchfoundation/scratch-gui

而前面图形化是低代码唯一不可少的功能，这就使得低代码不适合做复杂的抽象逻辑处理，这是图形化缺陷决定的，因此在复杂逻辑处理方面低代码永远无法彻底取代专业代码开发。

图形化不适合用来实现业务逻辑，只适合用来做更高层次流程控制，比如审批流，审批流是现实真实存在的，没有复杂的抽象逻辑，因此适合图形化。借此再对g6-editor闭源事件高呼伸手党万岁！

固化交互行为

固化算法

但如果是面向特定领域，低代码平台可以先将这个领域难以图形化的算法预置好，让使用者只需做简单的处理，比如在 Blender 中将 PBR 算法封装了，使用的时候只需要调整参数就行

如果复杂了，你的图像界面不卡死，但是用户大脑估计也会死机！比如：https://blueprintsfromhell.tumblr.com/

固化交互

固化交互行为，这是不少低代码平台的做法。比如：tab、swipe、dialog、发起请求、打开链接、刷新等。

使用固化交互行为有下面两个优点：可以可视化编辑，整合度高，通过嵌套实现复杂的交互逻辑

低代码组件

在低码平台上， 我们可以通过可视化拖拉拽的方式，再编写少量代码即可快速开发一个应用。

而使用开发应用相同的方式开发的组件就是低码组件。简单讲就是在低码平台上直接开发的组件。

一般都是使用传统的源码开发方式在线下（脱离低码平台）开发，然后再到低码平台上上传使用，我们称之为源码组件。

在前端组件化的今天，一个页面都是由组件拼凑而成的，组件有基础组件，有业务组件，如果所有组件都是源码组件，那就相当于大部分的开发工作都是在线下，脱离了低码平台，那低码平台的价值就大打折扣，有点名存实亡的感觉。

我们可以看阿里的：https://lowcode-engine.cn/site/docs/guide/expand/editor/parts/partslcc

巴巴的lowcode低代码引擎是挺强大，想要的功能都有，可定制化程度也高。

但是感觉是个KPI项目，比如文档为何如此拉胯呢？导致上手成本略高。各种定义也很繁杂，想要在实际项目中落地，需要花费大量的时间研究规则。

其实这是是实现简单组件个性定制化开发。关键还是简历组件市场，加载第三方组件（插件化架构），这里安利下：《插件化架构设计(1):插件化架构能解决什么问题？为啥选它？》 、《微前端学习笔记(4):从微前端到微模块之EMP与hel-micro方案探索》

生产与运行建设

就是最部署问题，最高级的形式是 拖曳出来的页面再编译（精简化、一码多端等），但是目前各类平台的做的其实不多！

这方面去啃 编译原理吧……

后端低代码的方案

后端低代码需要解决以下三个问题：

1. 如何实现自定义数据存储？

2. 如何实现业务逻辑？

3. 如何实现流程流转？

如何自定义数据存储？

低代码平台需要支持用户存储自定义数据，因为每个应用所需的字段是不一样的。

myslq or MongoDB , who cares？同时模糊的还有类型，字段除了数字、字符串、图片（url）、GIS……

给用户（特别是产品）提供的始终是 数据模型，平台所接入的业务千差万别，…… 

自定义数据存储是后端低代码最重要的功能，使用什么方案将直接影响这个产品的适用范围，目前我们已知有4种方案，每种都有自己的优缺点。

直接使用关系型数据库（SQL类）

这个方案的原理是将数据模型的可视化操作转成数据库 DDL。

这个方案的优点是：

1. 所有方案里唯一支持直连外部数据库，可以对接已有系统。
   

2. 性能高和灵活性强，因为可以使用高级 SQL。

3. 开发人员容易理解，因为和专业开发是一样的。

但它的缺点是：

DDL 有很多问题无解，比如在有数据的情况下，就不能再添加一个没有默认值的非 NULL 字段。

最关键的是：JSON字段任意拓展（动态字段），SQL类会搞死人！（比如：mysql 对JSON的支持也不错了，个人感觉还是赶不上MongoDB类）

使用行代替列

很多可扩展平台里使用的技术，比较典型的是 WordPress，它的扩展性很强，装个扩展就能变成电商网站。而整个 WordPress 只有 12 个表，它是怎么做到的？方法是靠各种 meta 表。

WordPress 的扩展性主要依赖于 wp_postmeta 和 wp_usermeta 这样的元数据表。这些表允许开发者为帖子、用户、分类和标签添加无限量的自定义字段，而不需要修改核心数据库结构。这种设计使得 WordPress 能够通过插件和主题来扩展其功能，而不需要对数据库进行大规模的更改。

例如，如果你想将 WordPress 网站转变为电子商务平台，你可以安装像 WooCommerce 这样的插件。WooCommerce 会在现有的 WordPress 数据库中添加自己的表来存储电商特有的数据，如订单、产品、支付方式等，同时也会大量使用 wp_postmeta 表来存储产品的额外信息，比如价格、库存、SKU 等。

这种使用元数据表的方法提供了极大的灵活性，因为它允许存储几乎任何类型的数据，并且可以通过简单的查询来检索。这也是为什么 WordPress 能够通过插件来实现各种各样的功能扩展，而不会影响到核心系统的稳定性和性能。

这个方案的优点是实现简单，多用于成熟项目的扩展，比如在 CRM 产品中允许用户扩展字段，但因为性能较低，并不适合通用低代码平台。

1. 查询性能低，如果有 10 个字段就要查 10 行。
   

2. 无法支持 SQL 高级查询，因为数据是按行存的。

元信息+宽表

早期数据库不支持 JSON 字段的时候，有些开发者会预留几个列来给用户扩展自定义属性，比如在表里加上 ext1、ext2、ext3 字段，让用户可以存 3 个定制数据，基于这个原理我们可以进一步扩展，通过预留大量列来实现应用自定义存储。

这个方案最早出现在 https://www.salesforce.com/，具体细节可以阅读它架构说明文档。

宽表会将每个字段及其属性以列的形式存储,不同的属性之间用列进行区分。

例如产品表中,产品ID、产品名称、品牌都作为产品维度的不同列。地区ID和地区名称也是不同的列。

这种列式存储使各字段直接可用,便于分析运算。

综上，宽表实现了事实表和维度表的聚合，以列的形式存储各个字段属性，从而成为一个扁平化的结构，这是它与长表的显著区别。

实现它有两个关键点：元数据、预留列，这里简单说明一下原理，首先系统预先创建一个 500 列的表，比如就叫 data：

缺点

• 开发难度大/维护成本高：宽表到底多宽、主次如何分类、数据一致性如何保持 等

• 冷热分离难：里面有200个字段，有30张报表在使用它，但是我发现前面150个经常字段经常被使用，后面 50个字段只有一两张报表使用到了

• 数据泄露风险高：数据库都不支持行级别权限的账号，所以意味着所有租户其实共享一个数据库账号，只要有某个功能的查询漏了加租户过滤就能查到所有租户数据。

使用文档型数据库（noSQL）

文档型数据库不需要预先定义表结构，因此它很适合用来存储用户自定义数据，特别适合用户做自定义配置。实现成本非常低。

显著缺点：

1. 无法支持外部数据库，数据是孤岛，外部数据接入只能通过导入的方式。

2. 不支持高级 SQL 查询（ MySQL、Postgres 虽然支持JSON字段类型，但是创建索引麻烦，从而导致大规模数据查询困难）。

后端业务逻辑的实现

前面提到过代码难以图形化，这在后端也是一样的，因此大概有这几种方案：

1. 逻辑图形化，这个目前看各个产品效果都不太理想，看上去还不如代码易读。

2. 固定行为，主要是对数据存储提供增删改查操作。

3. 支持 JavaScript 自定义。

4. 简化 DSL 语言，类似 Excel 中的公式。

流程的实现

如何实现流程？这是大部分低代码平台标配的功能，流程的逻辑不像普通代码那么抽象，因此适合用可视化编辑。

流程可视化存在很久了，著名的 BPMN 规范最早版本在 2004 就发布了，因此大部分产品都会支持 BPMN 2.0 规范。

低代码不是银弹，不要过度神化

低代码解决不了所有（或者大部分）编程问题，深层原因无非解决不了实际业务的复杂性问题，复杂性又分三类，

• UI复杂性，Web排布就是个深坑，做一个功能齐全的UI编排工具，约等于实现一个浏览器UI调试器，有人可能说自创简化UI语法和引擎，你可以创，市场绝对不会买你的账。

• 代码与UI联动的复杂性，各种神交互，神来了也顶不住，这里不做解释！

• 纯逻辑和涉及后台交互复杂性，这两个实际研发工作里，更是八仙过海，更显神通，各种习惯、模式乱飞，某些超大型项目在业务鼎盛时期可能有人力来统一下，小项目基本都是浓郁个人风格，平台类工具一定满足不了这些个性化需求

• 对算法和复杂数据结构要求比较高的：业务逻辑复杂对低代码来说不是问题，算法逻辑复杂才是问题。那啥叫业务逻辑复杂呢，就是业务人员总之是说的清楚，或者是能理解的；啥叫算法逻辑复杂呢，就是业务人员只能给个目标，具体怎么实现是不管的，就算解释也是一脸闷逼的听不懂的。

• 分析和智能化应用：分析类应用自然应该用更专业的BI工具，
  

通用和定制化的矛盾，抑制不了定制化需求加上设计上的局限。

某个厂商宣传的效果越好，就越不可能是专业的低代码平台。从我们的经验看，用低代码做一些小系统确实挺快，但上了规模后还能是不是有数倍提升，我觉得也不大可能。

研发低代码⼯具除了依赖技术底蕴外，更需强⼤过硬的产品思维，这类⼈是在市场上极具稀缺性的。

但 BPMN 本质上是一种图形规范，它的最大作用是给事件、动作及分支条件这些抽象概念分配了不同的形体，使得熟悉这个规范的用户有了共同语言。

低代码只是一种解决业务问题的工具，它可以有一个宏大的愿景，但是它不能脱离现实业务而被造出来，所以它一开始肯定是紧贴业务的，围绕的业务的痛点展开建设的。要用敏捷的方式对平台所处领域进行合理分拆，小步快跑，合理迭代开发。

参看文章：

从实现原理看低代码 https://zhuanlan.zhihu.com/p/451340998

可视化拖拽组件库一些技术要点原理分析 https://juejin.cn/post/6908502083075325959

什么是低代码（Low-Code）https://developer.aliyun.com/article/778493

什么是低代码？低代码开发平台的优势是什么？ https://www.steedos.com/platform/lowcode

6500字，关于低代码平台，你想知道的都在这里 https://www.woshipm.com/it/5121523.html

腾讯低代码OTeam建设概述 https://cloud.tencent.com/developer/article/1829525

转载本站文章《低代码组件/平台从了解到实现（宏观笔记）》,
请注明出处：https://www.zhoulujun.cn/html/webfront/engineer/Architecture/9090.html