为什么 GraphQL 是 API 的未来

自 Web 诞生以来，开发 API 对开发者来说一直是一项艰巨的任务。我们开发 API 的方式必须与时俱进，才能始终构建出优质、直观且设计精良的 API。

近几年，GraphQL 在开发者中越来越受欢迎，许多公司也开始采用这项技术来构建 API。GraphQL 是 Facebook 于 2012 年开发的一种查询语言，并于 2015 年公开发布。它已经获得了广泛的关注，并被许多大公司采用，例如 Spotify、Facebook、GitHub、NYTimes、Netflix、沃尔玛等等。

在本系列教程中，我们将研究 GraphQL，了解它是什么，并看看哪些特性使这种查询语言如此直观和易于使用。

那么，让我们先来探讨一下 REST 的问题，以及 GraphQL 如何解决这些问题。我们还将探讨为什么许多公司都选择使用 GraphQL 构建 API，以及为什么它是 API 的未来。

哦，休息

很久以前，当我们将 API 设计从 SOAP 改为 REST 时，我们认为这一举措将为开发人员的工作带来更大的灵活性。不可否认，这一举措在一段时间内效果显著，在当时是一个明智的举措。随着应用程序和 Web 变得越来越复杂，API 自然也随之演进。

然而，REST 确实存在很多问题。让我们看看它们是什么：

很多端点

REST 中的每个资源都由一个端点表示。因此，在实际应用中，我们会为不同的资源创建多个端点。如果要发出 GET 请求，则需要一个特定于该请求的端点，并指定相应的参数。如果要发出 POST 请求，则需要另一个专门用于该请求的端点。

但是，这有什么问题呢？假设我们正在构建一个像 Facebook 这样的大型社交媒体应用。我们最终会有很多端点，这意味着开发人员需要花费更多的时间来开发和维护这些 API。

信息的过度获取和获取不足

一个让很多开发者苦恼的问题是通过 REST API 过度获取信息或获取不足。这是因为 REST API 总是返回固定的结构。除非我们为此创建特定的端点，否则我们无法准确获取所需的数据。

因此，如果我们只需要一小部分数据，就必须处理整个对象。例如，如果我们在 REST API 中只需要获取用户的firstName、lastName和 ，age那么如果不获取整个对象，我们就无法准确获取这些数据。

信息获取不足也存在问题。如果我们想从两个不同的资源获取数据，就需要对两个不同的端点进行不同的调用。在大型应用程序中，这种方式的扩展性很差，因为有时我们只需要获取特定的数据，而不是整个对象。现在，假设我们正在构建一个包含 100 个端点的应用程序。想象一下我们需要编写的工作量和代码量。随着时间的推移，这将变得越来越困难。代码也会变得难以维护，开发人员在这个过程中会感到不知所措。

版本控制

在我看来，REST 的痛点之一是版本控制。在 REST API 中，经常会看到很多 v1 或 v2 版本的 API，但在 GraphQL 中，不需要版本控制，因为你可以通过添加新类型或删除旧类型来改进 API。

在 GraphQL 中，您只需编写新代码即可改进 API。您可以编写新的类型、查询和变更，而无需发布 API 的另一个版本。

因此，您将不会看到具有如下端点的 GraphQL API：

https://example.com/api/v1/users/12312

https://example.com/api/v2/users/12312

为什么 GraphQL 是未来

早在 2012 年，Facebook 在开发移动应用程序时就遇到了一个问题，这促使他们创建了 GraphQL。这些问题非常常见，尤其是在我们讨论 RESTful API 设计时。正如所讨论的，这些问题包括：

• 表现不佳
• 很多端点
• 数据过度获取或获取不足
• 每次我们需要添加或删除某些内容时，都会发布另一个版本
• 难以理解 API

结合诸多概念，Facebook 的开发者们开发出了一种更好的 API 设计方法，后来将其命名为 GraphQL。从本质上讲，它是 REST 的替代品，并且进行了大量改进。

GraphQL 为我们带来了许多新功能，让您在构建 API 时拥有超强的能力。让我们逐一了解一下：

单一端点

无需构建大量端点！使用 GraphQL，我们只需一个端点，即可通过单个请求获取任意数量的数据。基本上，GraphQL 将您的所有查询、变更和订阅都封装在一个端点中，供您使用。它可以缩短您的开发周期，因为您无需发出两个请求来从两个不同的资源获取数据。此外，假设我们正在构建一个大型应用程序，我们不会像 REST 那样需要大量的端点和代码。我们将获得一个端点，并且通过该端点我们可以发出任意数量的请求。

另外，正如我上面所说，“仅端点”方法可以使您的 API 自带文档，因为您无需构建文档，因为您的开发人员已经知道如何使用它。他们只需查看代码或查看 Playground 即可理解 API。我们将在稍后（本系列的下一个教程）进一步学习。看起来很神奇，但这仅仅是 GraphQL！

使用 GraphQL，你只获取所需的数据

不再出现信息过度获取或获取不足的情况。您只需获取所需的数据。还记得我们最初讨论过的性能问题吗？GraphQL 提升了 API 的性能，尤其是在网络连接较慢的情况下，这个问题已经不再存在。

GraphQL 使构建 API 和保持一致变得简单

很多人认为 GraphQL 非常复杂，因为它涉及一个架构和一个端点。一旦你开始用它开发 API，你就会发现它比你想象的要简单。“仅端点” API 在开发网站/应用时非常有用。它使你的 API 更加自文档化，你无需编写大量文档。

如果您不使用 JavaScript 作为主要语言，那也没问题，因为 GraphQL 是一种不可知查询语言，这意味着您可以将它与任何语言一起使用。在撰写本教程时，GraphQL 已支持超过 12 种语言。

GraphQL 代表未来

GraphQL 是一种开源查询语言，这意味着社区可以为其做出贡献并对其进行改进。当 Facebook 将其发布到社区时，它获得了开发者的广泛关注和认可。现在，随着越来越多的开发者开始使用它构建 API，GraphQL 正在快速发展。然而，一些人一直在质疑它是否真的会取代 REST，或者成为为实际应用程序构建 API 的新方式。

起初，我以为 GraphQL 只是炒作，只是另一种创建 API 的方式。然而，当我开始研究它时，我发现 GraphQL 具备为现代应用程序创建现代 API 所需的基本功能，因为它与现代技术栈配合得很好。

所以，如果我现在要告诉你的话，那就是：是的，GraphQL 确实是 API 的未来。这就是大公司押注它的原因。

2018 年 11 月，GraphQL 与 Linux 基金会合作创建了 GraphQL 基金会，这意味着该查询语言正在鼓励其开发者构建更多文档、工具和支持。该基金会将确保 GraphQL 拥有稳定、中立和可持续的未来。因此，这也是我们认为 GraphQL 是 API 未来的另一个原因。

当然，它不会立即取代 REST，因为许多应用程序仍在使用它，而且不可能一夜之间重写它们。随着越来越多的公司采用 GraphQL，用户体验 (UX) 和用户体验 (DX) 都将得到改善。

结论

GraphQL 代表着 API 的未来，我们需要深入了解它。因此，我决定创建一系列 4 个教程，从查询和修改开始，到订阅和身份验证，展示如何充分利用 GraphQL 的精髓。

本文最初发布于 Hashnode。如果您喜欢这篇文章，也欢迎在那里阅读，这样您就可以支持我并帮助我撰写更多文章！您可以在这里阅读！