选择 GraphQL 的 N 个理由

• GraphQL API 具有强类型模式
• 按需获取，扩展性强
  • Overfetching
  • Underfetching
• 支持快速产品开发
• Composing GraphQL API
• 有一个丰富的社区
• 我可以不用再写 SQL Server 代码
• 参考文献

选择它就是因为好用啊

GraphQL API 具有强类型模式

GraphQL schema 是一个约定，用于指明 API 的功能。

• 严格的 scheme 定义了 API 所支持的操作 (query, mutation, subscribe)
• API 文档会根据对应的 schema 自动生成，后端 API 的设定变得非常简单

按需获取，扩展性强

这个其实很直接，前端写了一段 query，query 里面直接确定所需要的数据

解决了传统 REST API 的两个典型问题：Overfetching 和 Underfetching

不必依赖 REST 端返回的固定数据结构。

对于老式数据查询 API 返回的固定的数据结构，我们甚至要在前端进行额外的处理

Overfetching

即返回的数据多于我所需要的数据

• 老式 API
  • 你有一个固定的后台可以接收特定的参数，根据参数决定返回的数据库数据
• GraphQL
  • 在前端的请求 query 中直接写我所需要的数据，这样就不会传过多的数据回来

Underfetching

即返回的数据少于我所需要的数据

• 老式 API
  • 我很可能要在请求一个借口得到需要的数据
  • 特别是类似于一些连接的数据
    • 比如先获得用户的数据，然后需要再根据每一个用户请求一次后台获取用户的文章数据
    • 这样明显就请求了多次
• GraphQL
  • 一次请求即可得到全部

支持快速产品开发

有很多对 GraphQL 支持的前端框架 (Apollo, Relay 等等)

甚至还有 GraphQl Faker 这样的工具，使得完全可以可以编码之前将 schema 全部设计好

Composing GraphQL API

API 的拼接

可以自由的将多个 API 进行拼接

并且可以进行嵌套式的查询

有一个丰富的社区

Express 等多个框架都有相应的中间件

调试工具也随着会不断的增多

我可以不用再写 SQL Server 代码

这个也可以算作是一个优势啊

参考文献

https://www.jianshu.com/p/03a7d390375d