api工具 graphql_为什么GraphQL是API的未来

api工具 graphql

by Leonardo Maldonado

莱昂纳多·马尔多纳多(Leonardo Maldonado)

为什么GraphQL是API的未来 (Why GraphQL is the future of APIs)

Since the beginning of the web, developing APIs has been a difficult task for developers. The way we develop our APIs must evolve with time so that we can always build good, intuitive and well-designed APIs.

自网络开始以来，开发API一直是开发人员的艰巨任务。 我们开发API的方式必须随着时间而发展，以便我们始终可以构建良好，直观且设计良好的API。

In the last few years, GraphQL has been growing in popularity among developers. A lot of companies have started adopting this technology to build their APIs. GraphQL is a query language developed by Facebook in 2012 and released publicly in 2015. It has been gaining a lot of traction. It has been adopted by a lot of big companies such as Spotify, Facebook, GitHub, NYTimes, Netflix, Walmart, and so on.

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

In this series of tutorials, we’re going to examine GraphQL, understand what it is, and see what features make this query language so intuitive and easy to use.

在本系列教程中，我们将研究GraphQL，了解它是什么，并查看使该查询语言如此直观和易于使用的功能。

So, let’s get started by examining the problems with REST, and how GraphQL solves them. We will also find out why companies have been building their APIs with GraphQL, and why it is the future of APIs.

因此，让我们开始研究REST问题以及GraphQL如何解决它们。 我们还将发现为什么公司一直使用GraphQL构建其API，以及为什么这是API的未来。

哦，REST (Oh, REST)

A long time ago, when we changed our API design from SOAP to REST, we thought that move would give developers more flexibility in their work. We can’t deny that it worked pretty well for some time and was a good move at the time. As the applications and the web have been getting more and more sophisticated, the APIs naturally evolved as well, following these changes.

很久以前，当我们将API设计从SOAP更改为REST时，我们认为此举将使开发人员的工作更具灵活性。 我们不能否认它在一段时间内效果很好，并且在当时是一个不错的举动。 随着应用程序和Web变得越来越复杂，随着这些变化，API也自然地发生了变化。

However, REST does have a lot of problems. Let’s see what they are:

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

很多端点 (A lot of endpoints)

Each resource in REST is represented by an endpoint. So, in a real-world application, we would end up having a lot of endpoints for a lot of resources. If you want to make a GET request, you would need an endpoint specific to that request, with specific parameters. If you want to make a POST request, you would need another endpoint just for that request.

REST中的每个资源都由一个端点表示。 因此，在现实世界的应用程序中，我们最终将拥有大量用于大量资源的端点。 如果要发出GET请求，则需要特定于该请求的端点，并带有特定参数。 如果要发出POST请求，则仅需要另一个端点来处理该请求。

But, what’s the problem with that? Let’s imagine we are building a huge social media application like Facebook. We will end up with a lot of endpoints which means more developer time is going to be spent developing and maintaining these APIs.

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

信息过度获取和不足 (Over-fetching and under-fetching of information)

A real problem that annoys a lot of developers is over-fetching and under-fetching information through REST APIs. This is because REST APIs always return a fixed structure. We can’t get exactly the data that we want unless we create a specific endpoint for that.

困扰许多开发人员的一个实际问题是通过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 ，就无法在不获取整个对象的情况下准确获取此数据。

There’s also a problem with under-fetching of information. If we want to get data from two different resources, we need to make different calls to two different endpoints. In a huge application, this doesn’t scale so well since there will be cases where we only need to get a specific piece of data, not the entire object. Now, imagine we’re building an application that’s going to have 100 endpoints. Imagine the amount of work and code that we need to write. This will become more difficult with time. The code also gets hard to maintain, and developers feel lost in the process.

信息获取不足也存在问题。 如果要从两个不同的资源获取数据，则需要对两个不同的端点进行不同的调用。 在一个庞大的应用程序中，这种方法无法很好地扩展，因为在某些情况下，我们只需要获取特定的数据，而不是整个对象。 现在，假设我们正在构建一个将具有100个端点的应用程序。 想象一下我们需要编写的大量工作和代码。 随着时间的推移，这将变得更加困难。 该代码也很难维护，并且开发人员会在此过程中迷失方向。

