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

Posted 2021-04-30 360linker

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了谈谈 GraphQL 的历史组件和生态系统相关的知识，希望对你有一定的参考价值。

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

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

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

No.1

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 出现之前，开发人员在使用什么？它给他们带来了哪些限制？让我们来找出答案！

No.2

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 查询方法解决了广泛的大规模应用程序开发问题。

No.3

GraphQL 是如何流行开来的

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

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

GraphQL 的主要组件

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

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