本文主要介绍低代码开发开源(低代码开发平台介绍)，下面一起看看低代码开发开源(低代码开发平台介绍)相关资讯。
开源、全站点、低代码项目rxdrag的前端和后端演示终于上线了。停下来喘口气，通过系列文章分享开发实践，顺便整理一下思路。
当我决定做这个低代码项目的时候，低代码还没有现在这么火。
在开发过程中，我只是感觉前端和后端合二为一，有很多冗余信息，用代码反复表达。是一件很无聊很无聊的事情。
这些枯燥重复的工作完全可以由机器来完成，从而腾出我们的时间去做更有价值的工作。
带着这些幼稚的想法，我开始了低代码开发的探索。随着工作的深入，越来越多的人接触到低码领域。慢慢意识到低码火了！
当你看到资本的疯狂追逐，老板的奇思妙想，商家的无底线吹捧，程序员充满优越感的鄙视。...
难免会想，自己做低代码有什么意义？你为什么要趟这趟浑水？当潮水退去，一个40岁的业余程序员的时间就没有意义了吗？
但是，有时候梦想的种子种下了，很难湮灭。可能是这种执念的驱使让我坚持了一年多，前端和后端都尝试了一遍。
最后，我想明白，生命是以死亡为代价的，所有消失的东西，只要存在，都或多或少的实现了自己的一些价值。所有的尝试，无论成功与否，都会成为社会进步的动力。不同的是，有的成了肥料，有的开花了，有的结果了。
不管怎样，只要你觉得你做的工作能帮助到一些人，这样的工作就是有意义的。过度追捧与否又有什么关系呢？即使在闹市，你也可以找一个完全安静的房间，做自己喜欢的事情，然后坚持下去！
尽可能的分享自己的开发经验和心得。即使这个项目可以 不开花不结果，作为肥料应该更有营养。
在分享开发经验之前，先回答一些问题。
低代码到底有没有用？低代码不是软件开发中的银弹，它可以 解决不了软件危机，它更像是一个工具，就像近视、助听器、汽车、轮船等等。
这些工具有一个共同点，就是对一些人有用，对另一些人没用。
低代码也是如此。
作为一个外贸从业者，我见证了这样一个过程:从使用静态页面到制作企业网站，再到wordpress的蓬勃发展，再到shopify 美国的统一和独立。在这个过程中，我们可以看到软件技术的应用是完全普及的，还有很大的市场空间。有很多人对软件技术不熟悉，对软件的使用需求很强烈，却不让他们进门。
wordpress和shopify只是满足了这部分人的部分需求，取得了巨大的成功。低码的存在可以更好的服务有类似需求的人。在这个领域，各种题材，精美的文章，轻松的企业秀只是一个开始，相信会有越来越多优秀的应用涌现。这些应用程序本质上是低代码的。
人天生不愿意做一些重复枯燥的工作，程序员也是如此。经常遇到一些优秀的程序员，炫耀他们的代码结构有多优秀，到了自己完成主要架构，把重复的代码交给低端程序员的程度。
问题是，谁是低端程序员，谁想做低端程序员？
把这些枯燥重复的任务留给机器，是更明智的选择。
有条件的公司，根据自己的业务领域，拿出一些通用的东西，搭建自己的低代码框架。能提高自己公司的开发效率吗？有没有可能扩大系统的容量？能否提高为客户定制的能力？你有能力快速原型化一个愿景吗？
具备这些能力的前提是你愿意提前花一定的成本去做一个低代码的平台。所以低代码是每个开发者都可以参与的，而不是大资本的专利。
也希望自己的rxdrag系列低代码项目能提供一些有价值的参考和帮助。如果有些模块真的可以应用，那么忙这么长时间也是值得的。
什么可以 t低代码做什么？许多事情可以 不能用低代码完成。它能做的事情太多了。;不做。它可以 不要送我去工作，can 不要接我的孩子，can 不治疗疾病...唐 不要向它要求任何东西，也不要。;不要把重点放在这方面。
当我们专注于它能做什么的时候，我们专注于创造，关注客户。只关注积极的事情会带来美好的人生体验。
程序员会被淘汰吗？●代码做一些枯燥重复的工作。作为一个程序员，如果你坚持做这些工作，不带感情地从机器上抢饭吃，你可能会被淘汰。如果是感性的工作，不容易被机器取代。
在wordpress出现之前，的网站建设公司比现在多得多。大家收客户很多钱，套用劣质模板，把企业网站做得充满了浓浓的乡土气息。
直到wordpress的出现，大量质优价廉的国外主题模板通过wordpress生态圈进入。一些外贸培训机构通过教客户用wordpress建网站，年赚上亿元。国内很多建站公司被淘汰。
这些被淘汰的公司能对自己的亏损深信不疑吗？不喜欢的人。;没有任何编程经验，经过短期培训，使网站杀死你昂贵的本地网站。为什么不被淘汰？
淘汰是一个新事物取代旧事物的过程。当一个工作岗位消失时，往往会创造出更多新的工作岗位。就在车夫消失的同时，出现了各种各样的司机和宇航员。。
面对这样的变化，需要感叹吗？你需要恐惧吗？需要被谴责？谁在乎这种态度？谁能阻止这些变化？当历史的车轮滚滚向前，时代要淘汰我们的时候，你会迎接我们吗？面对这些，我们除了全力奔跑还能做什么？
技术日新月异，但爱永远不变。爱、美、创意从来没有被淘汰，反而越来越珍贵。愿意相信、真心为他人着想、用心为客户服务的人是不会被淘汰的，只是改变了服务客户的形式而已。
低代码不是毒瘤，也不是万能药，而是工具，好人坏人都会用。唐 不要因为坏人奉承它，就对它怀有敌意。it 它是无辜的。唐 不要神话它，因为它受大资本追捧，它只是一个工具。
技术堆栈中有太多技术堆栈。;的选择过程，不同的技术栈适用于不同的应用场景。个人来说，毕竟经验有限，很难说哪个更好。
只是分享一下使用二手技术的经验，希望能给一些朋友提供一些参考。
刚重新进入开发领域的时候，想给公司做一个cms项目。因为看到了php在市场上的成功，所以选择了php laravel，后来了解了vue。在使用vue的过程中，我非常喜欢组件的概念。使用vue·拉勒维尔作为低代码平台的想法应运而生。做低码平台的梦想的种子可能就在这个时候种下了。
在页面表单中输入的数据、请求的数据和存储在数据库中的数据往往是相同的，但需要在三个地方进行三次处理。要添加或修改字段，需要再次更改所有三个代码。基于对这种冗余工作的厌恶，当时用php做了一个简单的低代码框架:用php函数构造前端页面的json描述，同时可以绑定字段数据。前端做了一个vue渲染引擎，从后端渲染json。
这样虽然解决了代码冗余的问题，但是结构不合理。页面与业务数据耦合太紧密。
虽然作为一个业务程序员，我的技术水平一般，但是我愿意折腾和分享。期间，我做了一个hmtl的可视化编辑小工具，无意中登上了知乎热搜，从中交到了很多朋友。
和朋友交流了很多，也有很多新的想法进来。我知道我可以直接在数据库中编写描述json，而不需要生成php代码。非常感谢当时提供这个想法的网友。
此时的技术栈是:php laravel vue。设计思路是通过可视化拖拽建立前端的json描述，将这些描述存储在数据库中，做一个专门的渲染引擎，渲染这些界面，绑定数据。目标是做一个没有代码的前端，具体后端如何实现还没有考虑太多。
一个人可以 当他做开源的时候，不要什么都自己做。选一个。一个成熟的ui库是必要的。在对材料设计一无所知的情况下，我误选了vuetify。由于技术经验不足，接下来的过程在vuetify的视觉拖拽过程中经历了一个曲折的过程。有的坑是因为水平差，有的是技术栈 的选择。
在处理拖拽事件的时候，使用vuetify的总感觉不自然，总觉得应该有更流畅的。it 这并不是说它可以。;功能上实现不了，但总感觉别扭。另外，我不习惯用vue的槽。在这种情况下，我决定学习react。
看了react文档，印象深刻。原来，十几年前，书本上刚刚谈到的编程思路，已经付诸实践，变成了产品。作为一个没有任何约束的免费开发者，是不可能回归vue的，也注定要在react的道路上走下去。
既然选择了react，那么顺便一起学习typescript也就顺理成章了。
用一个奇怪的东西，不可能设计出合理的结构。给自己的目标是先完成功能，再重构优化后的代码。
边学边做，跌跌撞撞的完成了第一版可视化前端。技术栈是:typescript react reduce material ui。
第一版完成后，我不能 i don’我迫不及待地要举行。我在几个论坛发了，反响还不错，虽然我知道还差很多。将近一年的时间，是一个不断重建和折腾的过程。
第一版和后端通信的接口是web api，是mockjs做的演示数据。这时，网友 灵活的胖子 给自己推荐了mobx和graphql。作为一个自由开发者，尝试几种新技术并不难。使用graphql和mobx重构前端是自然而然的事情。目前的演示版本是基于这两种技术的重构版本。
mobx的优势不言而喻。虽然许多朋友不 i don’我不喜欢它，也认为它不怎么样。;不符合react的概念，对我来说不是障碍。mobx是由低码行业的子项目mendix开发而来，对低码项目非常友好。在使用过程中，mobx用起来还是很舒服的。
然而，当谈到graphql时，它 一言难尽。
后端选择:代码生成还是实时运行？前端完成，后端实现面临两个方向:代码生成和实时运行。
代码生成技术已经发展了很多年，实现起来也是最简单的，但是成功的案例很少。大厂开发的基于代码生成的ide，大多已经化为时代的尘埃，被遗忘在某些角落。
毫无疑问，我们需要一个精简的实时后端。是我最希望完成的工作。
而现有的开源库，除了与graphql相关的hasura，大部分都是基于代码生成的。对于开发人员来说，它们可能是优秀的工具，但对于低代码平台来说，它们几乎不是首选。
作为一个团队只有一个人的业余爱好者，他只能融入到一个开源的生态中，却没有精力自己去做所有的事情。目前很少有时间和精力去开发一个类似hasure的graphql服务器。只能暂时放弃graphql，改用传统的web api。
到目前为止，后端都是通过json api指令实现的。演示已经准备好运行，文档已经初步完成。
我心里很清楚，我不愿意就这样放弃graphql。也许有一天我会回来。
后端技术栈和。;的后端技术选择一直倾向于php生态。当你使用graphql时，它 已经计划好了，拉勒维尔灯塔。
我喜欢php有三个原因:
php在前web时代的成功；他们知识匮乏，不了解太多新技术，毕竟离开这个行业太久了；解释语言对热插件友好，适合低代码项目。在使用lighthouse的过程中，总觉得有点不舒服。最后被朋友说服放弃php，在java和typescript之间选择。
选择java没必要着急，毕竟已经成熟成功了。但是，我还是想试试typescript，希望它能带来更多的可能性。
rxdrag针对中小型项目，我相信typescript足够胜任。目标执行语言是js，这是一种解释语言，对热加载友好，可以使用js生态系统。
用了一段时间后，我发现typescript的开发效率比php高很多。总之，typescript好闻。
到目前为止，后端技术栈:typescript，nestjs，typeorm。
前端技术栈:typescript，react，mobx，mat《价值》(应该是他说的，但我不是特别确定)。他认为，进入全球统一市场是一个国家的必要条件。;基于经济学的比较优势原理。 过去40年的快速发展也得益于改革开放和进入全球市场。
以同样的，你可以得到技术栈 的选择。在选择技术栈的时候，尽量连接大的生态圈。短期的商业项目可能看不到什么优势。从长远来看，通路更重要。项目的状态会更进一步。
低码平台的重心在哪里？开发rxdrag的前端项目dragit用了一年左右，后端项目rxmodels用了两个月左右。前端和后端完成后，最深刻的感受就是低代码项目的重点要放在后端。
这种想法和无处不在的拖拽式低代码有点格格不入。
只要静静的坐下来回顾这些年的发展，你会发现后端的发展速度比前端慢。java family buck-modelsrxmodles-swr,的一套react钩子，用于与rxmod://github.com/rxdrag/dragit也有一个拖放框架，与dragit分离，不依赖于特定的ui库。我还没有 我还没决定它的名字。下一篇文章将分享rxdrag后端项目rxmodes的开发实践。
标签:
代码后端
了解更多低代码开发开源(低代码开发平台介绍)相关内容请关注本站点。