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

开源、全站、低代码项目 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 后端项目 rxModes 的开发实践