GraphQL 初探—面向未来 API 及其生态圈

GraphQL 初探—面向未来 API 及其生态圈

 

什么是 GraphQL ？第一次看到这个名词未免让人联想到数据库查询语言 SQL 。但本质上，这是两个完全不同的东西， GraphQL 在官方文档里的定义如下：

GraphQL is a query language for your API, and a server-side runtime for executing queries by using a type system you define for your data.

即 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 (OWF