GraphQL 有什么优缺点

[Ayanokouji]

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

[Weny]

相对来说门槛高… 一般来说全栈会倾向选 graphql 。 生态也都很不错，我们在用的 urql,code-generator 可以做到前端包括小程序开发体验都是一致的。我们有一些小项目或者内部的项目，用 graphql 暴露了一套根据 entity 生成的 mongodb query dto 给到前端😂

[twocucao]

之前写过一篇文章, 结论大致是 1. 对前端来说很利好. 2. 但对后端来说, 问题蛮多的

- View 层代码组织剧变
- 权限问题
- 版本更迭
- required vs nullable vs blank
- 服务端缓存
- 嵌套式 API
- N+1 问题
- 为名所困

https://zhuanlan.zhihu.com/p/384196319

[loading]

云里雾里，我选择用普通 api 方式。

[ichou]

优点：
没人动不动找我改 api 了

缺点：
太难了
特别是 Apollo 引入的复杂度，导致在异常监控、限流、鉴权、缓存方面处理起来贼复杂

[OliveGlaze]

@reeco 多少能减少一些沟通成本。我觉得沟通成本也是工作量，不只是你的代码量才是你的工作量。

[ZSeptember]

@pluswu1986 准备搞 GraphQL ，想问下为什么会有复杂查询问题，Query 应该是后端可以控制提供的吧，可以确保 Query 都走索引，前端只是控制字段扩展什么的吧。
没有限制的话，不就是把整个 db 都暴露出去了吗

[ZSeptember]

@XCFOX Apollo 客户端一个项目，只能接一个 endpoint ？后端，准备搞点项目，用 GraphQL ，想的方案是一部分代理到已有的 GraphQL 服务，一部分新写。

[lixm]

沟通成本，代码生成， 其实完全可以用 openapi 规范来实现
GraphQL 对后端还是太不友好了

[Ayanokouji]

@ZSeptember graphql 跟数据库无关吧，我理解的，比如 rest 需要查 ID ，name 俩个字段，数据库是 id ，name ，age 三个字段，通常 orm 都是这三个字段都查出来，返回两个，graphql 的逻辑处理应该跟 rest 的一样，只不过 http 的 response 只返回 id 和 name 而已

[pluswu1986]

@ZSeptember 没法控制客户端用各种你想不到的姿势查聚合，而且默认 go graphQL AST 解析就贼慢，普通 HTTP 接口你可以针对特定 URI 做缓存提前聚合最主要时职责清晰谁接口慢就搞谁，不该给客户端的数据就不给，GQL 查询缓存得针对查询级别的然后防不住客户端查询拉不合理的数据，一个查询可能在复杂度超标不超标边缘作死，N 个查询就是大家都不行了