GraphQL 是一种面向数据的 API 查询风格。
GraphQL来自 Facebook，如果你也跟我一样完全没了解过它，不知道它到底是干什么的，那么你可以把它想象成 SQL。
- 嗯，和
SQL一样，GraphQL是一门查询语言（Query Language） - 同样和
SQL一样的是，GraphQL也是一套规范，就像MySQL是SQL的一套实现一样 - 与
SQL不同的是，SQL的数据源是数据库，而 GraphQL 的数据源可以是各种各样的 REST API，可以是各种服务/微服务，甚至可以是数据库
传统的 API 拿到的是前后端约定好的数据格式，GraphQL 对 API 中的数据提供了一套易于理解的完整描述，客户端能够准确地获得它需要的数据，没有任何冗余，也让 API 更容易地随着时间推移而演进，还能用于构建强大的开发者工具。
GraphQL 优缺点
优点
- GraphQL 比其他通信 API 快得多
- 能够准确地获得它需要的数据，而且没有任何冗余，不多不少，避免前端 undefined 导致白屏的问题
- API 的聚合，一次请求拿到所有的数据（典型的 REST API 请求多个资源时得载入多个 URL，而 GraphQL 可以通过一次请求就获取你应用所需的所有数据）
- 完备的类型校验机制，它类似于 SQL，并在执行查询之前提供描述性错误消息
缺点
- 有学习成本，DSL 是一门新的语言
- 查询的复杂性。打个极端例子，如果前端一次请求一个系统所有的数据，是可行的，但是会造成后端的低效和性能问题（有解决方案，但是需要探索）。所以必须有一种机制，如最大查询深度、查询复杂度加权、避免递归或持久查询，以阻止来自客户端的低效请求。
- 用 GraphQL 实现一个简化的缓存比在 REST 中实现它要复杂得多。
- 速率限制。在 REST API 中，你可以简单地指定我们一天只允许这个数量的请求”，但在 GraphQL 中，很难指定这种类型的语句。
GraphQL 为我们解决了什么问题？
GraphQL 能减少前后端矛盾，让彼此更专注自身！
- 比如字段命名不合理
- 冗余字段
- 字段类型不合理（想要数组，却给的字符串，前端拿到还要转换一次）
个人观点
- 在以后端主导的 toB 项目中，GraphQL 几乎是不可能行得通的。（不可能前端来定义返回的数据内容）
- 既然如此，是否可以前端自己架设中间层，来过滤一遍后端的接口，最后返回给前端的都是前端想要的字段和数据（新的中间层，使用 TypeScript 开发，选用了 Egg.js 为框架，魔改了 egg-graphql 这个插件作为 GraphQL 服务的基础。提供实时规范的接口文档、0 配置 Mock 服务、动态配置且热更新等功能。） （有点类似 BFF 架构）
但是需要考虑接入成本的评估：
- 存在瞬间请求大量数据的可能，很容易拖垮数据库
- 可能很难推动后端实现
- 中间层的开发也是一个大问题，还要权限啥的
（所以接入成本还是很大的）