有用过 GraphQL 的吗？可以进来说说相比 restful 的优劣吗?

[ReinerShir]

在使用 restful 中，经常发现无法严格按照 restful 规范来设计，结果就是慢慢的变成的一个仅仅是看起来像是 restful 的设计

因此网上找资料发现了 GraphQL，它可以大量节省请求次数，返回字段由前端决定，也不用写文档了，初步了解之下感觉很不错。

但转念一想可能没这么简单，有没有用过的大佬来说说它有什么坑？

相比 restful 的优劣有哪些？

[wwwap]

debug 挺麻烦的, 开发者工具里全是 /api/graphql 的请求，只有点开看 request 和 response 才能搞清谁是谁。

[dk7952638]

graphql 爽不爽主要看两点，
一是调用端愿不愿意接受，虽然很简单，体验很好，但是总有一群人，学习个新东西比杀了他们还难，
第二是后端实现一个完整的 graphql 服务其实复杂度很高，做缓存也比较难，对后端团队的技术要求很高，错误的实现方式反而会让问题更复杂，
另外还有一点，graphql 的生态比较完善的是 node，而国情目前还是 java 天下，
综上所述，这东西在已经有自己的技术栈或者权力比较分散的大公司比较难推，小公司小团队可以试试

[linoder]

graphql 适合企业级后台 别的场景真不适合 ……

[KIMMG]

我从 restful 过渡到了 graphQL 。

这里说说感受，restful 实际上是一种约束，它约束 API 设计应该遵循资源规范。用户资源和订单资源是分开的。
但这种设计是方便后端的，按照这种设计，由于业务的组合，前端需要多次发起调用不同资源的 api，就很繁琐了。
实际业务中很难严格遵守这种规范，导致 /users/{id}/orders/{id} 这种情况经常出现。
甚至 /users/getUser 这种完全不是 restful 风格的 api 的出现。

而 graphQL 的结构声明，其实也是 restful 思维的扩展。

现实是，api 的设计过于随意，graphQL 中结构的声明也很少遵从设计原则。依旧是导致资源嵌套很深。
到头来写的二不像。

[binux]

aip.dev

[xuanbg]

graphQL 没有解决任何问题，反而增加了系统的复杂度。前端发明的东西经常如此。

[keepeye]

只要对整体有利，那就值得，不能光考虑前端调用方便而忽视后端的难度增加

[janxin]

GraphQL 和图的关系了解一下，所以可以建模为图关系的都可以用

不过问题是由于耦合很大，所以会导致优化起来难度远比 Restful 方案更麻烦

[nigelvon]

用了 3 年多了，现在内部项目全部上 GraphQL，版本迭代速度快了很多。接口性能也有大幅上升。底层微服务提供粒度很小的 API，方便做缓存，中间层用 GraphQL 组装数据，前端按需调用，爽得飞起。

[Desiree]

@xuanbg 你用过吗？

[ReinerShir]

@nigelvon 我明白了，你的架构是低层服务访问数据库，api 走 restful，非常分散的那种，中间层做业务逻辑，负责接收前端请求然后调用低层服务，但是这样其实还是多次调用，只不过中间层把它封闭了而已，不知道我理解得对不对。

[uselessVisitor]

要前端参与业务设计，相当于后端一个大接口，到 GraphQL 按需选取数据

[jsq2627]

近 1 年都在和 GraphQL 打交道，接触的方面包括：
1. 前端 apollo client 和后端 node.js apollo server 打交道，后端是重业务代码
2. 前端 apollo client 和后端 graphql ruby 打交道，后端也是重业务代码
3. 前端 react query 和后端 node.js apollo server 打交道，后端是 BFF 层

总结一下个人对 GraphQL 评价
优点：
- schema-driven 的开发流程，衍生出一系列好处：代码生成、精确的接口文档。类比 RESTful 的 swagger 。
- 很容易实现 field 粒度的 ACL
- 良好的类型系统，对 normalization 、cache 、codegen 等都非常友好
- 有官方 spec，不像 RESTful 有各种不同的解读方式（尽管 spec 没有提到分页，但 relay style 已经成为了事实标准）

缺点：
- 各类 HTTP debug 工具支持都很弱
- 大规模 scale out 的实践比较少，缺少成熟的基础设施（ gateway，细粒度监控，日志，限流，等等）
- 很难利用 HTTP cache，需要前端自己实现 cache 系统
- 服务端 n+1 查询问题
- 和 RESTful 一样，只是一种工具，没有官方范式。有人会写嵌套很深的 field，有人会像 RESTful 一样全部扁平化，甚至有人写出来是 RPC style （我见过 root query 顶层 field 全部是 `getXxxByXxx` 的命名风格）
- 使用最广泛的 apollo-client 至今稳定性欠佳，bug 很多

[jsq2627]

有个印象很深刻的项目，充分使用 apollo-client 的 cache 后，前端状态管理变的非常简单（一般业务项目，所谓前端状态管理，基本就是把 fetch 回来的数据存到 store 里面； apollo 的 cache 已经帮你全搞定了）。
这个项目最后只用了 React 原生 hooks / useReducer / context 做状态管理，以及一小部分 apollo local state 。

[forgottencoast]

@ReinerShir
你是说的前端吗？反正后端是不会手工拼参数的。
对于后端来说，如果需要大概都会使用类似 AddParameter(A, a)的方法来手动添加参数。
因为对于 HTTP 规范来说，参数的形式都是一样的：
A=a&B=b&C=c
GET 和 POST 的区别在于放在 header 还是 body 。

[IvanLi127]

很好用，前后端都能省很多事，就是后端这边，关联查询的性能好像不是很好优化。

[xuanbg]

@Desiree 这个还需要用过才知道吗？前端需要的数据是和页面匹配的，一个页面一个特定的接口获取数据难道不是最简单也是最合适的做法吗？这个数据的内容和形式，由前端决定还是前后端协商决定，这个数据难道会有丝毫的不同吗？

[leeg810312]

graphql 是客户端驱动开发，我的理解是他的目的是为了最小化客户端向后端请求，小项目可能比较容易做，大型项目对系统交互设计要求很高，而且要有很强的后端团队才能用好，否则系统性能和运维会有很大问题

[masterclock]

@Desiree 一个页面一个特定的接口？
对前端来说肯定是最美好的世界，但后端怎么办？一个页面很多都会包含来自多个模块、服务、系统的数据，后端怎么办？前端增减页面、页面中的数据，后端一起改？
由前端决定还是前后端协商决定，这个数据确实会不同啊，前端肯定想着一个 API 拿到所有格式化好的数据，后端肯定想拿到砍人啊

[wwk]

增加了复杂度，并且目前缺乏好的工具链来搭配使用。