原创 廖云富 / 叫叫技术团队

导读：这篇文章是叫叫前端团队在建设低代码平台的过程中，从前端全栈角度将整个建设过程和相关的功能设计进行整理和提炼而来。希望能够帮助你在建设自有的低代码平台时少走一些弯路。
本文涉及较多的技术点，我们假定你已经熟悉前端开发、服务端开发等相关基础知识。遇到有疑问的地方可以记录下来与我们取得联系进行探讨。

一、前言

低代码开发平台（Low Code）最早是 Forrester 研究公司在 2014 年正式提出的名称，并在 2021 年成为热炒的关键字，伴随着资本的进入，国内各大互联网厂商也纷纷布局这个赛道，钉钉的宜搭、腾讯的微搭、百度的爱速搭等等。甚至在互联网企业内部低代码平台也都成为了研发的标配。

1.1 背景

叫叫前端团队从 2021 年开始对低代码平台有关注，2022 年正式开始搭建自有的叫叫低代码平台（JO搭）。起因是一个业务部门的负责人找到前端团队技术委员会，反馈在 Q3 会出现业务大量增长，业务主要是开发各种类型的表单配置页面，当时负责该业务的PC端前端开发人员只有一个人。为了避免该业务后续出现瓶颈，鉴于前期我们对低代码平台的探索和积累，决定使用低代码平台来构建这类表单页面。
JO搭低代码平台搭建之初主要是为了帮助研发进行提效，针对PC端B端业务系统页面开发。

注：JO搭译为JOJO（叫叫）搭建平台

1.2 挑战与机遇

从收到需求到系统上线我们差不多只有一个半月的时间，有两名前端同学可以完整参与，需要承担JO搭低代码平台前后端全部的开发工作，我们也面临着挑战和机遇。

时间短任务重：要在短期内完成低代码平台从0-1的搭建并投入生产使用；

复杂业务场景：一开始就选择了比较复杂的表单场景，表单的联动和校验可视化配置较复杂；

前端全栈开发：项目完全由前端团队成员开发，第一次使用Node支持线上业务，这是一个很好的机遇和切入点；

二、方案设计

2.1 需求调研

鉴于目前的开发资源，我们一开始就决定了基于现有的成熟产品进行二次开发，紧接着就对市面上成熟的开源低代码框架进行了调研。

下面是调研的平台和情况

项目名称	调研情况
阿里低代码引擎	优点 React 技术栈，目前团队主要为 React 技术栈具备完整的物料规范低代码引擎标准实现，有一个完整开箱即用的设计器，标准化的渲染器，标准的插件设计模式 Github Star 10.9K 已经有成熟的“宜搭”商业化产品缺点没有现成的服务端实现协议涉及内容较多文档不是很全缺少现成的表单联动方案
百度爱速搭	优点低代码平台全生命周期管理流程，开箱即用具备服务端程序，具备流程引擎能够支持审批流业务，支持数据管理支持小程序、快应用等移动应用的搭建支持数据联动配置，现成的表单场景方案商业化产品文档较为健全缺点 Vue2 技术栈（团队使用较少）服务端不开源，如果遇到需要定制的需求，无法进行开发
腾讯TMagic	优点可视化设计器，支持自定义组件、插件、扩展编辑器能力支持多种技术栈开发自己的业务组件，比如vue2、vue3、react 支持现成的表单联动方案缺点没有现成的服务端实现大部分组件基于 TMagic UI ，现有团队可复用的组件较少
H5-Dooring	优点 React 技术栈，能够做到开箱即用，适合开发各类H5落地页针对H5场景做了定向的优化，支持动态加载内核等缺点商业化产品，公司内部使用存在风险所有内容均是针对H5场景进行设计的，扩展能力较弱

从调研实际情况来看，大部分开源产品都不提供服务端程序，有提供服务端程序的项目又不太适合目前项目的场景，如果在此基础上进行二次开发成本也是比较高的。
最终决定“选定一个扩展性较好的页面编辑器，自研服务端程序”，选定了低代码引擎作为基础的页面编辑器。主要有以下几个方面的考虑

React 技术栈，叫叫前端团队主要为React技术栈，PC资产包有Antd可选，现有组件库的组件能够复用
有较为成熟的低代码设计规范，包含引擎、资产规范，不用再去制定一套低代码开发规范
开源社区活跃，Github Star 10K+
已经有成熟的“宜搭”商业化产品，可以吃到商业化产品带来的一些红利，商业化的功能会逐步添加到开源版本。
自研服务端程序，可以和我们现有的研发体系结合得很好，并且后续的升级迭代也更加可控，没有过渡依赖风险。

2.2 设计与实现

