选择 GraphQL 的5大原因
文章目录

就因为好用我就选择它这句话还不够吗?

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 代码

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

不过再怎么好的东西都有一些弱点

GraphQL 麻烦的地方: Error Handling

REST server 可以完全控制 Error 的流出:

  1. 提供非常详细的错误信息
  2. 可以提供不同的错误码
    1. 200 OK
    2. 404 FNF
    3. 500 Server Error

然而在 GraphQL 之中, 因为中间多了一层,所以对应的错误类型就增加了很多

  • Server problems (5xx HTTP codes, 1xxx WebSocket codes)
  • Client problems like rate-limited, unauthorized, etc. (4xx HTTP codes)
  • Query is missing or was malformed
  • Query fails GraphQL internal validation of syntax, schema logic etc.
  • User-provided variables or context is bad and resolve/subscribe function shows an error
  • Developer error occurred inside the resolve/subscribe function

解决 GraphQL Error Handling 的方案

  1. 返回纯净的信息
    • 如果返回的数据那么意味着绝对没有错误, 这时候我们仅返回 data 而不包含 error 以及 msg
    • 如果返回的错误那么意味着就一定没有数据, 这时候就不返回 data 我们单纯返回 error 以及 msg
    • 当然在这种情况下,前端要进行一定的适配
  2. Schema 进行一些 Validation 并且可以预设一些 error
    1
    2
    3
    4
    5
    6
    7
    8
    return {
    error:{
    id:'222'
    type:'errorType'
    title: 'Name of an error'
    message: 'Let user know what's wrong how to fix'
    }
    }

参考文献

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