XCFOX
2022-03-12 20:00:55 +08:00
正好最近在做的项目前后端深度使用 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 功能来帮助服务器主动发送消息。但是实践下来发现这个功能还是比较简陋的，不合适微服务架构和集群部署。