为什么GraphQL是API的未来[每日前端夜话0x50]

自从 Web 开始迅猛发展，对程序员来说开发 API 是一项很艰巨的任务。我们开发 API 的方式必须随着时间的推移而发展，以便我们始终可以开发良好、直观且设计良好的API。

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

在本系列教程中，我们将研究 GraphQL，了解它是什么，并学习使这种查询语言如此直观和易用的原因是什么。

先让我们研究一下 REST 存在的问题，以及 GraphQL 如何解决它们。我们还将了解那些大公司为什么用 GraphQL 去构建API，以及为什么它是 API 的未来。

REST

很久以前，当我们把 API 的设计从 SOAP 转向 REST 时，认为此举将会为工作提供更多的灵活性。我们不能否认 REST 的运作是良好的，在当时是一个很好的举措。但是随着应用和 Web 变得越来越复杂，API 也会随着这些变化而发展。

不过 REST 也确实存在很多问题。让我们看看它们是什么：

太多的端点

REST 中的每个资源都由端点表示。因此，在实际的程序中，我们最终会为这些资源提供大量端点。如果要发出 GET 请求，则需要具有特定参数并特定于该请求的端点。如果要发出 POST 请求，则需要该请求的另一个端点。

REST 有太多的端点

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

过度获取和欠缺的信息

真正令人烦恼的问题是通过 REST API 会过度获取和欠缺的信息。这是因为 REST API 会始终返回固定的结构。除非我们再去创建一个特定的端点，否则无法准确获取所需的数据。

So, if we need only a tiny piece of data, we have to work with the whole object. For example, if we only need to get the firstName, lastName, and age of a user in a REST API, there's no way we can get exactly this data without fetching the whole object.

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

信息欠缺也存在问题。如果我们想从两个不同的资源获取数据，就需要分别对两个不同的端点进行调用。在一个巨大的程序中，扩展性会很差，因为在某些情况下我们只需要获取特定的数据，而不是整个对象。假设我们正在开发一个具有 100 个端点的程序。想象一下工作量和产生的代码量。随着时间的推移，开发会变得越来越困难，代码也难以维护，程序员会感到迷茫。

版本控制

在我看来，REST 中的一个痛点就是版本控制。使用 REST API，通常会看到许多带有 v1 或 v2 的 API。这些在 GraphQL 中并不需要，因为你可以通过添加或删除类型来改进 API。

在GraphQL中，你所需要做的就是写新代码。可以编写新类型、查询和修改，而无需维护其他版本的API。

因此你将看不到如下所示具有端点的 GraphQL API：

1https://example.com/api/v1/users/12312
2https://example.com/api/v2/users/12312

为什么 GraphQL 是未来

早在2012年，Facebook 在开发移动应用时面临一个问题，这导致他们开发了 GraphQL。这些问题非常普遍，特别是当我们谈论 RESTful API 设计时。如上所述，这些问题是：

• 表现不佳
• 端点过多
• 过度获取或欠缺数据
• 每当我们要增加或删除某些内容时，需要开发另一个版本
• API 难以理解

考虑到许多概念，Facebook 的开发人员开使用了一种更好的方法来设计 API，后来将其命名为 GraphQL。基本上它是 REST 的替代品，做了很多改进。

使用 GraphQL，我们可以获得许多新功能，在构建 API 时为你提供强大的功能。下面让我们一个一个地审视它们：

单端点

根本没有必要构建很多端点！GraphQL 只需要一个端点，通过它我们可以在单个请求中获得尽可能多的数据。基本上 GraphQL 会将你的所有查询、修改和订阅封装在一个端点中，并供你调用。它改善了你的开发周期，因为你不必向两个不同的资源发出请求来获取数据。此外，当我们开发一个大型的应用时，不必再像 REST 一样获得大量端点和代码。我们只需要获得一个端点，并根据需要开发尽可能多的请求即可。

GraphQL仅需要一个端点

正如我上面所说，“单端点”方法使你的 API 能够自我描述，你不再需要再去构建文档，因为你的程序员已经知道应该如何使用。他们只需查看代码即可了解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 Foundation 合作创建了一个 GraphQL Foundation。这种查询语言鼓励其开发人员创建更多的文档、工具和语言支持。这将确保 GraphQL 的稳定、中立和可持续发展的未来。因此这也是将 GraphQL 视为 API 的未来的另一个原因。

当然 GraphQL 不会立即取代 REST，因为许多应用仍然在使用它，也不可能在一夜之间重写它们。随着越来越多的公司采用 GraphQL，UX 和 DX 都将得到改进。

结论

GraphQL 的确是API的未来，我们需要了解更多信息。这就是我决定撰写这一系列教程的原因，这些教程将为我们展示如何用好 GraphQL，先从查询和修改开始，然后是订阅和身份验证。

在本系列的下一篇教程中，我将深入研究 GraphQL，展示 GraphQL 如何与类型一起工作，并创建我们的第一个查询和修改。

所以请继续关注并希望在下一个教程中见到你！