未分類
17 2 月 2021

通过 strapi 这类产品，是不是就没有 CRUD boy/gril 了

通过 strapi 这类产品，是不是就没有 CRUD boy/gril 了

資深大佬 : sugarkeek 2

我这是设想啊。

strapi 其实是作为一个中间层或者网关这么一个概念，定义完模型和权限，前端用 GraphQL 查询，涉及到复杂的逻辑，如图片合成等，通过 strapi 插件的形式交给算法工程师去做。

当然我想过甚至去了 strapi 也行，直接在数据库上定义好权限和权限，psql 已经有类似的部件了。当然我觉得加上一层更好一点，这样 js er 有 strapi.js ，py er 有 strapi.py, java er 有 strapi.java，更加灵活。

大项目我不清楚，我接触过的中小型项目，绝大部分可以替换。

想法只是一时兴起还有不成熟的地方大家多多讨论

大佬有話說 (12)

  • 資深大佬 : shawnxwang

    我用过 Prisma+Nexus，这类产品会有 performance 的问题，内部小项目用还行，简单快捷

  • 資深大佬 : est

    低代码平台广告贴？

    我感觉路走偏了，你把 graphql 换成 sql 就和 20 年前做法一模一样了。db 负责管理权限，可以执行一些 serverless 的存储过程，可以根据不同业务生成不同的数据 view 。先进的多。

    都不如 vb5 delphi 来的快。拖一个表格控件，双向绑定，可以满足 99%需求了

  • 主 資深大佬 : sugarkeek

    @est 老哥，说广告贴我就不乐意了，帖子里没有广告链接吧，经常看我发推广吗？我就发过几个外包项目的。我理解论坛上有发广告的，但是这么一上来就扣帽子着实不舒服。

    我上面也讲了，也设想过之间在数据库层面展开权限和模型，但是还是和其他技术配合就不太灵活了。如果说数据库有这么涉及到复杂逻辑一个和技术配合的部分，那其实和我讲的概念一样，

  • 資深大佬 : dfzj

    不可能的，CRUD 的 SQL 本身足够简单，SELECT.. UPDATE… INSERT… 本身就非常接近自然语言。
    应用层没有什么必要需要干掉它，除非它能实现 SQL 的的效果，并且比 SQL 还简单，而且跟前后上下文程序衔接成本也更低。

  • 資深大佬 : msg7086

    怎么有种重新发明 ORM 的感觉……

  • 資深大佬 : xcstream

    想多了
    crud 是程序员吃饭的主食

  • 資深大佬 : abcbuzhiming

    sql 已经非常简单了，我觉得你重新定义 SQL 真的没有意义，SQL 没有被 NoSQL 干跨已经说明了自己的生命力如何。

    最后，复杂度问题的存在是各种通信协议的更新解决不了，无论你管这通信协议叫 REST 还是 GraphQL 都没意义

  • 資深大佬 : moonsn

    gril ?

  • 主 資深大佬 : sugarkeek

    @moonsn girl，手误手误

  • 資深大佬 : musi

    strapi 由谁去开发？前端用 GraphQL 查询也是需要后端去写接口的，不要把 GraphQL 过于神话了。做开发的要记住一句话：软件开发没有银弹

  • 資深大佬 : GreyYang

    strapi 这类 headless cms 只能解决 CRUD 项目的简单基础需求。但是这是非常有意义的。
    处理表之间的复杂级联关系和逻辑计算，strapi 的 Shadow CRUD 是不够的，但是 strapi 也明白这个道理，在项目中几乎每个阶段都可以 hook，以增加自己的处理逻辑，甚至可以定制 plugin, 这时 CRUD boy/girl 还需要上场。
    权限系统也是如此，通用解决方案不可能实现现实项目中的各种权限，例如 strapi 的 RBAC 颗粒度是针对每个 model （表）中的各个方法（ find/findOne/create/update/delete 等）的权限，但是现实中的项目客户要求的“权限”可能是好几个 model 中方法的组合，甚至还牵扯更多的别的判断，这时的逻辑也需要 CRUD boys or girls 去实现。
    还有许多的“现实“需求直接用 strapi 无法完成的,所以 strapi 此类产品能否取代 CURD boy?我觉得不能。但是能取代一部分 CRUD boy 的基础工作，让 CRUD boy 的工作更加轻松一点我认为是可以做到的。
    另外性能问题我觉得倒不是非常重要，这类产品的单体性能肯定是比用 springboot 或者其他框架直接写出来的要低，但是本身逻辑与数据分离，数据库可以分布式扩容，strapi 无状态配置后(上传下载文件上云储存，公共 auth 认证)也可以水平扩容做负载均衡，最终计算得失的地方是使用 strapi 减少的人力成本、后期维护费用与云产品（硬件）费用增加的成本之间的关系，然而这个得失结果却是非常难以明确了。

  • 主 資深大佬 : sugarkeek

    @GreyYang 感谢老哥的分享的观点，很客观理性的分析