V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
sugarkeek
V2EX  ›  Node.js

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

  •  
  •   sugarkeek · 87 天前 · 2719 次点击
    这是一个创建于 87 天前的主题,其中的信息可能已经有所发展或是发生改变。
    我这是设想啊。

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

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

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

    想法只是一时兴起还有不成熟的地方大家多多讨论
    第 1 条附言  ·  87 天前
    girl,手误
    12 条回复    2021-02-15 12:50:52 +08:00
    shawnxwang
        1
    shawnxwang   87 天前   ❤️ 1
    我用过 Prisma+Nexus,这类产品会有 performance 的问题,内部小项目用还行,简单快捷
    est
        2
    est   87 天前 via Android
    低代码平台广告贴?

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


    都不如 vb5 delphi 来的快。拖一个表格控件,双向绑定,可以满足 99%需求了
    sugarkeek
        3
    sugarkeek   87 天前
    @est 老哥,说广告贴我就不乐意了,帖子里没有广告链接吧,经常看我发推广吗?我就发过几个外包项目的。我理解论坛上有发广告的,但是这么一上来就扣帽子着实不舒服。

    我上面也讲了,也设想过之间在数据库层面展开权限和模型,但是还是和其他技术配合就不太灵活了。如果说数据库有这么涉及到复杂逻辑一个和技术配合的部分,那其实和我讲的概念一样,
    dfzj
        4
    dfzj   87 天前
    不可能的,CRUD 的 SQL 本身足够简单,SELECT.. UPDATE... INSERT... 本身就非常接近自然语言。
    应用层没有什么必要需要干掉它,除非它能实现 SQL 的的效果,并且比 SQL 还简单,而且跟前后上下文程序衔接成本也更低。
    msg7086
        5
    msg7086   87 天前
    怎么有种重新发明 ORM 的感觉……
    xcstream
        6
    xcstream   87 天前
    想多了
    crud 是程序员吃饭的主食
    abcbuzhiming
        7
    abcbuzhiming   87 天前
    sql 已经非常简单了,我觉得你重新定义 SQL 真的没有意义,SQL 没有被 NoSQL 干跨已经说明了自己的生命力如何。

    最后,复杂度问题的存在是各种通信协议的更新解决不了,无论你管这通信协议叫 REST 还是 GraphQL 都没意义
    moonsn
        8
    moonsn   87 天前 via Android
    gril ?
    sugarkeek
        9
    sugarkeek   87 天前
    @moonsn girl,手误手误
    musi
        10
    musi   87 天前
    strapi 由谁去开发?前端用 GraphQL 查询也是需要后端去写接口的,不要把 GraphQL 过于神话了。做开发的要记住一句话:软件开发没有银弹
    GreyYang
        11
    GreyYang   85 天前   ❤️ 2
    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
        12
    sugarkeek   85 天前
    @GreyYang 感谢老哥的分享的观点,很客观理性的分析
    关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1638 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 18ms · UTC 00:12 · PVG 08:12 · LAX 17:12 · JFK 20:12
    ♥ Do have faith in what you're doing.