从Web开始，开发API对于开发人员来说是一项艰巨的任务。我们开发API的方式必须随着时间的推移而发展，以便我们始终可以构建良好，直观且设计良好的API。
在过去几年中，GraphQL在开发人员中越来越受欢迎。许多公司已经开始采用这种技术来构建他们的API。GraphQL是一种由Facebook在年开发并于年公开发布的查询语言。它已经获得了很大的吸引力。它已被许多大公司采用，如Spotify，Facebook，GitHub，NYTimes，Netflix，沃尔玛等。
在本系列教程中，我们将研究GraphQL，了解它是什么，并查看哪些功能使这种查询语言如此直观和易于使用。
因此，让我们开始研究REST的问题，以及GraphQL如何解决它们。我们还将了解公司为何使用GraphQL构建API，以及为什么它是API的未来。
哦，REST
很久以前，当我们将API设计从SOAP更改为REST时，我们认为此举将为开发人员提供更多工作灵活性。我们不能否认它在一段时间内运作良好，当时是一个很好的举措。随着应用程序和Web变得越来越复杂，API也会随着这些变化自然发展。
但是，REST确实存在很多问题。让我们看看它们是什么：
很多端点
REST中的每个资源都由端点表示。因此，在实际应用程序中，我们最终会为很多资源提供大量端点。如果要发出GET请求，则需要具有特定参数的特定于该请求的端点。如果要发出POST请求，则只需要该请求的另一个端点。
但是，那有什么问题呢？让我们假设我们正在构建一个像Facebook这样的大型社交媒体应用程序。我们最终会得到很多端点，这意味着开发和维护这些API将花费更多的开发人员时间。
过度获取和信息不足
令许多开发人员烦恼的真正问题是通过RESTAPI过度获取和获取信息。这是因为RESTAPI始终返回固定结构。除非我们为此创建特定的端点，否则我们无法准确获取所需的数据。
因此，如果我们只需要一小部分数据，我们就必须处理整个对象。例如，如果我们只需要在RESTAPI中获取用户的firstName，lastName和age，那么我们就无法在不获取整个对象的情况下获得这些数据。
信息欠缺也存在问题。如果我们想从两个不同的资源获取数据，我们需要对两个不同的端点进行不同的调用。在一个巨大的应用程序中，这不会很好地扩展，因为在某些情况下我们只需要获取特定的数据，而不是整个对象。现在，假设我们正在构建一个具有个端点的应用程序。想象一下我们需要编写的工作量和代码量。随着时间的推移这将变得更加困难。代码也难以维护，开发人员在此过程中感到迷茫。
版本
在我看来，REST中的一个痛点就是版本控制。使用RESTAPI，通常会看到许多带有v1或v2的API。在GraphQL中，不需要它，因为你可以通过添加新类型或删除旧类型来改进API。
在GraphQL中，你需要做的就是编写新代码。你可以编写新类型，查询和突变，而无需发送其他版本的API。
因此，你将看不到具有端点的GraphQLAPI。
为什么GraphQL是未来
早在年，Facebook在开发移动应用程序时面临着一个问题，导致他们创建了GraphQL。这些问题非常普遍，特别是当我们谈论RESTfulAPI设计时。如上所述，这些问题是：
性能不佳很多端点过度获取或欠读数据每次我们需要包含或删除某些内容时，需要运送其他版本难以理解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的未来。这就是大公司押注它的原因。
在年11月，GraphQL与LinuxFoundation合作创建了一个GraphQLFoundation。这种查询语言鼓励其开发人员构建更多文档，工具和语言支持。该基础将确保GraphQL的稳定，中立和可持续的未来。因此，这是将GraphQL视为API未来的另一个原因。
当然，它不会立即取代REST，因为许多应用仍然使用它，并且不可能在一夜之间重写它们。随着越来越多的公司采用GraphQL，UX和DX都将得到改进。
结论
GraphQL实际上是API的未来，我们需要了解更多信息。这就是我决定创建一系列4个教程的原因，这些教程将展示我们如何使用最好的GraphQL，从查询和变异开始，然后是订阅和身份验证。
在本系列的教程中，我将深入研究GraphQL，展示GraphQL如何与类型一起工作，并创建我们的第一个查询和变异。
所以，请继续
转载请注明：http://www.0431gb208.com/sjszyzl/1703.html
