graphql 增加了后端的工作量,也可能会导致接口聚合难以维护,不太理解后端用这个干嘛?

[TomVista]

而且前端用这个也没什么优势吧?

graphql 我能感觉到好用的地方 是聚合已有的接口 /微服务 /api 生成新的接口.

但是大部分项目都没有这么多已有的接口 /微服务 /api 吧? 而且这种聚合会造成资源浪费..比如 n+1query, 或者所有数据都过一遍 graphql 的过滤 然后返给前端..... , 我认为没有多少项目能够支撑使用 grapql 带来的缺点

[mcfog]

观察两家知名的 graphql 接口服务商脸书和 github，他们用 graphql 都是非常合适的

- 他们的后端（开放）接口 consumer 数量巨大，协作困难（不如说因为是提供给大量第三方，不可能单点和某家 consumer 协作）
- 支持更多的 consumer 对他们是有利的，形成生态的，他们有动力去改善 consumer 的开发体验（ DX ）
- 他们的业务核心逻辑和关系稳定多年不变（脸书的用户、好友关系、feed 流，github 的 repo、star 等），又有大量的字段、自资源、关联等情况，又愿意或者需要提供这些能力给外部

好的，所以国内几乎不存在满足上述条件的公司，就算国外我也想不到第三家了

哦，对接部门多到爆炸的大公司的某些核心部门的内部 API 网关可能也还能考虑用吧，但这种用了也不一定会有分享让外界知道

[TomVista]

@mcfog 还是大佬讲的明白
另外 大佬感觉用 graphql 实现数据库操作,可行吗? 我觉得不可行,又找不到合适的理由.

[mcfog]

@TomVista
我不太理解什么叫用 graphql(或 restful)实现数据库操作
你觉得不可行，但找不到理由为什么不可行的话，可以倒过来想想，这样做（比其他做法的）的好处在哪里，沙子造芯片是可行的，机器码写业务也是可行的

[TomVista]

@mcfog
前端按照固定格式 传给 后端,后端解析这个格式,然后实现数据库的增删改查,不限于 graphql /restful,
用 json 举个例子
{
tableName:user,
action:select,
keys:['userName','email','phone'']
}

{
tableName:user,
action:add,
data:{
userName:'tom',
phone:'1234'
}
}

优点:省个 curd body,前端放飞自我.
缺点: 除了 curd 干不了别的,鉴权没法做,事务也不行,数据库一旦到达瓶颈,就没救了.

[optional]

鉴权有 directive
1+n 问题有 dataloader

[optional]

@TomVista query 没必要开启事务，mutation 其实等于 data mutation 加 query 只需要关注 datamutation 部分的事务

[TomVista]

@optional
感谢,我再研究下,,,