开源低代码平台开发实践一：低代码开发探讨与技术选型

开源、全站、低代码项目 rxDrag 的前、后端演示终于全都上线了，停下来喘口气，把开发实践通过系列文章的方式分享出来，顺便整理一下思路。

当决定要做这个低代码项目的时候，低代码还不像现在这样火。

开发过程中，只是觉得前端后端合起来，有很多冗余信息，被代码一遍遍重复表达，是一件很枯燥、无聊的事情。

这些枯燥的重复工作，完全可以由机器来做，以便解放出我们的时间，来做更有价值的工作。

带着这些有点儿天真的想法，开始了低代码开发的探索之路。随着工作越来越深入，接触到的低代码领域的人也越来越多。慢慢意识到，低代码火了！

当看到资本们疯狂的追逐、老板们天马行空的幻想、商家们无底线的吹捧、程序员们充满优越感的鄙视...

难免会思考，自己做低代码的意义到底是什么？为什么要趟这趟浑水？当大潮退去，一地鸡毛，一个四十多岁业余程序员的时光，是否被毫无意义的消耗掉了？

但是，有时候梦想的种子被种下，就很难将其湮灭。可能就是这份执念的驱动，让自己坚持了一年多，前端后端都尝试一遍。

最后也想明白了，生命是以死亡为代价的，所有消失的事物，只要存在过，或多或少就实现了部分自身价值。所有的尝试，不管成功还是失败，都会成为社会进步的动力。区别是，有的变成了肥料，有的开出了花朵，有的还结出了果实。

管那么多呢，只要觉得自己做的工作能够帮助某些人，这样的工作就是有意义的。是否过度被追捧，形形色色的评判又有什么关系，就算在闹市里，也可以完全寻一方静室，做自己喜欢的事情，然后坚持到底！

把自己的开发经验、心得尽量多的分享出来，就算项目开不了花、结不出果，那么充当肥料，也要更有营养一些。

在分享开发经验之前，先回答一些问题。

低代码到底有没有用？

低代码不是软件开发方面的银弹，它解决不了软件危机，它更像是一个工具，就像近视镜、助听器、汽车、轮船等一样。

这些工具有一个共同的特点，就是对有些人有用，对有些人却没用。

低代码也是这样的。

作为一个外贸从业者，见证了这样一个过程：从用静态页面做企业网站，到 wordpress 的蓬勃发展，再到 Shopify 的一统独立站天下。这个过程里，看到软件技术应用完全普及开来，还有很大的市场空间。有很多对软件技术不是很熟悉，对软件有很强烈的使用需求的人，却不得门而入。

Wordpress 跟 Shopify 只是满足了这部分人的一部分需求，就取得了巨大的成功。低代码的存在，可以更好地服务有类似需求的人群。在这个领域，什么凡科、美篇、易企秀只是初级的开始，相信会有更多更优秀的应用不断涌现的。这些应用本质上都是低代码。

人天生就不愿意做一些重复性枯燥工作，程序员也是。经常见一些优秀程序员，炫耀自己代码结构多么优秀，优秀到这样的程度：自己完成主要架构，重复性代码交给低端程序员去做。

问题是，谁是低端程序员，谁愿意做低端程序员？

这些枯燥的重复性工作，交给机器来做，是更为明智的选择。

有条件的公司，根据自己的业务领域，把一些通用的东西抽出来，打造一个专属自己的低代码框架，是不是可以提高自己公司的开发效率？是不是可以系统的扩展能力？是不是可以提高为客户定制的能力？是不是具备了快速原型化一个愿景的能力？

具有这些能力的前提是，愿意预先花一定的成本，做一个低代码平台。所以低代码是每一个开发者都可以参与的事情，不是大资本的专利。

也希望自己做的rxDrag系列低代码项目，能够提供一些有价值的借鉴和帮助。如果某些模块，能被真正应用起来，那么持续这么长时间的忙碌也算值了。

低代码不能做什么？

很多事情，都是低代码不能完成的，它不能做的事情太多了，不能送我上下班、不能替我接孩子、不能治疗疾病..., 不要去要求它什么都行，也不要把关注点放在这个方面。

当聚焦在它能做什的么时候，我们关注的创造，看到的是客户。只关注正向东西，会带来美好人生体验。

程序员会被淘汰吗？

低代码完成的是一些枯燥的，重复性的工作。作为一个程序员，如果坚持要做这些工作，跟没有情感的机器抢饭吃，那么可能是要被淘汰的。如果是带有情感的工作，是不容易被机器取代的。

在Wordpress以前，国内的建站公司远比现在多，大家收着客户不菲的价钱，套用着劣质模板，做着充满浓浓乡土气息的企业网站。

直到 Wordpress 出现，国外大量的质优价廉的主题模板通过 Wordpress 生态圈子进入国内，有些做外贸培训的机构，凭借教客户用WordPress建站，年收入达上亿元。很多国内建站公司被淘汰。

