GraphQL-它是什么,它可以解决什么问题?

作者 : IT 大叔 本文共3744个字,预计阅读时间需要10分钟 发布时间: 2020-09-14

当我第一次阅读有关GraphQL及其解决的问题时,我发疯了。因此,我希望您了解GraphQL。

这是有关GraphQL的新帖子系列的第一篇帖子。在第一篇文章中,我将解释什么是GraphQL以及创建它的动机。然后,在以后的文章中,我将通过项目在理论上和实践上解释基本概念和高级概念。

什么是GraphQL?

GraphQL是用于构建API的查询语言。它是由Facebook创建的,其目的是解决REST API引起它们的一些问题。移动Facebook团队在使用REST时遇到问题,这影响了他们的应用程序性能。他们必须对一个简单的应用程序页面执行多个请求,并且在获取数据方面也遇到了问题。因此,应用程序性能受到影响。因此,他们开始创建一种新的查询语言,客户端可以在其中精确指定所需的数据并在单个请求中接收数据。

2015年,Facebook发布了该语言的规范。该规范已被社区高度采用,并且同一社区已开发了多种语言的多种客户端和后端实现:https : //graphql.org/code/

目前,GitHub,Twitter,Airbnb,Atlassian等许多不同的公司正在使用GraphQL。

GraphQL解决什么问题?

在本节中,我将解释GraphQL解决的REST问题。GraphQL的动机是解决此问题,因此了解它们很重要。

多个请求

假设我们需要一些信息来填写页面。在此页面中,我们要显示帖子列表及其相关用户和评论。

使用REST API

如果我们使用的是REST API,则可能必须发出多个请求才能获得页面所需的所有信息:

// Get a list of posts - GET
curl https://jsonplaceholder.typicode.com/posts

// Get user of each post -> N request if you have N posts
curl https://jsonplaceholder.typicode.com/users/{post.userId}

// Get comments of each post -> M requests, if each post would have M comments
curl https://jsonplaceholder.typicode.com/comments/${post.comments[i].id}

在这个例子中,我们可以看到一个重要的问题。对于每个帖子,我们都要做:

1-提取用户的额外请求。

2-如果帖子有M条评论,则M请求获取所有评论。

因此,考虑到我们获取了N个帖子,每个帖子都有M条评论:

totalRequests = 1 (fetch posts)+ N (fetch user) + NM (fetch comments)
totalRequests = 1 + N + NM

例如,如果在一个简单页面中我们有20个帖子,每个帖子有3条评论,则总共我们将进行1 + 20 + 20 * 3 = 81个请求。

帖子和评论之间的问题是一个已知问题N + 1 problem。当我们获取一个简单的资源(1个请求)时,也会发生此问题,并且我们还必须执行N个请求才能获取所有所需的信息。

您可以告诉我,通过API进行重构,该问题就消失了。那是真的。如果我们创建一个新的端点,例如:

curl https://jsonplaceholder.typicode.com/posts/1/comments

我们只需要对每个帖子执行单个请求即可获取其所有评论。更好的是,如果我们在帖子资源中发送评论,则不需要额外的请求。

但是,我们不应该根据前端需求更改后端。这很昂贵,并且降低了我们的开发速度。

使用GraphQL

GraphQL允许我们仅在一个请求中获得所需的所有数据进行GraphQL查询可获得与上一个示例相同的信息:

{
 getPosts{
   id
   title
   body
   user {
     id
     username
     avatar
   }
   comments {
     id
     body
     author {
       id
       username
       avatar
     }
   }
 }
}

通过这个独特的GraphQL查询,我们将获得包含所有必要信息的帖子列表。这是与REST相比的重要优势。

抓取不足和抓取过度

按照上一节的示例,假设我们需要用帖子列表填充页面。在此页面中,我们必须显示每个帖子的标题,用户名和标签

使用REST API

我们的API中有和端点,可返回包含以下数据的帖子列表:

[
{
  id: '1',
  title: 'A title',
  userId: '1',
  tags: ['js', 'html'],
  likes: 12,
  body: 'Post body',
  image: 'An img'
}, 
{...}, 
{...}
]

在新页面中,我们只需要每个帖子的标题,用户名和标签。因此,我们可以看到我们正在提取不足过度提取数据。我们正在提取数据不足,因为我们将需要请求其他端点来提取用户的用户名。而且我们超量获取数据是因为页面中未使用“ body”,“ image”和“ likes”之类的属性。这是REST API的问题,因为端点返回固定的数据结构。因此,当我们命中一个端点时,它返回的固定数据可能包含比我们所需少得多的信息。

使用GraphQL

