1
shawnxwang 2021-02-13 11:06:57 +08:00 1
我用过 Prisma+Nexus,这类产品会有 performance 的问题,内部小项目用还行,简单快捷
|
2
est 2021-02-13 11:07:38 +08:00 via Android
低代码平台广告贴?
我感觉路走偏了,你把 graphql 换成 sql 就和 20 年前做法一模一样了。db 负责管理权限,可以执行一些 serverless 的存储过程,可以根据不同业务生成不同的数据 view 。先进的多。 都不如 vb5 delphi 来的快。拖一个表格控件,双向绑定,可以满足 99%需求了 |
3
sugarkeek OP @est 老哥,说广告贴我就不乐意了,帖子里没有广告链接吧,经常看我发推广吗?我就发过几个外包项目的。我理解论坛上有发广告的,但是这么一上来就扣帽子着实不舒服。
我上面也讲了,也设想过之间在数据库层面展开权限和模型,但是还是和其他技术配合就不太灵活了。如果说数据库有这么涉及到复杂逻辑一个和技术配合的部分,那其实和我讲的概念一样, |
4
dfzj 2021-02-13 12:25:29 +08:00
不可能的,CRUD 的 SQL 本身足够简单,SELECT.. UPDATE... INSERT... 本身就非常接近自然语言。
应用层没有什么必要需要干掉它,除非它能实现 SQL 的的效果,并且比 SQL 还简单,而且跟前后上下文程序衔接成本也更低。 |
5
msg7086 2021-02-13 12:40:26 +08:00
怎么有种重新发明 ORM 的感觉……
|
6
xcstream 2021-02-13 13:23:09 +08:00
想多了
crud 是程序员吃饭的主食 |
7
abcbuzhiming 2021-02-13 13:33:38 +08:00
sql 已经非常简单了,我觉得你重新定义 SQL 真的没有意义,SQL 没有被 NoSQL 干跨已经说明了自己的生命力如何。
最后,复杂度问题的存在是各种通信协议的更新解决不了,无论你管这通信协议叫 REST 还是 GraphQL 都没意义 |
8
moonsn 2021-02-13 16:02:16 +08:00 via Android
gril ?
|
10
musi 2021-02-14 00:05:58 +08:00
strapi 由谁去开发?前端用 GraphQL 查询也是需要后端去写接口的,不要把 GraphQL 过于神话了。做开发的要记住一句话:软件开发没有银弹
|
11
GreyYang 2021-02-15 09:50:06 +08:00 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 减少的人力成本、后期维护费用与云产品(硬件)费用增加的成本之间的关系,然而这个得失结果却是非常难以明确了。 |