试问这些被淘汰的公司，输得心服口服吗？没有任何编程经验的人，经过短短培训，做出来的网站，秒杀你们收费高昂的乡土网站，凭什么不被淘汰？

淘汰，是新事物取代旧事物的过程。一个工种消失，往往会产生更多新的工种。就像马车车夫消失了，却出现了各种驾驶员、宇航员。

面对这样的变化，需要感叹吗？需要恐惧吗？需要谴责吗？这样的态度谁会在意？这些变化谁能阻止？历史车轮滚滚，时代要淘汰我们的时候，会跟我们打招呼吗？面对这些，我们除了全力奔跑，还能做些什么？

技术日新月异，爱却永恒不变。爱、美、创意不仅从来没有被淘汰，反而越来越珍贵。愿意相信，真心为他人着想，用心服务客户的人，不会被淘汰，只是换个服务客户的形式而已。

低代码不是毒瘤，也不是万能药，只是一个工具，这个工具既会被好人使用，也会被坏人使用。不要因为坏人在吹捧它，就对它充满敌意，它是无辜的。也不要因为大资本追捧，而神话它，它只是个工具。

技术栈的选择历程

技术栈太多了，不同的技术栈，适合不同的应用场景。就个人来讲，毕竟经验有限，很难说哪个更优。

只是分享用过技术的使用体验，希望能对有些朋友多少能提供一点借鉴意义。

最初重新进入开发领域，是要给公司做个CMS项目，因为看到了PHP在市场上的成功，就选择了PHP + Laravel，后来了解了VUE。在使用VUE的过程里，非常喜欢组件的概念。就萌生了用VUE+Laravel做一个低代码平台的想法。做低代码平台梦想的种子，或许就在这个时候已经种下了。

页面表单输入的、请求接收到的、跟存到数据库的往往是同样的数据，却要在3个地方处理3遍，添加或者修改一个字段，就要3处代码全部改一遍。基于对这用冗余工作的厌恶，当时用PHP做了一个简易低代码框架：通过PHP函数构造前端页面的JSON描述，同时可以绑定字段数据。前端做了一个VUE渲染引擎，用于渲染后端传来的JSON。

用这样的方式，虽然冗余代码问题解决了，结构却不合理。页面跟业务数据耦合太紧密。

虽然作为业务程序员，技术水平一般，但是愿意折腾，愿意分享。疫情期间做了一个小的HMTL可视化编辑的小玩意，无意间竟然登上了知乎的热搜，由此认识了很多朋友。

跟朋友交流多了，很多新的想法跟着进来了，知道可以把界面的描述不用PHP代码生成，直接把描述JSON写在数据库里。非常感谢当时提供这个思路的网友“冲动”。

这时候的技术栈是：PHP + Laravel + Vue。设计思路是，通过可视化拖拽的方式构建前端JSON描述，把这些描述存在数据库里，做一个专门的渲染引擎，渲染这些界面，并绑定数据。目标是做一个不需要代码的前端，具体后端怎么实现，并没有考虑太多。

一个人做开源，不可能所有东西都自己做，选一个成熟UI库是必要的。在还不了解什么事 material design 的情况下，误打误撞选中了 Vuetify。由于技术的不熟练，接下里在做 Vuetify 的可视化拖拽的过程里，经历了曲折的过程。有的坑是因为自己水平太菜，有的坑则是技术栈选择的问题。

在处理拖拽事件的时候，使用 Vuetify 的方式总感觉不是特别自然，总觉得应该有更顺畅的方式。不是功能上实现不了，而是总觉得别扭。另外，对Vue的 slot 也有些使用不习惯。在这样的情况下，决定去了解React。

看了一遍 React 文档，就被折服了。原来十几年前，只是书本上谈论的编程思想，已经被人实践出来变成了产品。作为没有任何约束的自由开发者，已经不可能再回到 Vue 了，注定要在 React 的路上走下去。

既然选中了 React，那么 TypeScript 顺便一起学，也就顺理成章了。

使用一个陌生的东西，不可能结构设计很合理，给自己定的目标就是先完成功能，然后再重构优化代码。

边学习，边制作，跌跌撞撞完成了第一版可视化前端。技术栈是：TypeSctipt + React + Redux + Material ui。

第一版完成，就迫不及待挂出演示，在几个论坛发了一下，反响还不错，虽然自己知道还差很多。接下来将近一年的时间里，都是不断重构折腾的过程。

第一版跟后端通讯的接口是 Web api，用 mockjs 做的演示数据。这时间点，网友“灵活的胖子”给自己推荐了 mobx 跟 GraphQL，作为一个自由开发者，尝试几项新的技术，并不是困难的事情。使用 GraphQL 和 mobx 对前端重构，自然而然也就发生了。目前的演示版本，就是基于这两项技术重构后的版本。

