即 GraphQL 既是一个 API 查询语言，也指其服务端实现。但 GraphQL 不只是为了在 API 领域搞个类似数据库的查询语言，它的诞生更涉及到 API 设计的思路转变。

 

REST 模式的难题

 

通常，一项新技术的产生都会伴随着两个背景，一个是该技术所在的领域出现了新趋势、二是原有的技术难以应对新趋势。而近几年， API 领域有几个趋势愈发值得关注：

 

首先是日益增多的移动端应用，和移动端性能本身较低下的矛盾，要求数据加载过程更高效。

 

再者，要满足客户端和前端快速开发、快速添加特性的需求， API 必须能快速拓展。

 

第三则是各种不同的前端框架和平台层出不穷，而后端 API 服务面对众多的前端框架、乃至前端和客户端共享 API 的情况，其能否按需提供数据，会影响接口复用度和开发效率。

 

而现如今在 API 领域被广泛使用的 REST 模式，面对上述愈发复杂的客户端和服务端交互，问题也渐渐浮现：

 

首先是接口灵活性差。由于设计接口粒度较粗或历史遗留原因，接口中有时会存在当前数据交互不需要的字段，导致取到无用且多余的数据；而另一方面，有时前端需要一份数据，却需要手动访问多个接口才能完整获取。

 

第二是接口操作流程繁琐，回想下前端获取数据的过程，通常我们要先构造 HTTP 请求，然后接收和解析服务端响应。有时还要对收到的或处理后的数据另作本地数据转储，最后才进行 UI 展示。

 

第三，随着客户端功能拓展，服务端不断增加接口。这样维护众多接口，不仅服务端维护成本高，此外也不能按需提供数据、阻碍了客户端的快速迭代和拓展。

 

还有 REST 模式实质上是基于 HTTP 协议的，这虽让其易于被 Web 开发人员理解和上手，但也决定它不能灵活选择网络协议来解决问题。

 

GraphQL 的解决方案

 

面对 REST 模式的上述不足， Facebook 提出了他们的解决方案 – GraphQL ：

 

前面提到 GraphQL 既是一个 API 查询语言，也指其服务端实现，所以 GraphQL 本身也由两部分组成，Facebook 将它们分别开源：

 

语言标准： Open Web Foundation Agreement (OWFa) v1.0 协议

 

GraphQL.js、客户端工具Relay： MIT 协议

 

我们来逐条了解下 GraphQL 的特性：

 

声明式的数据获取

 

如下图所示，声明式的数据查询带来了接口的精确返回，服务器会按数据查询的格式返回同样结构的 JSON 数据、真正照顾了客户端的灵活性：

 

另外，这种数据获取方式也带来更简洁的数据查询流程。 GraphQL 认为，客户端只需描述查询结构发起查询，再把服务端响应数据用于 UI 展示即可。中间构造请求和转储数据的操作可以交由 GraphQL 客户端辅助完成。

 

一个服务仅暴露一个 GraphQL 层

 

上图是一个 GraphQL 应用的基本架构，其中客户端只和 GraphQL 层进行 API 交互，而 GraphQL 层再往后接入各种数据源。这样一来，只要是数据源有的数据， GraphQL 层都可以让客户端按需获取，不必专门再去定接口了。

 

传输层无关、数据库技术无关

 

带来了更灵活的技术栈选择，比如我们可以选择对移动设备友好的协议，将网络传输数据量最小化，实现在网络协议层面优化应用。

 

GraphQL 接入概览

 

既然 GraphQL 有诸多优点，那又该如何接入呢？大体上，有三种接入的方式：

 

直连数据库的GraphQL服务

 

最为简洁的服务配置，直接操作数据库也能减少中间环节的性能损耗。

 

集成现有服务的GraphQL层

 

这种配置适合于旧服务的改造，尤其是在涉及第三方服务时、依然可以通过原有接口进行交互。