开源全站低代码项目rxDrag的前后端演示终于上线了.停下来喘口气，把开发实践通过系列文章的方式分享一下，顺便整理一下思路。当我决定做这个低代码项目时，低代码还没有现在这么流行。在开发的过程中，只是觉得前后端合一的时候，有很多冗余的信息，用代码重复表达，是一件很枯燥乏味的事情。这些枯燥重复的工作都可以由机器来完成，从而腾出时间去做更有价值的工作。带着这些幼稚的想法，我开始了对低代码开发的探索。随着工作越来越深入，越来越多的低代码领域的人被暴露出来。慢慢发现低代码火了！当你看到资本的疯狂追捧，老板的天马行空，商人的无底的阿谀，程序员充满优越感的蔑视……不免会想，自己做low-code的意义何在？为什么要踏上这趟浑水之旅？当大潮退去，一个40多岁的业余程序员的时间会被无意义地浪费掉吗？然而，有时候梦想的种子是种下了，想要毁掉是非常困难的。可能是这种执念驱使，让我坚持了一年多，前端和后端都尝试过。最后，我也想明白，生命是以死亡为代价的，所有消失的东西，只要曾经存在过，都或多或少实现了自己的一部分价值。所有的尝试，无论成败，都将成为社会进步的动力。不同的是，有的成了肥料，有的开花了，有的结果了。不管怎样，只要你觉得自己所做的工作能够帮助一些人，这样的工作就是有意义的。过分追捧与否，各种评判，都无所谓。即使身处闹市，也能找一处安静的房间，做自己喜欢的事，坚持下去！尽可能分享自己的开发心得和心得。即使项目不能开花结果，作为肥料应该更有营养。在分享开发经验之前，回答一些问题。低代码有用吗？低代码不是软件开发的灵丹妙药，它不能解决软件危机，它更像是一种工具，就像近视、助听器、汽车、轮船等。这些工具有一个共同点，就是，他们为某些人工作而不为其他人工作。低代码也是如此。作为一名外贸从业者，我见证了这样一个过程：从静态页面做企业网站，到wordpress的蓬勃发展，再到Shopify独霸独立站。在这个过程中，我们可以看到软件技术的应用得到了充分的普及，还有很大的市场空间。有很多人对软件技术不是很熟悉，对软件的使用需求很强烈，但是不让进。Wordpress和Shopify只是满足了这部分人的部分需求，却取得了巨大的成功。低代码的存在可以更好的服务于有类似需求的人。在这个领域，凡客、美篇、一期秀只是一个开始，相信还会有更多更好的应用涌现。这些应用程序本质上是低代码的。人天生不愿意做一些重复枯燥的工作，程序员也是。经常看到一些优秀的程序员，炫耀自己的代码结构有多好，好到自己完成主要结构，把重复的代码交给低端程序员。问题来了，谁是低端程序员，谁愿意做低端程序员？将这些枯燥重复的工作委托给机器是更明智的选择。有条件的公司，根据自己的业务领域，抽取一些共性的东西，打造自己的低代码框架，能否提高自己公司的开发效率？是否可以扩展系统？是否可以提高为客户定制的能力？是快速构建愿景原型的能力吗？具备这些能力的前提是你愿意提前花费一定的成本来搭建一个低代码平台。所以low-code是每个开发者都可以参与的，不是大资本的专利。也希望自己做的rxDrag系列低代码项目能提供一些有价值的参考和帮助。如果真的有一些模块能够应用，那么忙那么久也是值得的。低代码不能做什么？有很多事情是低代码做不到的。它做不到的事情太多了。它不能送我上下班，不能帮我接孩子，不能治病……什么都不要让它来做，也不要把Focus放在这方面。当专注于它能做什么时，我们专注于创造并看到客户。只关注积极的事情会给你带来美好的生活体验。程序员会被淘汰吗？低代码完成的是一些枯燥、重复的工作。作为一名程序员，如果你坚持做这些工作，毫无情绪地与机器竞争，你可能会被淘汰。如果是情绪化的工作，就不容易被机器取代。在Wordpress之前，国内的建站公司远比现在多。他们向客户收取高额费用，使用低质量的模板，建立了充满浓厚地方情怀的企业网站。直到Wordpress的出现，国外大量质优价廉的主题模板通过Wordpress生态进入中国。一些外贸培训机构通过教客户用WordPress建站，年收入达数亿元。国内很多建站公司都被淘汰了。请问这些被淘汰的企业，输的有说服力吗？没有任何编程经验的人，经过短暂的培训，做出一个秒杀你昂贵的本地网站的网站，为什么不被淘汰？淘汰是新事物取代旧事物的过程。一种工作类型的消失往往会创造出更多新的工作类型。就好像车夫不见了，却出现了各种各样的司机和宇航员。面对这样的变化，我们是否需要叹息？需要害怕吗？需要谴责吗？谁在乎这样的态度？谁能阻止这些变化？历史的车轮滚滚向前，当时代即将淘汰我们的时候，他们会迎接我们吗？面对这些，除了全力奔跑，我们还能做什么呢？科技日新月异，但爱永远不变。爱、美、创意不仅从未被淘汰，反而变得越来越珍贵。我愿意相信，真诚为他人着想，用心为客户服务的人不会被淘汰，他们只是改变了服务客户的形式。低代码不是癌症，也不是灵丹妙药。它只是一个工具，好人和坏人都可以使用。不要因为坏人吹捧就对它产生敌意，它是无辜的。也不要因为大资本追逐就把它神话了，它只是一个工具。技术栈选择过程技术栈太多了，不同的技术栈适用于不同的应用场景。就个人而言，毕竟经验有限，很难说哪个更好。只是分享使用该技术的经验，希望能为一些朋友提供一些参考。刚重新进入开发领域的时候，想给公司做一个CMS项目。因为看到了PHP在市场上的成功，所以选择了PHP+Laravel，后来学习了VUE。在使用VUE的过程中，我非常喜欢组件的概念。萌生了使用VUE+Laravel作为低代码平台的想法。做低代码平台梦想的种子，可能就在这时候种下了。页面表单中输入的数据、请求接收到的数据、存储到数据库中的数据，往往是相同的数据，但要在三个地方处理三次。要添加或修改字段，所有三个代码都必须更改一次。基于对这种冗余工作的厌恶，当时用PHP做了一个简单的低代码框架：通过PHP函数构建前端页面的JSON描述，同时可以绑定字段数据。前端做了一个VUE渲染引擎来渲染后端传来的JSON。这样虽然解决了冗余代码问题，但是结构不合理。页面与业务数据的耦合过于紧密。虽然作为一个业务程序员，我的技术水平一般，但是我愿意折腾和分享。疫情期间做了一个HMTL可视化编辑小工具，无意中登上了知乎热搜，并从中认识了很多朋友。和朋友交流了很多，也有很多新的想法进来，知道不用PHP代码也可以生成界面描述，直接在数据库中写描述json就可以了。非常感谢当时提供这个思路的网友“冲动”。此时的技术栈是：PHP+Laravel+Vue。设计思路是通过可视化拖拽的方式构建前端JSON描述，将这些描述存储在数据库中，做一个专门的渲染引擎，渲染这些接口，绑定数据。目标是做一个不需要代码的前端。具体后端如何实现没有过多考虑。一个人做开源是不可能的。自己一个人做所有事情是不可能的。选择成熟的UI库是很有必要的。在不知道什么是MaterialDesign的情况下，误选了Vuetify。由于技术不熟练，在做Vuetify的可视化拖拽的过程中经历了一个曲折的过程。有的坑是因为自己水平太好了，有的坑是因为技术栈的选择。在处理拖放事件的时候，使用Vuetify的方式总感觉不自然，总觉得应该有更流畅的方式。不是功能实现不了，而是总感觉别扭。另外，我不习惯Vue的槽。在这种情况下，我决定学习React。在阅读了React文档后，我深信不疑。原来十几年前，书本上讨论的编程思想已经被实践并变成了产品。作为一个没有任何约束的自由开发者，回归Vue是不可能的，他注定要走上React的道路。既然选择了React，顺带一起学习一下TypeScript也是顺理成章的。用一个不熟悉的东西，不可能有合理的结构设计。我给自己定下的目标是先完成功能，再重构优化代码。一边学习，一边制作，跌跌撞撞完成了第一版可视化前端。技术栈为：TypeScipt+React+Redux+Materialui。第一个版本完成后，就迫不及待的挂出了demo。我发在几个论坛上，反响还不错，虽然我知道还是差了很多。在接下来的近一年时间里，将是一个不断改造和折腾的过程。第一个版本与后台通信的接口是Webapi，demo数据是用mockjs做的。就在这个时候，网友“NexibleFatty”向自己推荐了mobx和GraphQL。作为一名自由开发者，尝试几种新技术并不难。使用GraphQL和mobx重构前端是自然发生的。目前的演示版本是基于这两种技术的重构版本。mobx的优势不言而喻。虽然很多小伙伴不喜欢，觉得不符合React的理念，但对我来说不是障碍。mobx由低代码领域领先的子项目mendix发展而来，对低代码项目非常友好。在使用的过程中，mobx用起来还是很舒服的。不过，说到GraphQL，就不好说了。后端选择：代码生成还是实时？前端完成，后端的实现面向代码生成和实时运行两个方向。代码生成技术已经发展了很多年，也是最容易实现的，但是成功的案例很少。各大厂商开发的基于代码生成的IDE，大多已化作时代的尘埃，被遗忘在某些角落。做一个精简的、开箱即用的实时后端无疑是我最希望完成的工作。然而，现有的与GraphQL相关的开源库，除了hasura之外，大部分都是基于代码生成的。它们可以成为开发人员的绝佳工具，但很难成为低代码平台的首选。作为一个团队只有一个人的业余爱好者，他只能融入开源生态，没有精力事事亲力亲为。目前很少有时间和精力去开发类似Hasure的GraphQL服务器。我们只能暂时放弃GraphQL，转而使用传统的WebAPI。到目前为止，后端已经实现为JSONAPI+指令。该演示已准备好运行并且文档是初步的。我心里很清楚，我很不甘心就这样放弃GraphQL，也许未来的某一天，我会重新回来。后端技术栈的选择一直倾向于PHP生态。在使用GraphQL的时候，就计划好了，Laravel+Lighthouse。我喜欢PHP的三个原因：PHP在前Web时代的成功；知识匮乏，不知道太多新技术，毕竟离开这个行业太久了；解释型语言对热插拔友好，适用于低代码项目。在使用Lighthouse的过程中，总感觉有些不流畅。最后在朋友的劝说下放弃了PHP，选择了Java和TypeScript其中之一。选择Java不用有什么顾虑，毕竟成熟成功。不过，我还是想试试TypeScript，希望它能带来更多的可能性。rxDrag的目标是中小型项目，我相信TypeScript足够胜任。目标执行语言是js，是解释型语言，热加载友好，可以用js生态的东西。使用一段时间后，发现TypeScript的开发效率比PHP高很多。一句话：TypeScript真香。目前后端技术栈：TypeScript、nestjs、TypeORM。前端技术栈：TypeScript、React、Mobx、Materialui。有前端和后端演示可以运行。关于技术栈选择的思考前段时间看了高瓴资本创始人张磊的《价值》（应该是他说的，不是特别确定）。他表达了这样一个观点，基于经济学中的比较优势原理，进入一个统一的全球市场是一个国家发展的必要条件。中国过去40年的快速发展，也得益于改革开放和走向全球市场。同理，可以获得技术栈的选择权。在选择技术栈的时候，尽量对接大生态圈。短期商业项目可能看不到任何优势。从长远来看，连接到更大生态系统的项目将走得更远。低代码平台的重点在哪里开发rxDrag的前端项目DragIt耗时1年左右，后端项目rxModels耗时2个月左右。前后端完成后，最深刻的感悟就是低代码项目的重心应该在后端。这个想法与无处不在的拖放低代码有点格格不入。静静坐下来回顾一下这些年的发展，你会发现后端的发展速度比前端慢。Java全家桶已经发展了将近20年。整体思路没有太大变化，但是前端变化很快。这意味着如果同时开发前后端两个项目，后端的生命周期很可能会比前端长。无论前端还是后端，核心都是数据。如果数据管理得好，可以衍生出很多前端应用。我个人的建议是把管理重点放在靠近数据的后端部分。在rxDrag项目中，其后端部分rxModels也是整个项目的核心。rxDrag低代码平台rxDrag致力于构建全栈低代码生态，其核心是后端对象管理模块rxModels。目前包括这些内容：rxModels是一个对象管理服务器，通过绘制ER图，可以实时搭建一个运行后台。提供了一个通用的JSON接口用于操作服务端数据，接口可以通过指令进行扩展。内置基于角色的细粒度权限管理。项目地址：https://github.com/rxdrag/rx-...rxmodles-swr一组Reacthooks，用于帮助与服务器端的rxModels进行通信。项目地址：https://github.com/rxdrag/rxm...DragIt可视化低代码前端。项目地址：https://github.com/rxdrag/dragit还有一个与DragIt分离的不依赖于特定UI库的拖拽框架。现在我不知道该怎么称呼它。下一篇内容分享rxDrag后端rxModels的开发实践
