多年来，RESTful web服务一直在为简单查询结构提供基本支持。但是，这些服务没有提供对数据的细粒度控制，从而允许开发人员可以灵活运用而无需创建大量不必要的调用。

GraphQL最初由Facebook构建，它是用于API的查询语言，允许开发人员选择他们想要发出的请求类型，并在单个请求中接收所需的信息。

我在本文中将解释GraphQL是什么、它是怎样开始的以及它如何成为开发人员构建API的基本工具。我们还将介绍GraphQL的关键组件以及GraphQL生态系统中的主要参与者。

让我们开始吧！

GraphQL是什么？

按其最简单的形式来看，GraphQL是一种开源语言，用于从客户端应用程序查询数据库。

GraphQL的联合创建者Dan Schafer认为：

“GraphQL是一种查询语言，用于我们在客户端和服务器之间转移合约的API，允许服务器说‘这些是我公开的能力’，并允许客户端以一种方式来描述它们的要求，而这种方式最终使产品开发人员能够构建其希望创建的产品。”

在后台，它告诉API如何把检索到的数据呈现给客户端。这使开发人员能够发出精确的数据请求，以便他们接收的就是他们需要的东西——不多也不少。

以下是GraphQL为开发人员提供的主要好处：

准确地声明他们需要服务器所提供的内容，并以可预测的方法来接收请求的数据。
在单个请求中从服务器检索多个资源。
它是强类型的，也即：其允许API用户知道（1）有哪些数据可用，以及（2）数据以什么形式存在。

一个GraphQL查询本质上是一个字符串，发送该字符串到服务器后，返回JSON文件到客户端。这些查询快速应答了它们的响应，因此容易预测运行查询返回的数据的形状。另外，如果开发人员知道其应用程序所需数据的类型，那么，编写查询也就容易了。

与RESTful服务或SQL中复杂的连接语句不同，GraphQL是分层的。这意味着，其遵循对象之间的关系，适用于分层用户界面使用的图形结构数据。

GraphQL利用现有代码，而不是命令或提供数据存储。它意味着可以查询GraphQL服务器支持的类型，使得在这些信息之上构建工具变得容易。

借助GraphQL，返回数据的形状完全取决于客户端的查询。因此，可以容易地给服务器添加其他字段（比如，在添加新产品功能的时候），而不会影响现有的客户端。反之亦然。因此，当我们不再使用旧功能时，相关的服务器字段将继续工作，即使它们被弃用了。这样，GraphQL带来了向后兼容过程，不再需要增加版本号，这个功能很酷。

现在，我们对GraphQL是什么有了更好的理解，我们赶快来看看这一切是怎样开始的吧。

构建一个带数据库的即时GraphQL API，并开始探索一下这项技术的工作原理。

这一切是怎样开始的

GraphQL是怎样开始的？在GraphQL出现之前，开发人员在使用什么？它给他们带来了哪些限制？让我们来找出答案！

GraphQL是怎样开始的？

向移动的转变

GraphQL的起源可追溯到这个行业向移动的转变。当时，Facebook的移动战略（即，在移动设备上采用HTML5）由于网络的使用量过高而未能实现。结果，Facebook决定使用原生技术从头构建iOS应用程序。

在移动端实现Facebook新闻推送的是一个主要问题。这不是像获检索一个故事、作者、故事的内容、评论列表和喜欢该文章的人这么简单。每个故事都相互关联、嵌套和递归的。现有的API没有被设计成允许开发人员在移动设备上展示一个丰富、类似新闻推送的体验。它们没有层次性，允许开发人员选择他们所需要的，或有显示异构推送故事列表的能力。

在2012年，Facebook决定，他们需要构建一个新的新闻推送API，以构建Facebook的移动应用程序。这就是GraphQL开始成形的时间，并且，在8月中旬，Facebook发布了采用新GraphQL技术的iOS5.0应用程序。它允许开发人员通过利用其数据获取（data-fetching）功能来减少网络的使用。在接下来的一年半时间里，除了新闻推送外，GraphQL API扩展到大多数的FacebookiOS应用程序。在2015年，GraphQL规范首次与JavaScript中的引用实现一起发布。

传统REST API的局限性

传统REST API的主要问题是速度慢以及需要硬编码（hard-coding）。加快速度的一种可能解决方案是创建多个端点。但是，当我们把这个外推以覆盖所有数据来源和API客户端应用程序所需，我们就遇到了REST API的局限性问题。

让我用个类比来解释一下传统REST API的局限性。

