为什么选择 GraphQL？

最初于 2020 年 6 月 2 日发布于https://www.wisdomgeek.com 。

对于开发者来说，开发 Web API 从来都不是一件容易的事。过去十年来，REST 一直是 Web API 设计的事实标准。鉴于 REST 的广泛流行，任何人在阅读 GraphQL 时，脑海中浮现的第一个问题都是：为什么要使用 GraphQL？既然开发者已经精通 RESTful 架构，为什么还需要 GraphQL？

GraphQL 是新生事物，而 REST 则是经验丰富的老将。我们需要了解 GraphQL 诞生的原因。在深入探讨原因之前，我们先来了解一下它是什么。

什么是 GraphQL？

GraphQL 代表图查询语言 (Graph Query language)。它是 Facebook 为 Web API 创建的查询语言。它与 REST 一样，通过 HTTP 运行。需要注意的是，它只是一个规范，而不是一个实现。这意味着我们可以使用任何编程语言、任何数据库以及任何客户端来实现 GraphQL。

GraphQL 并非一种架构模式，也不是一种 Web 服务。它仅仅充当一个薄的中间层，支持声明式数据获取，让客户端能够指定所需的数据。GraphQL 并非 REST 的替代品，而是一种替代方案。我们可以将它与 REST 结合使用，也可以不结合使用，这取决于我们自己。

GraphQL 在哪里发挥作用？

GraphQL 的主要重点是优化网络请求，以便仅获取客户端所需的数据（防止获取不足和过度）。这是 GraphQL 开发过程中关注的关键领域。这个问题的出现是因为用户期望在所有设备和平台上都能获得高质量的个性化体验，这提高了门槛。REST 端点对于这类客户端来说并非理想之选，因为 REST 更像是一种点对点的过程式 API。如果某个设备只需要某些特定数据，开发人员要么必须创建另一个端点来仅返回特定数据，要么必须在输入参数中添加一些布尔字段来指定所需内容。最终，这对于大型应用程序来说变得过于复杂，难以处理。

GraphQL 尝试解决 REST 的哪些问题？

GraphQL 的主要优点是：

• 速度
• 灵活性
• 便于使用
• 维护简单
• 对开发者友好

让我们深入了解 GraphQL 如何解决这些问题。

GraphQL 更快

让我们看看如何使用 REST 构建博客应用程序。

对于像本文这样的简单博客文章，我们需要获取需要显示的文章详情。因此，我们将为此发出 GET 请求。假设这篇文章的 ID 为 1。然后，我们将向某个端点（例如 GET /posts/1）发出请求，以获取关于这篇文章的所有相关详情。

但我们还需要获取这篇博文的所有评论。为此，我们还需要发送另一个 GET 请求。类似 GET /posts/1/comments。

我们还会在下面显示一些相关文章。因此，我们需要另一个 GET 请求。假设我们有一个端点，它接受要显示的文章类型，并将文章 ID 作为查询字符串参数。这需要另一个 GET 请求 /posts?related=1。

这最终为我们提供了显示此页面所需的一切。整个过程如下所示：

现在，如果我们要从 GraphQL 端点获取相同的数据，则不需要那么多 HTTP 请求。我们将查询单个端点（即 /graphql）。并且我们将向此端点发出 POST 请求，描述我们需要从服务器获取的所有信息。在我们的例子中，我们查询帖子信息、评论信息和相关文章。我们将以 GraphQL 查询的形式请求这些信息。

本文不会深入探讨 GraphQL 查询的具体细节，因为本文主要讨论的是“为什么”使用 GraphQL，而不是“如何使用”。但它最终的样子是这样的：

重要的区别在于，不再由服务器决定返回哪些数据，而是客户端描述其所需的所有数据。服务器只需一次请求即可返回所有信息，而无需发出多个请求。

不存在任何数据的过度获取或不足。因此，GraphQL 查询比 REST 更快。

GraphQL 非常灵活

这或许是 GraphQL 相对于 REST 的最大优势。

在上面的例子中，我们本可以将所需的所有信息放在一个 REST 端点中，因为我们知道所有这些信息都是博客文章所必需的。我们也可以像 GraphQL 解决方案一样，将所有这些信息塞进一个端点 GET /posts 中，该端点将返回所需的所有信息。

这种方法本身完全有效。但是，如果我们想添加其他内容该怎么办？比如说，我们想显示此帖子作者的其他帖子？我们就必须在创建的端点中更改很多内容。如果我们想有条件地显示这些内容怎么办？我们必须在其中添加另一个参数作为查询字符串。

让我们再举一个例子，针对同一个端点。在移动设备上，我们不想获取评论和相关文章。所以我们不想在用户滚动到页面底部之前访问这些端点。但是，我们已经将所有内容都塞进了桌面版的单个端点。如果我们向该端点发出请求，就会过度获取数据，从而损害用户体验。

在这些场景中，GraphQL 非常方便。由于客户端描述了所需的数据，GraphQL 提供了一种灵活的方式来查询所需的信息。查询可以根据客户端和页面所需的信息进行修改。如果我们需要按作者获取帖子，我们可以将其添加到 GraphQL 查询本身中。

客户有权精确定义其所需的数据，不多不少。

GraphQL 易于维护且易于使用

正如您在上面的示例中看到的，我们需要向 REST 应用程序添加许多新的端点和查询字符串参数，以适应博客文章等简单场景。

但在 GraphQL 中，它只是一个端点，客户端可以定义它需要什么。因此，它更容易维护。客户端只需更改其查询，服务器就会做出相应的响应。

这种方法确实也带来了一些挑战，例如嵌套调用等问题。但总的来说，它比 REST 端点更易于维护。

GraphQL 对开发人员友好

GraphQL 还引入了强类型系统，可让您避免在获取数据时出现错误。

GraphQL 查询使查询语言成为一种定义和从服务器获取数据的声明式方式。这有助于理解从服务器获取的所有数据。

只要您的模式向后兼容，GraphQL 还可以消除维护 API 单独版本的麻烦。

所有这些点结合在一起，为开发人员带来极佳的体验。

GraphQL 会取代 REST 吗？

虽然 GraphQL 相较于 REST 有很多优势，但这并不意味着 GraphQL 就是灵丹妙药。REST 有很多优势是 GraphQL 无法实现的，例如 HTTP 内容类型、HTTP 缓存、状态码、管理复杂查询以确保它们不会进行昂贵的连接、监控端点等等。

我们需要了解两者之间的权衡，并同时掌握这两种工具。然后，我们可以根据正在构建的应用程序及其需求选择正确的工具。

如果您有兴趣了解有关完整堆栈、React、Relay 和 GraphQL 生态系统的更多信息，您可以查看该帖子。

请在评论区分享你对 GraphQL 的看法。你会在下一个应用中使用它吗？