2.2.1 设计目标

如下图所示，我们需要提供一个在线的页面配置管理系统，并且在对应的业务系统里提供渲染低代码页面的能力。
业务系统通过接入渲染器就可以获取到对应页面的配置Schema，并且将配置 Schema 渲染为页面组件。
目标为结合低代码引擎，建设一套自有的低代码平台达到

建设一套在线的低代码配置平台并且在业务中落地
完成表单场景的建设，并拥有联动、校验等能力

2.2.2 总体系统架构

名词解释

资产包（物料）：中后台前端体系中的各类基础组件和业务组件

低代码编辑器：支持通过可视化拖拽和组件属性配置的方式进行业务页面搭建的设计器

低代码渲染器：加载低代码页面的Schema渲染出低代码页面的SDK

场景：针对不同的业务场景，对资产包、低代码编辑器、低代码渲染器进行自定义后最终的一个组合

系统设计之初我们就考虑了低代码平台应用场景，未来一定不止服务于表单或中后台场景。我们对场景进行了抽象，将低代码平台设计成一个标准化的场景搭建平台，可以针对不同的业务场景定制完全不同的资产包，编辑器，渲染器以适配各种各样的业务。

2.2.3 关键技术组件

接下来我们分别从服务端实现和前端实现来分别讲解整个系统使用到的技术组件，以及每个组件的选型思路。

2.2.3.1 服务端实现

Web框架：JO搭完全由前端团队来进行开发，所以我们自然而然的就选择了 Node.js 作为我们的服务端开发语言。团队内之前也使用过市面上成熟的 MVC Node.js 框架，比如Express、Egg.js、Koa.js等。使用到的项目也大都在一些线下小工具场景使用的，并未真正有投入线上业务使用的项目。随后我们也对Nest.JS进行了调研，Nest.JS对比其他Web框架有以下优点

基于 TypeScript 进行构建，有完整的类型使用体验
开箱即用，不需要经过复杂的配置就可以开始构建应用程序
面向对象的编程思想，支持和JAVA程序基本一样的依赖注入能力，天然的可以让项目工程设计更加标准化
开源社区活跃，相关周边生态组件建设完善。如MYSQL、鉴权、监控、日志、定时任务等

使用 TypeScript 和开源社区活跃是我们选择 Nest.JS 的一个很重要的原因，周边生态的完善也会让我们在后续的建设中少花一些时间在造轮子上。当然我们在使用 Nest.JS 时也踩了一些坑，这个可以后续再给大家进行分享。

辅助能力：JO搭需要直接为线上业务提供服务，目前研发体系内的基础设施都是围绕JAVA进行建设的，针对Node.js 的服务可观测能力是缺失的，我们还针对 Node.js 开发了各个模块的SDK。

配置系统 Apollo的 Node.js SDK：系统基础配置均存储在 Apollo，并实现了不重启应用即修改系统配置，如CDN域名前缀地址，对象存储配置信息等。
监控能力 Promethous SDK：用于监控系统运行情况，如CPU、内存占用，HTTP服务响应情况，低代码页面配置数据查询响应情况等。
日志能力：当线上出现异常时我们需要知道异常的错误日志信息，叫叫研发内部有搭建自有的日志平台，我们也开发了对应的SDK用于将日志数据发送至自研日志平台。主要基于 Nest.JS 的自定义Logger实现。

数据存储：数据存储我们根据数据特点，分为以下两部分：

基础数据的存储：主要包含整个平台的基础业务数据存储，考虑到生态和叫叫研发体系内的基础设施建设情况，我们选择了MYSQL作为数据存储引擎。TypeORM作为ORM层，提供了完备的MYSQL能力支持，TypeScript 等。
页面配置 Schema 的存储：低代码平台产出的页面配置数据为JSON格式，根据我们实测一个完整的页面配置JSON大小大约在50KB左右，如果直接将JSON数据存储在MYSQL显然是不太友好的。我们选择了更加低廉的对象存储（阿里云OSS）来存放页面配置数据。并且对象存储可以非常方便在外部提供CDN访问能力，在C端大流量场景下拉取页面配置数据也不受限制。

下面是基础的数据库实体的ER图供参考（仅包含了关键字段）

下面是服务端项目工程的目录结构

