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

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

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

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

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

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

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

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

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

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

鉴权有 directive
1+n 问题有 dataloader

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

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