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

开源、全站、低代码项目 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-...
  • rxmodles-swr 一套React钩子,辅助跟服务端 rxModels 通信。项目地址:https://github.com/rxdrag/rxm...
  • DragIt 可视化低代码前端。项目地址:https://github.com/rxdrag/dragit
  • 还有一个从 DragIt 分离出来的,不依赖具体 UI 库的拖拽框架,现在还么想好叫什么名字。

下一篇文章内容

分享 rxDrag 后端 rxModels 的开发实践

你可能感兴趣的:(前端javascript低代码)