├── src
│   ├── common                 #公共的服务类
│   ├── config                 #存放系统基础的配置
│   ├── constants              #公共的常量
│   ├── core                   #核心的授权、鉴权、公共HTTP拦截、公共HTTP响应封装
│   ├── health                 #健康检查端口（应用部署在K8S集群内）
│   ├── metrics                #prometheus指标采集端口
│   ├── platform               #业务代码放置到该文件夹
│   ├── user                   #用户相关模块
│   ├── utils                  #工具函数
│   ├── app.module.ts          #入口Module
│   └── main.ts                #程序入口（初始化）
├── .editorconfig
├── .env.development.local
├── .eslintrc.js
├── .gitignore
├── .gitlab-ci.yml
├── .npmrc
├── .prettierrc
├── README.md
├── declarations.d.ts
├── nest-cli.json
├── package.json
├── pnpm-lock.yaml
├── tsconfig.build.json
└── tsconfig.json

2.2.3.2 前端实现

基础框架：项目启动时Umi4刚刚发布，抱着吃螃蟹的心态我们直接采用了 Umi4+Antd4+@ant-design/pro-components 的组合创建了前端项目。

低代码编辑器：编辑器直接采用了低代码引擎进行搭建，其中参考了大量 lowcode-demo 工程的内容。我们对项目目录结构和插件、Setter 都进行了重新梳理。也开发了模板保存、页面保存、页面发布、页面历史记录等插件。
插件的开发可以参考：插件扩展
低代码渲染器：保存的页面 Schema JSON 配置要在业务系统接入需要引入“@alifd/lowcode-react-renderer”，我们也在此基础上封装了单独的渲染器，引入了自定义的 request handler ，页面配置数据请求逻辑等，业务方只需要接入该SDK并配置对应的页面KEY就可以直接渲染页面了。

import { ToolRender } from 'lowcode-toolbox';

<ToolRender
  ref={lowcodeRef}
  pageKey='example_page'
  appKey="example_app"
  />

组件资产：叫叫前端团队内部有前端组件平台（JOJO-Design），公共组件都在组件平台进行维护。低代码设计时考虑到不再创建一套单独的组件规范，而且低代码引擎也能够支持直接从现有的前端组件通过“低代码化”就能够完成普通组件到低代码组件的转换工作。

表单场景：低代码引擎默认场景内包含“Formily”场景资产包，Formily 能够非常好的进行表单场景的适配，并且支持联动和响应式配置，同时也具备表单场景必备的各种自定义校验能力。我们基于 Formily 组件进行二次开发，针对特定的业务场景定制了部分表单组件。

文档：低代码平台本身是一个比较庞大的系统，初学者初次使用需要阅读入门教程才能进行使用。我们基于Docusaurus 搭建了文档网站，提供了入门教程和开发者指南，帮助用户快速进行低代码页面搭建。

三、实践与应用效果

3.1 游戏配置工具表单场景落地

目前在叫叫的课程配置环节已经广泛落地，新的游戏配置表单页面已经 100% 采用低代码平台配置了。目前已经有超过 13 个游戏表单配置界面使用低代码方式开发，经过对比传统代码开发方式，传统开发约 4 小时的新需求，熟练的开发者使用低代码大约1小时能够配置完成，节省 75% 的开发时长。如果是对已上线的页面进行修改，那这个开发时长将会更加恐怖，不新增新的业务组件情况下，分钟级就可以完成修改。

3.2 运营活动场景落地

在实践中后台场景过程中，在团队内还有一部分对低代码感兴趣的同学也加入了进来，对移动端的一些落地场景进行了探索。
针对移动端场景我们制作了单独的

移动端运用活动组件资产
开发了单独的移动端低代码渲染器，移动端有单独的用户授权
针对移动端访问量大的情况，我们将低代码页面进行了静态化，将配置的页面JSON和渲染器直接打包上传至CDN，用户访问时不再需要请求低代码平台服务，加快用户访问速度。

体验地址：叫叫16周年庆活动地址

四、结语

在本文截稿时，JO搭低代码平台已经在内部完成了更多场景的落地，我们在表单场景、C端运营活动场景、B端中后台场景、数据报表场景都进行了业务落地。
当然目前JO搭低代码平台还有一些没有完善的部分，例如

低代码页面发布的合规性，低代码可以直接修改线上业务，如何保证发布的合规和稳定性
搭建系统区分开发、测试、预发布、正式环境，需要在各个环境进行页面Schema的复制粘贴

在搭建整个低代码平台的过程中，我们也发现低代码平台在每一个细分的业务领域都可以发挥巨大的作用，不仅能够完成研发的提效，甚至能够完全颠覆现有的研发或产品生产协作流程。在线可视化制作或搭建在商业领域目前也是一个非常有前景的方向。每个细分领域都可能孕育出一个巨大的商业化公司，例如：市值百亿美金的 Figma、Canva、酷家乐 – 在线3D云设计平台等等。

我们也对JO搭低代码平台也有了更多的期待，并会持续不断地去探索更多的业务场景，帮助业务快速高效发展。未来我们将从以下几个方向进行探索。