GraphQL允许客户端精确指定所需的数据。因此,我们将不会出现数据提取不足和提取过度的问题。查询示例可能是:

{
 getPosts{
   id
   title
   tags
   user {
     username
   }
 }
}

然后,通过单个查询,我们将获得需要的确切信息,以避免数据提取不足和数据提取过度

前端加上后端

假设我们正在应用程序中开发一个新页面。在分析所需数据时,我们确定必须调用多个REST API端点才能获取所有数据。

如果我们不希望由于API请求倍数而影响应用程序的性能,则可以对REST API端点进行一些更改,或者创建一个新的端点,该端点仅返回一个或一个即可返回页面所需的所有数据。几个端点。REST API经常会发生这种情况,我们通常必须决定是要更改API还是使前端适应API提供的信息。这是一个问题,因为我们正在耦合前端和后端。

使用GraphQL,该问题消失了。客户端可以在任何页面中获取其所需的数据,而无需在后端中进行任何更改。客户端唯一需要知道的是GraphQL API的架构。GraphQL Schema定义了API提供的数据,客户端可以根据需要使用这些数据。

前端和后端之间缺乏合同

REST定义了客户端和服务器之间如何通信,但未定义有关客户端和服务器之间交换的信息的数据结构的任何内容。有关数据结构的决定是公开的,通常后端由客户端决定如何与客户端发送和接收信息。在有组织的团队中,前端和后端团队可以就API的端点和数据结构达成一致。无论如何,这不是REST API的特征,而是组织良好的团队的特征。在许多其他情况下,我们必须使用外部REST API,直到开始使用API​​时,我们才知道数据结构。

GraphQL解决了使用强类型系统来定义数据结构和可从我们的客户使用的信息的问题。使用GraphQL架构定义语言(SDL)在架构中写下所有这些定义。这里是一个例子:

type Post {
  id: ID!
  title: String!
  body: String!
  user: User!
  comments: [Comment]
}

type Comment {
  id: ID!
  body: String!
  user: User!
}

type User {
  id: ID!
  username: String!
  avatar: String
}

type Query {
  getPosts: [Post]
  getUsers: [User]
}

如果您不了解此架构定义,请不要担心。在下一篇文章中,我将介绍SDL以及如何从头开始创建简单的GraphQL项目。

此架构充当客户端和服务器之间的协定。

定义GraphQL模式后,前端和后端团队就可以独立工作,因为它们之间存在合同。因此,前端团队可以按照Schema模拟数据并开发整个前端应用程序或网页。后端准备就绪后,前端团队就可以使用真正的GraphQL API。

没有文档的API

REST不会强迫您创建有关API的文档。诸如Swagger之类的工具可帮助开发人员创建REST API文档。但是,开发人员需要付出额外的精力来创建和维护它。因此,许多REST API都没有文档或文档已过时。

由于GraphQL使用强类型系统,因此按定义是一种书面语言。因此,仅创建GraphQL模式,我们才能生成API文档。例如,下面是带有上面定义的架构文档的gif:

缺少API使用情况跟踪

借助REST,我们唯一可以跟踪到客户端如何使用我们的API的方法就是每个端点的调用频率。

使用GraphQL,由于每个客户端都精确地指定了他们感兴趣的信息,因此我们可以了解正在使用的数据和未使用的数据。此外,我们可以衡量所请求的每个属性的性能,这可提供有关API性能的重要见解。

结论

我们已经了解了GraphQL和GraphQL相对于REST的优势。

GraphQL是功能强大的工具,但不是功能强大的工具。构建API REST可能更简单。因此,如果您不关心我在本文中提到的REST问题,那么REST是您的项目的不错选择。

在本系列的下一篇文章中,我们将开发一个简单的项目。通过这个项目,我将解释一些GraphQL概念以及如何构建基本的GraphQL API。

谢谢阅读!

免责声明:
1. 本站资源转自互联网,源码资源分享仅供交流学习,下载后切勿用于商业用途,否则开发者追究责任与本站无关!
2. 本站使用「署名 4.0 国际」创作协议,可自由转载、引用,但需署名原版权作者且注明文章出处
3. 未登录无法下载,登录使用金币下载所有资源。
IT小站 » GraphQL-它是什么,它可以解决什么问题?

常见问题FAQ

没有金币/金币不足 怎么办?
本站已开通每日签到送金币,每日签到赠送五枚金币,金币可累积。
所有资源普通会员都能下载吗?
本站所有资源普通会员都可以下载,需要消耗金币下载的白金会员资源,通过每日签到,即可获取免费金币,金币可累积使用。

发表评论