版本控制 (Versioning)

One of the painful points in REST, in my opinion, is versioning. With REST APIs, it is very common to see a lot of APIs with v1 or v2. In GraphQL there’s no need for it since you can evolve your APIs by adding new types or removing old ones.

我认为，REST的痛苦之处之一就是版本控制。 使用REST API，通常会看到许多带有v1或v2的API。 在GraphQL中不需要它，因为您可以通过添加新类型或删除旧类型来发展您的API。

In GraphQL, all you need to do to evolve your API is to write new code. You can write new types, queries, and mutations without the need to ship another version of your API.

在GraphQL中，开发API所需要做的就是编写新代码。 您可以编写新的类型，查询和变异，而无需附带其他版本的API。

So, you won’t see GraphQL APIs with endpoints like the following:

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

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

为什么GraphQL是未来 (Why GraphQL is the future)

Back in 2012, Facebook faced a problem while they were developing their mobile applications which led them to create GraphQL. Those problems are very common, especially when we’re talking about RESTful API design. As discussed these problems are:

早在2012年，Facebook在开发移动应用程序时遇到了一个问题，导致他们创建了GraphQL。 这些问题非常普遍，尤其是当我们谈论RESTful API设计时。 如上所述，这些问题是：

• Poor performance
  表现不佳
• A lot of endpoints
  很多端点
• Over-fetching or under-fetching of data
  数据过度获取或不足
• Shipping another version every time we need to include or remove something
  每次我们需要包含或删除某些内容时，都发送另一个版本
• Difficulty understanding APIs
  难以理解的API

With a lot of concepts in mind, developers from Facebook developed a better way to design APIs and later named it GraphQL. Basically, it’s the replacement for REST, with a lot of improvements.

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

With GraphQL, we get a lot of new features that give you superpowers when you are building your APIs. Let’s examine them one by one:

借助GraphQL，我们获得了许多新功能，这些新功能可在您构建API时为您提供超能力。 让我们一一检查它们：

单端点 (Single endpoint)

There’s no need to build a lot of endpoints! With GraphQL, we only get one endpoint, and with that, we can get as much data as we want in a single request. Basically, GraphQL wraps all of your queries, mutations, and subscriptions in one endpoint and makes it available to you. It improves your development cycle because you don’t need to make two requests to get data from two different resources. Also, imagine that we’re building a huge application, we won’t get a lot of endpoints and a ton of code as with REST. We will get a single endpoint, and with that endpoint, we can make as many requests as we want.

无需构建许多端点！ 使用GraphQL，我们仅获得一个端点，并且通过该端点，我们可以在单个请求中获得所需的尽可能多的数据。 基本上，GraphQL将所有查询，突变和订阅都包装在一个端点中，并提供给您。 它可以缩短开发周期，因为您无需发出两个请求即可从两个不同的资源获取数据。 另外，想象一下我们正在构建一个庞大的应用程序，不会像REST那样获得很多端点和大量代码。 我们将获得一个端点，有了该端点，我们可以发出任意数量的请求。

Also, as I said above, an “endpoint-only” approach makes your API self-documented since there’s no need for you to build documentation because your developers already know how to use it. They can understand the API just by looking at the code, or by looking at the playground. We’re going to learn more about it later on (next tutorial in this series). Seems magical, but it is just GraphQL!

另外，正如我在上文所述，“仅端点”方法使您的API成为自记录文档，因为您无需开发文档，因为您的开发人员已经知道如何使用它。 他们可以通过查看代码或查看操场来了解API。 我们将在稍后(本系列的下一个教程)中进一步了解它。 看起来很神奇，但这只是GraphQL！

使用GraphQL，您只需获取所需的数据 (With GraphQL you fetch only the data you need)

No more over-fetching or under-fetching of information. You fetch only the data that you need. Remember the poor performance issues that we discussed initially? We don’t have that anymore since GraphQL improves the performance of your API, especially in case of slow network connection.