比方说，我们有台自动售货机。在传统的REST里，我们在自动售货机上按一个按钮就会得到一样东西。因此，我们必须一次按多个按钮才能得到我们需要的所有东西，这个过程很慢。

但是，如果我们有个特殊用途的按钮，按它一次就可以得到多样东西。因此，比如，我们能够按一次一个特殊用途的按钮，就从自动售货机那里得到4样东西。

把这两种方法混合一下以获得这么一台自动售货机，我们可以以组合方式按下我们需要的按钮就可以一次性得到我们想要的一切。这就是GraphQL在做的。

GraphQL旨在通过拥有一个“智能”节点而不是很多“愚蠢的”节点来解决这些问题。关键的好处在于，智能节点能够执行复杂的查询，并按客户端的要求形成输出的数据。

本质上，GraphQL层存在于客户端和数据源之间。其任务是接收客户端请求，并根据客户端的要求获取必要的数据。简而言之，GraphQL查询方法解决了广泛的大规模应用程序开发问题。

GraphQL是如何流行开来的

正如我们可以想象的，业界已经存在对像GraphQL这样的解决方案的需求，这就是它这么快就流行起来的原因。在头6个月中，在不同编程语言中就都实现了GraphQL，这些编程语言包括PHP、JavaScript、Scala、Python和Ruby。

当新公司和爱好者开始构建它时，它就流行开来。最终，在2016年，更大的公司开始采用该技术，从GitHub开始，然后是推特、Yelp、《纽约时报》、Airbnb等公司。

GraphQL的主要组件

实际上，GraphQL API使用了3个主要的组件：

查询。查询是客户端发出的请求，查询字段可以指向数组及支持参数。
解析器。除非我们告诉GraphQL服务器该做什么，不然它不知道如何处理它得到的查询。这个工作是用解析器来完成的。简单地说，解析器告诉GraphQL如何（及从何处）获取与特定字段对应的数据。借助GraphQL，我们使用的API模式和数据库模式是解耦的。这允许我们使用它们作为变更解析器来修改我们数据库的内容。
模式。GraphQL模式描述了客户端一旦连接到GraphQL服务器就可以使用的功能。模式中的核心构建块被称为类型。

GraphQL生态系统

现在，我们来快速浏览一下GraphQL生态系统中的主要参与者。

GraphQL服务器

由于GraphQL只是个规范，因此，我们需要一些GraphQL服务器实现才能开始。

GraphQL-JS是GraphQL原始参考实现，可以与Express一起使用。
GraphQL-Server是Apollo的一体式GraphQL服务器实现，正在迅速获得关注。它可以从任何GraphQL客户端查询。
GraphQL-Severless是Back4App即时GraphQL API，完全集成了数据库（MongoDB）及云函数（Cloud Functions）。我们可以作为提供GraphQL API的服务访问后端。
GraphQL Yoga是构建于Express 和Apollo服务器上的Prisma的服务器实现。

GraphQL客户端

尽管我们可以直接查询我们的GraphQL API，但是，拥有一个专用的客户端库肯定会让事情变得更容易。

Relay是Facebook的JavaScript库，用以使用GraphQL构建React应用程序。
Apollo Client缓存请求并正则化数据，从而节省网络流量。它还支持分页、预取数据以及数据层和视图层之间的连接。

GraphQL网关

最流行的GraphQL网关可能是Apollo Engine。其功能包括：查询执行跟踪、查询缓存、错误跟踪和API性能趋势分析。

开源应用程序和工具

以下是一些使用了GraphQL的开源应用程序：

由GraphQL提供支持，Gatsby能够从多个GraphQL API获取数据，并用来创建静态的供客户端使用的React应用程序。
VulcanJS利用GraphQL，以允许用户快速地构建CRUD应用程序。
GraphQL Playground是个功能强大的IDE，可以为GraphQL查询、变更、订阅、验证等打包编辑器。它允许开发人员可视化模式的结构。
GraphiQL是个内嵌于浏览器的IDE，可以和GraphQL API进行交互，支持数据查询、执行变更及自动完成查询。

结论

尽管GraphQL的构建是用来解决Facebook针对iOS应用程序新闻推送API的一个非常具体的问题，但是，它很快扩展到Facebook内部，解决了更多的问题，并且，最终进行了开源，目前有很多大的公司采用的工具。

原文链接：

What is GraphQL: History, Components, and Ecosystem

创作场景

谈谈 GraphQL 的历史、组件和生态系统