GraphQL 有什么优缺点

[Ayanokouji]

如果后端主导使用 GraphQL ，请问使用，还需要避免踩那些坑

[pupboss]

好处主要是可以省流量，省 http 请求次数，坏处其实挺多的，比如鉴权，限流，缓存，性能浪费

如果你感兴趣的话可以看看这篇：GraphQL 后端架构的经验分享 https://www.pupboss.com/post/2021/experience-sharing-of-graphql-backend/

[bojue]

@pupboss 现在采用的多不多，我们项目目前遇到的问题是都后端传递字段太臃肿了，每次后端修改字段要等待资源挺麻烦的

[zchlwj]

https://www.zhihu.com/question/38596306

[codehz]

缺点：自带自省功能（对于一些实现来说不是那么容易关闭），攻击者可以轻易获取所有 api （

[hooopo]

太难了

[pupboss]

@bojue 看你的描述好像是说向前兼容的问题，GraphQL 它本质上就是个 API 聚合器，后端该遇到的问题它一个也不会少（我好像还没遇到什么场景下 GraphQL 有碾压型的优势

[auh]

前端如果没有复杂业务。后端用这个，就是浪费。

[micean]

当需要一些关联的数据的时候，比较方便，相当于本来需要人工聚合的部分，框架帮你做了。
缺点主要是鉴权麻烦，至于安全问题，觉得暂不用考虑。

[XCFOX]

正好最近在做的项目前后端深度使用 GraphQL 。

优点：
1. 强类型文档。GraphQL 本身首先是一门语言，而且是强类型语言，目前社区已有各种语言与 GraphQL 转换的工具。实践中，前端配合自动生成工具和 TypeScript 能确切知道每个 Query 每个变量每个属性的类型，省去了以往 RESTful API 项目中前端手动声明类型的麻烦。使用如果后端使用 TypeGraphQL 或者 NestJS 这类框架，能直接从 TypeSCript 的 Class 生成文档(schema)。

2. 自动聚合。以往 RESTful API 的每个接口的数据都是预先设计好的，前端展示的数据和后端返回的数据有时匹配不上，复杂的业务往往需要一层 BFF 层来做数据聚合。GraphQL 的返回数据是由前端决定的，能有效降低前后端的数据耦合程度，并且减少接口调用次数。

3. 更细致的鉴权。RESTful API 的鉴权颗粒度只停留在路由上，但是 GraphQL 能控制每个字段的访问权限。（讲道理 RESTful 也能，无非实现起来麻烦点）

缺点：
1. 迁移成本高。
2. 生态不完善。如果后端要用 GraphQL 的话目前几乎只能选 Node.js 了。其他语言生态都不完善，缺少 dataloader 、federation 等关键包库。
其他方面我觉得和 RESTful 相比，GraphQL 简直完胜啊

坑：
1. 著名的 N+1 问题。对于后端来说，需要对每一个列表查询进行优化避免 N + 1 。目前流行的解决方案是 dataloader 。
2. 每个前端项目只能有一张 GraphQL schema 。这使得后端必须部署一个网关来整个各个微服务，目前几乎只能用 Apollo Federation 来解决这个问题。
3. Subscriptions 。Apollo 实现了 Subscriptions 功能来帮助服务器主动发送消息。但是实践下来发现这个功能还是比较简陋的，不合适微服务架构和集群部署。

[james122333]

就是省的多写逻辑重複的 api 然后只是部分回传不同字段 一般 api 前面写个过滤器根据规则过滤一样效果 省流量倒是没有 因为你数据库是一大笔资料取出来 除非架设在一起 然而整理代码也不是不可以

[james122333]

好处应该是节省 api 串接沟通成本 但其实整个结构对照并且有测试查寻页面也差不多了

[james122333]

这东西其实是大而全的 涵盖不只一个功能
虽然意义不大但要用也可以 毕竟是方案型
不爱就是

[masterclock]

优点
一大堆

缺点
说法不了：REST/JSONRPC/XXX 就行啊

@XCFOX 主要语言对 GraphQL 的支持都很好了，
golang 支持 dataloader ，1.8 后就有泛型 dataloader 可以用了
golang 也支持 Apollo Federation ，另外还有个库支持 Subscription 的 federation

[Mithril]

如果你要对接的 API 消费者，不只是跟你在同一个地点工作的前端同事，他们的需求也不是你们组定的，那么 GraphQL 可以显著减少沟通成本和你自己的开发成本。
其他情况 RESTful 能遇到的问题，GraphQL 也一样能遇到。并不会省多少事。
但同样的，RESTful 或者瞎写的接口能做到的，GraphQL 也一样可以做。不止 NodeJS ，其他语言，至少我用过的 C#和 Java 的 Client ，功能也都很全。

[iseki]

dataloader 也不能解决全部问题，只是粗暴的把 key 聚合起来一次查询而已。整体来看迁移成本太高了，将整个查询控制交给前端，前端给出啥样的查询完全不可控，很容易把后端搞死······

[reeco]

对后端来说，这玩意除了增加工作量外没有一点好处，想不明白哪个后端会来主导用 graphql

[SjwNo1]

N+1 问题，其他应该都还好吧。
( dataloader 并不能很好地解决这个~)

[pluswu1986]

@iseki 被搞死。。相当于让客户端写 sql 查询 db 。。反正我们这 go 的 gqlgen 查询一复杂就经常被搞死。。。。

[ericls]

怎么都比 restful 好

[iseki]

传统 API 模式的好处是 API 相对固定，查询模式往往派生自 API ，也相对固定，便于实现和优化； graphql 这种会导致查询模式完全由前端传递，后端进行限制和优化难度陡增。想想是手动实现优化与一个 SQL 等价的查询容易还是编写一个通用的查询优化器容易～ dataloader 相对缓解这个问题，但是彻底解决我看够呛