为什么 GraphQL 是 API 的未来

骑猪看日落 2022-02-20 06:15 270阅读 0赞

> 翻译：疯狂的技术宅  
> [https://medium.freecodecamp.org/why-graphql-is-the-future-of-apis-6a900fb0bc81][https_medium.freecodecamp.org_why-graphql-is-the-future-of-apis-6a900fb0bc81]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2V5ZW9mYW5nZWw_size_16_color_FFFFFF_t_70]

自从 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 请求，则需要该请求的另一个端点。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2V5ZW9mYW5nZWw_size_16_color_FFFFFF_t_70 1]

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

#### 过度获取和欠缺的信息 ####

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

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2V5ZW9mYW5nZWw_size_16_color_FFFFFF_t_70 2]

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

#### 版本控制 ####

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

在GraphQL中，你所需要做的就是写新代码。可以编写新类型、查询和修改，而无需维护其他版本的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 一样获得大量端点和代码。我们只需要获得一个端点，并根据需要开发尽可能多的请求即可。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2V5ZW9mYW5nZWw_size_16_color_FFFFFF_t_70 3]

正如我上面所说，“单端点”方法使你的 API 能够自我描述，你不再需要再去构建文档，因为你的程序员已经知道应该如何使用。他们只需查看代码即可了解API。我们稍后会详细了解它（本系列的下一篇教程）。看起来很神奇，但这就是 GraphQL！

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

没有过度获取或未被充分利用的信息，你只获取自己需的数据。还记得我们最初讨论的性能问题吗？不会再像那样了，因为 GraphQL 提高了 API 的性能，特别是在网络连接速度较慢的情况下。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2V5ZW9mYW5nZWw_size_16_color_FFFFFF_t_70 4]

#### GraphQL 使得开发 API 变得容易并保持一致 ####

很多人认为 GraphQL 非常复杂，因为它涉及模式和单个端点。但是你一旦开始用它开发 API，会发现它比你想象的要容易得多。当你开发网站或应用时，“单端点” API 会给你很大帮助。它使你的 API 更加能够自我描述，并且无需为它编写大量的文档。

如果你并不是把 JavaScript 作为主要语言，那也不是问题。 GraphQL 是一种查询语言，这意味着你可以使用任何自己熟悉的语言。在编写本教程时，GraphQL 支持的语言已经超过了 12 种。

### GraphQL 是未来 ###

GraphQL 是一种开源查询语言，这意味着社区可以为其做出贡献并对加以改进。当 Facebook 将其发布到社区时，得到了大量的认同。现在随着越来越多的程序员用它构建 API，GraphQL 一直在快速增长。但是也有些人一直在问它是否真的要取代 REST，或者成为构建 API 的新方法。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2V5ZW9mYW5nZWw_size_16_color_FFFFFF_t_70 5]

起初，我认为 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 如何与类型一起工作，并创建我们的第一个查询和修改。

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

--------------------

欢迎关注微信公众号：前端先锋，每天第一时间阅读最新技术文章。

![SouthEast][]

[https_medium.freecodecamp.org_why-graphql-is-the-future-of-apis-6a900fb0bc81]: https://medium.freecodecamp.org/why-graphql-is-the-future-of-apis-6a900fb0bc81
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2V5ZW9mYW5nZWw_size_16_color_FFFFFF_t_70]: /images/20220220/c8292ab7c2fa49cda2c131f13c1028ae.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2V5ZW9mYW5nZWw_size_16_color_FFFFFF_t_70 1]: /images/20220220/854e28076c26449d9e80a1738e81c918.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2V5ZW9mYW5nZWw_size_16_color_FFFFFF_t_70 2]: /images/20220220/e97bcc0deb104da19269c73f6db14c59.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2V5ZW9mYW5nZWw_size_16_color_FFFFFF_t_70 3]: /images/20220220/0a4ec3f4ce064f7d880079979aca9b90.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2V5ZW9mYW5nZWw_size_16_color_FFFFFF_t_70 4]: /images/20220220/f94eb058f5854ca8a7e75e165dadde35.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2V5ZW9mYW5nZWw_size_16_color_FFFFFF_t_70 5]: /images/20220220/a45c930bb2b44403a4a3d841b79659c0.png
[SouthEast]: /images/20220220/72e390d69fd846438e9fe238f1870e69.png