Skip to content

GitLab

开放中
Created by 庄建国@zhuangjianguoOwner

[Proposal]: 问题与展望

Created by: snowyu

从功能上看Steedos是国内开源低代码平台最完善的,站在了巨人的肩膀上,吸收了SaleForces低代码平台的许多优秀的经验.真正做到了开箱即用. 有望成为国内乃至国外领先的开源低代码平台黑马.

问题

拍马屁的话就不多说了. 下面从代码和功能层面上谈谈不足之处:

从代码上看:

  • 虽然开源,但是开源社区没有做起来,全是自己在维护更新代码,原因如下
    • 使用了不下三种语言: js, coffeescript, typescript
      • 缺少统一的开发 Language Style 规范.
    • 自行维护的库包太多,让有心加入的开发者难以下手
    • 如果对第三方库包有说改进,应该遵循开源做法,Fork and PR. 而不是直接复制到自己的项目中.
    • 缺少自动化的单元测试
    • 进而导致:
      • 维护复杂度高
      • 库包升级麻烦(如 meteor)
      • 因为很难区分哪些是自己开发的,哪些是第三方开发的,从而很容易引发 DMCA(Digital Millennium Copyright Act) 版权纠纷.
  • 严重依赖于 Meteor
    • 剥离 Meteor 依赖, 只需保留 Meteor 的用户认证作为向下兼容的微服务.
    • 例如有人已经把Meteor-AutoForm从meteor剥离出来作为Reacto-Form
  • 而内部代码又严重依赖于 Creator
    • 导致库包通用程度不高, 比如 objectql 过于依赖于本项目,根本从项目中拿不出作为独立库使用.自然就不能更好的利用开源社区.
  • Datasource不通用,内部只能用mongoDB数据源.需要重构Datasource,对第三方数据源和自己的不应加以区分,应该一视同仁都能使用.
  • 数据库ORM应该同时支持 MongoDB, MySQL, PostgreSQL, SqLite
  • 权限通用性还要扩展:
    • 支持 view/modify filter 指定的记录, 而不是只有 modifyAllRecords/viewAllRecords
    • 支持特定字段权限, 限制只能编辑,查看记录中的某些字段
    • 似乎关于限定某个子组织方可访问的权限也没在这里看到,比如子组织可以继承父组织的权限,也可以不继承自己设置.
  • MetaData 规范没有分离后端定义和前端定义, 后端的定义前端一定需要,但是前端定义后端就用不着.
    • 比如字段类型中,混杂了前端的类型和后端的类型
    • 分离的意义在于更好的总结规范前端的需求和后端的需求.
    • 尽量规范后端的Meta字段保持数据库的通用性(NoSQL, SQL都支持)
    • 规范前端的Meta字段则可以分离UI,切换不同的UI库(只要创建不同的UI适配器就可),乃至建立新的UI组件都有标准可循.
      • 个人不是很喜欢DevExtremeUI库,虽然它的确好用.
  • SalesForce 的 Formulas 可读性太差,这个就不要照搬吧,完全和白皮书不搭:

    • 销售订单审批通过时，如果涉及多个供应商，自动分解成多个采购订单，并自动给供应商发送订单确认邮件

    • 也许下面这样更方便那些不懂编程的业务人员

      如果 [销售订单].审批 为 "通过" 那么
  列出所有 [销售订单].[产品] 的 供应商, 产品 和 产品数量
    建立 采购订单: 填入 供应商, 产品 和 产品数量
    然后发送邮件给 联系人(供应商).邮件地址, 内容是 请确认采购订单

    • 当然如果是从迁移讲,能完全兼容 SalesForce, 很轻松的把 SalesForce 的应用数据迁移过来,也不错.

  • 对开源代码的限制没有说明,比如:
    • 无导入数据库
    • 无配置服务端的触发器

展望

使用 Moleculer 重构为微服务架构是一个好主意,这是个大工程,为啥不干脆抛开原有的架构体系,重头来过,毕竟以前的历史包袱太重. 好好梳理下库包,该扔的就扔.从架构上重新设计. 另外 Moleculer 的 DB Adapter 也是需要重写的, 它只支持单表(Collection),而这远远不够, 还需要支持:

  • Collections(多表)
  • Relation
  • Transaction
  • Migration(数据库版本更新和回滚)

最近因朋友的关系接触到中小学教育这块,而各个学校的管理差别很大,很适合lowcode的场景,本想自己写一个,没想到看到你们的项目. 看下来工具链的癖好似乎差不多: coffeescript, meteor(做原型玩过超快,show出来也酷,数据实时变化), react, typescript. 而测试这块,前端还好有用 storybook,就是需要补全测试用例.后端推荐用jest, API测试不妨试试我自己写的Api-BDD-Test,基于Cucumber, 可以用类似自然语言的方式(中文)建API测试用例.

如果您们也正想完全重构项目,打造一流低代码开源平台,超越SafesForce,那么我就没必要自己再写了,直接加入好了. 只是用上 Moleculer 是远远不够的.

简单介绍下业余写过的一些东东,本职是架构.