mobx 的优势不言而喻，虽然很多朋友不喜欢，觉得跟 React 的理念不搭，但对我来说不是障碍。mobx是从低代码界的扛把子项目mendix发展出来的，对于低代码项目是非常友好的。在使用的过程中，mobx 用起来还是非常舒服的。

但是，说起 GraphQL，可就一言难尽了。

后端的抉择：代码生成还是实时运行？

前端完成，后端的实现面临两个方向：代码生成跟实时运行。

代码生成技术已经发展多年，实现起来最为简单，却鲜有成功案例。大厂们开发出来的基于代码生成的IDE，大都化成了时代灰尘，被人遗忘在某些角落里。

做一个精悍的、开箱即用的实时后端，无疑是自己最希望完成的作品。

可是，现有的开源库，除了 hasura，跟 GraphQL 相关的，大都基于代码生成。它们可以成为开发者的优秀工具，却很难成为低代码平台的首选。

作为团队只有一个人的业余爱好者，只能融入一个开源生态，是没有精力什么都自己做的。目前，几乎没有什么时间跟精力，开发一个跟 Hasure 类似的 GraphQL 服务端。只能暂时放弃 GraphQL，改用传统 Web API。

到目前为止后端的实现为 JSON API + 指令的方式。演示已经可以运行，文档也已初步完成。

自己心里很清楚，就这样放弃 GraphQL，很不甘心，说不定以后的某一天，还会再回来。

后端技术栈的选择

后端技术，一直是倾向于 PHP 生态的。使用 GraphQL 的时候，就计划好了，Laravel + Lighthouse。

钟情于PHP的原因有三个：

1. 前 Web 时代 PHP 的成功；
2. 自己知识的匮乏，不了解太多新的技术，毕竟离开行业太久了；
3. 解释语言对热拔插友好，适合低代码项目。

在使用 Lighthouse 过程里，感觉上总有些不顺畅，最后还是被朋友劝退了，放弃 PHP，在 Java 跟 TypeScript 两个里面选一个。

选择Java，是不需要有任何顾虑的，毕竟成熟又成功。但是，还是想尝试一下 TypeScript，希它能够带来更多的可能。

rxDrag的目标是中小型项目，相信 TypeScript 足以胜任。目标执行语言是js，是一种解释语言，热加载友好，可以使用JS生态圈的东西。

使用一段时间之后，发现 TypeScript 的开发效率要比 PHP 高好多，一句话：TypeScript真香。

到目前为止，后端技术栈：TypeScript，nestjs，TypeORM。

前端技术栈：TypeScript，React，Mobx，Material ui。

前后端都有演示可以运行。

对技术栈选择的思考

前一段时间，读高瓴资本创始人张磊的《价值》（应该是他说的，不是特别确定），他表达了这样一个观点，基于经济学的比较优势原理，接入全球统一的大市场，是一个国家发展的必要条件，中国近40年的快速发展，也是受益于改革开放，接入全球市场。

同样的道理，可以拿到技术栈的选择上来。选择技术栈的时候，尽可能接入大的生态圈子，短期商业项目可能并看不出什么优势，长期来看，接入更大生态的项目会走的更远。

低代码平台的重心在哪里

开发 rxDrag 的前端项目DragIt，大约用了1年的时间，后端项目 rxModels 大约2个月。前后端完成以后，最深刻的感悟就是，低代码项目的重心应该放在后端。

这想法与随处可见的拖拽低代码，显得有点格格不入。

只需要静静坐下来，回顾一下这些年的发展，会发现后端的发展速度是要比前端慢的。Java全家桶发展了近20年，整体思路变化不大，前端却是飞速变化着。这意味着，同时开发出前端跟后端两个项目，后端生命周期大概率会长于前端。

不管前端跟后端，围绕的核心都是数据，数据管好了，可以衍生很多前端应用。个人建议，把管理重点放在靠近数据的后端部分。

rxDrag项目里，它的后端部分 rxModels 也是整个项目的核心。

rxDrag低代码平台

rxDrag力图构建一个全栈低代码生态圈，它的核心就是后端的对象管理模块 rxModels。目前包含这些内容：

• rxModels 是一个对象管理服务器，通过绘制ER图，就可以实时构建一个可以运行的后端。提供通用JSON接口，用于操作服务端数据，并且可以通过指令扩展接口。内置了基于角色的细粒度权限管理。项目地址：https://github.com/rxdrag/rx-models

• rxmodles-swr 一套React钩子，辅助跟服务端 rxModels 通信。项目地址：https://github.com/rxdrag/rxmodels-swr

• DragIt 可视化低代码前端。项目地址：https://github.com/rxdrag/dragit

• 还有一个从 DragIt 分离出来的，不依赖具体 UI 库的拖拽框架，现在还么想好叫什么名字。

下一篇文章内容

分享 rxDrag 后端 rxModels 的开发实践