选择 GraphQL 的 N 个理由
最初发布于 szhshp的第三边境研究所, 转载请注明
选择它就是因为好用啊
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 全部设计好
扫描二维码关注公众号，回复：
6946350 查看本文章
Composing GraphQL API
API 的拼接
可以自由的将多个API进行拼接
并且可以进行嵌套式的查询
有一个丰富的社区
Express 等多个框架都有相应的中间件
调试工具也随着会不断的增多
我可以不用再写 SQL Server 代码
这个也可以算作是一个优势啊