为何 GraphQL 是 API 的将来

时间 2019-12-05

标签为何 graphql api 将来繁體版

原文原文链接

翻译：疯狂的技术宅
https://medium.freecodecamp.o...

本文首发微信公众号：前端先锋
欢迎关注，天天都给你推送新鲜的前端技术文章前端

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

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

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

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

REST

好久之前，当咱们把 API 的设计从 SOAP 转向 REST 时，认为此举将会为工做提供更多的灵活性。咱们不可否认 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。

所以你将看不到以下所示具备端点的 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 可以自我描述，你再也不须要再去构建文档，由于你的程序员已经知道应该如何使用。他们只需查看代码便可了解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 如何与类型一块儿工做，并建立咱们的第一个查询和修改。

因此请继续关注并但愿在下一个教程中见到你！