在开发服务端接口的时候接触到 GraphQL 这个名词,故而有了这篇文章。因为初始,所以整理过程难免有些错误和疏漏,请留言告知。在我们面对一个新的名词,或者一门新的技术时,了解的过程可以分成这么几部分,他是什么,他解决了什么问题,他和目前同类型的技术相比优势在哪里,这样几个部分去看也就能够比较粗略,但是快速的了解一样新东西了。所以这篇文章的组织结构也以这样的方式进行。

GraphQL 是什么

GraphQL,很容易让人想起来 SQL,其实也很类似,可以理解为是一门查询语句,但和 SQL 不同的是,SQL 是查询关系型数据库,而 GraphQL 是查询 WEB 服务数据。GraphQL 是有 Facebook 开发开源,设计主要是为了解决 RESTful 接口的不足。

RESTful 在设计时,将互联网上的每一个内容都理解为资源,通过 HTTP 不同的请求方法来对资源进行增删改查,而 GraphQL 则是通过客户端自主使用查询语句来获得资源。GraphQL 并不是一门语言或者框架,而是请求数据的一种规范,协议。GraphQL 本身并不直接提供存储管理功能,也不和任何数据库绑定。

GraphQL 解决了什么问题

RESTful 接口遇到的问题

  • RESTful 接口数据格式由后端约定,调用者无法修改数据格式,只能够做适配和容错
  • 随着系统和业务变化,RESTful 接口数量爆炸式增长,不利于维护
  • 创建大而全的接口不仅影响调用速度,也浪费了移动端传输流量
  • 很多情况下客户端只需要某一个接口中特殊几个字段,但是 RESTful 会将整个数据格式返回
  • RESTful 接口在开发时需要相应的维护一套文档,而更新接口时可能导致文档修改不同步

特点

GraphQL 有如下特点:

  • 强类型,所有类型都需要预先定义
  • 服务端根据客户端提供的查询语句返回对应的 JSON

GraphQL 对外提供只有一个接口,所有请求通过该接口处理,GraphQL 内部做了路由处理。查询语句主要分为两大类,Query 查询,Mutation 修改(非幂等操作,post,put,delete 等)

比如客户端有如下查询语句

query {
  user(id: 1) {
    id
    name
  }
}

服务端返回

{
  "data": {
    "user": {
      "id": "1",
      "name": "Uncle Charlie"
    }
  }
}

服务端会返回一个和查询一致的 JSON 字串。

关于 GraphQL 的类型系统,标量类型,对象类型那就自行查看文档即可。

如果你看到这里想要亲手体验一下,那么可以访问 GitHub 提供的在线查询工具

GraphQL 和 RESTful 比较

针对上面 RESTful 出现的问题 GraphQL 的解决方案:

  • GraphQL 是强类型,需要前后端事先约定
  • GraphQL 不会随着业务发展而接口数量暴增
  • GraphQL 的调用完全由客户端控制,不会产生无用传输流量
  • GraphQL 会根据定义好的类型系统自动生成说明文档,省去了文档同步更新的麻烦

其他扩展

reference