共计 5549 个字符，预计需要花费 14 分钟才能阅读完成。
开源、全站、低代码我的项目 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 的起因有三个：
- 前 Web 时代 PHP 的胜利；
- 本人常识的匮乏，不理解太多新的技术，毕竟来到行业太久了；
- 解释语言对热拔插敌对，适宜低代码我的项目。
在应用 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 的开发实际