不再需要过度获取或不足获取信息。 您仅获取所需的数据。 还记得我们最初讨论的糟糕的性能问题吗？ 由于GraphQL改善了API的性能，尤其是在网络连接速度较慢的情况下，我们再也没有了。

GraphQL使得开始构建API和保持一致变得容易 (GraphQL makes it easy to start building APIs and be consistent)

A lot of people think that GraphQL is pretty complicated because it involves a schema and a single endpoint. Once you start developing APIs with it, you discover that it’s easier than you thought. An “endpoint-only” API helps a lot when you’re developing your website/app. It makes your API more self-documented, and there’s no need for you to write a lot of documentation about it.

许多人认为GraphQL非常复杂，因为它涉及一个模式和一个端点。 一旦开始使用它开发API，就会发现它比您想象的要容易。 在开发网站/应用程序时，“仅端点” API很有帮助。 它使您的API更具自记录性，并且您无需编写大量有关它的文档。

If you don’t use JavaScript as your main language, that’s not a problem. GraphQL is an agnostic query language which means you can use it with any language. At the time of writing this tutorial, GraphQL has support for more than 12 languages.

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

GraphQL是未来 (GraphQL Is The Future)

The fact that GraphQL is an open source query language means that the community can contribute to it and make improvements to it. When Facebook released it to the community, it gained a lot of traction and approval from developers. Now, GraphQL has been growing rapidly as more and more developers are starting to build APIs with it. However, some people have been asking if this is really going to replace REST or become the new way to build APIs for real-world applications.

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

At first, I thought that GraphQL was only hype and just another way to create APIs. However, when I started to study it, I found out that GraphQL has the essential features that are required to create modern APIs for modern applications because it really plays well with modern stacks.

起初，我认为GraphQL只是大肆宣传，而只是创建API的另一种方式。 但是，当我开始研究它时，我发现GraphQL具有创建用于现代应用程序的现代API所需的基本功能，因为它确实可以与现代堆栈很好地兼容。

So if I could say something to you now is: yes, GraphQL is really the future of APIs. That’s why big companies are betting on it.

因此，现在我能对您说的是：是的， GraphQL确实是API的未来 。 这就是大公司对此押宝的原因。

In November 2018, GraphQL created a GraphQL Foundation, in partnership with the Linux Foundation. This query language is encouraging its developers to build more documentation, tools, and support for the language. This foundation will ensure a stable, neutral, and sustainable future for GraphQL. So, this is another reason to consider GraphQL to be the future of APIs.

在2018年11月，GraphQL与Linux Foundation合作创建了GraphQL Foundation。 这种查询语言鼓励其开发人员构建更多的文档，工具和对该语言的支持。 该基础将确保GraphQL的稳定，中立和可持续的未来。 因此，这是将GraphQL视为API的未来的另一个原因。

Of course, it won’t replace REST immediately because many apps still use it and it’s impossible to rewrite them overnight. As more and more companies adopt GraphQL, both UX and DX will improve.

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

结论 (Conclusion)

GraphQL is really the future of APIs, and we need to learn more about it. That’s why I decided to create a series of 4 tutorials that will show how we can work with the best of GraphQL, starting from Queries and Mutations, then Subscriptions, and Authentication.

GraphQL确实是API的未来，我们需要更多地了解它。 因此，我决定创建一系列4个教程的系列，这些教程将展示我们如何使用GraphQL的最佳功能，从查询和突变，然后是订阅和身份验证开始。

In the next tutorial of this series, I’m going to dive deep into GraphQL, show how GraphQL works with types, and create our first Queries and Mutations.

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

So, stay tuned and see you in the next tutorial!

因此，请继续关注并在下一个教程中见！

? Follow me on Twitter!

？ 在Twitter上关注我！

This article was originally posted at Hashnode. If you enjoy this article read it there too so you can support me and help me to write more articles! You can read it here!

本文最初发布在Hashnode上。 如果您也喜欢这篇文章，请在那儿阅读，以便您支持我并帮助我写更多文章！ 您可以在这里阅读 ！

翻译自: https://www.freecodecamp.org/news/why-graphql-is-the-future-of-apis-6a900fb0bc81/

api工具 graphql