Question

1.1 简介

GraphQL 是一种新的 API 的查询语言，它提供了一种更高效、强大和灵活 API 查询。它 是由 Facebook 开发和开源，目前由来自世界各地的大公司和个人维护。GraphQL 对你的 API 中的数据提供了一套易于理解的完整描述，使得客户端能够准确地获得它需要的数据，而且 没有任何冗余。它弥补了 RESTful API（字段冗余，扩展性差、无法聚合 api、无法定义数据 类型、网络请求次数多）等不足

注意：GraphQL 是 api 的查询语言，而不是数据库。从这个意义上说，它是数据库无关的， 而且可以在使用 API 的任何环境中有效使用，我们可以理解为 GraphQL 是基于 API 之上的一 层封装，目的是为了更好，更灵活的适用于业务的需求变化

GraphQL 可以用在常见各种服务器端语言以及客户端语言中

• 服务器端语言：C# / .NET、Clojure、Elixir、Erlang、Go、Groovy、Java、JavaScript、PHP、Python、 Scala、Ruby
• 客户端语言：js、React + React Native、Angular、Vue.js、Apollo Link、Native iOS、Native Android、 Scala.js
• 中文文档： http://graphql.cn
• Github: https://github.com/facebook/graphql

GraphQL 出现的历史背景

当提起 API 设计的时候，大家通常会想到 SOAP（一种简单的基于 XML 的协议），RESTful 等设计方式，从 2000 年 RESTful 的理论被提出的时候，在业界引起了很大反响，因为这种 设计理念更易于用户的使用，所以便很快的被大家所接受。

我们知道 REST 是一种从服务 器公开数据的流行方式。当 REST 的概念被提及出来时，客户端应用程序对数据的需求相 对简单，而开发的速度并没有达到今天的水平。

因此 REST 对于许多应用程序来说是非常 适合的。然而在业务越发复杂，客户对系统的扩展性有了更高的要求时，API 环境发生了巨 大的变，RESTful 显得心有余而力不足。比如：字段冗余，扩展性差、无法聚合 api、无法 定义数据类型、网络请求次数多

GraphQL 的出现整好弥补了 RESTful APi 的不足

使用 GraphQL 的公司

目前已经有很多的公司在使用 GraphQL（ https://graphql.org/users/ ）

1.2 为什么推荐 GraphQL 而不是 RESTful API

在过去的十多年中，REST 已经成为设计 web api 的标准（虽然只是一个模糊的标准)。

它提供了一些很棒的想法，比如无状态服务器和结构化的资源访问。

然而 REST api 表 现得过于僵化，无法跟上访问它们的客户的快速变化的需求

RESTful API 不足

• 扩展性（多个终端需要返回不同的字段），单个 RESTful 接口返回数据越来越 臃肿。前端对于真正用到的字段是没有直观映像的，仅仅通过 url 地址，无法预测也无 法回忆返回的字段数目和字段是否有效，接口返回 50 个字段，但却只用 5 个字段，造 成字段冗余，扩展性差，单个 RESTful 接口返回数据越来越臃肿
• API 聚合问题，某个前端展现，实际需要调用多个独立的 RESTful API 才能获 取到足够的数据，导致网络请求次数多
• 前后端字段频繁改动，导致类型不一致，错误的数据类型可能会导致网站出错 尤其是在业务多变的场景中，很难在保证工程质量的同时快速满足业务需求

GraphQL 的优点

• 吸收了 RESTful API 的特性
• 所见即所得 各种不同的前端框架和平台可以指定自己需要的字段。查询的返回结果就是输 入的查询结构的精确映射

客户端可以自定义 Api 聚合

如果设计的数据结构是从属的，直接就能在查询语句中指定;即使数据结构是独 立的，也可以在查询语句中指定上下文，只需要一次网络请求，就能获得资源和子 资源的数据。

代码即是文档

GraphQL 会把 schema 定义和相关的注释生成可视化的文档，从而使得代码的变更，直接就反映到最新的文档上，避免 RESTful 中手工维护可能会造成代码、 文档不一致的问题

参数类型强校验

• RESTful 方案本身没有对参数的类型做规定，往往都需要自行实现参数的校验机制， 以确保安全。
• 但 GraphQL 提供了强类型的 schema 机制，从而天然确保了参数类型的合法性