数据加载器揭秘 - GraphQL 教程

3. 数据加载器揭秘

10m

概述

在本课中，我们将

讨论什么是数据加载器
介绍dataloader 包
回顾数据加载器的要求
详细了解数据加载器在底层的运作方式

数据加载器

为了解决我们应用程序中的 n+1 问题，我们将使用 数据加载器。

数据加载器的主要工作是将多个相似的请求替换为一个批处理请求。在我们的示例中，我们看到了三个几乎完全相同的请求，它们使用特定的展示 ID 来返回 tiện nghi 数据。使用数据加载器，这会变成一个单个请求，一次获取所有三个展示的数据。

我们将会向我们的数据源类中引入数据加载器的强大功能，并使用 GraphQL dataloader 包。

`dataloader` 包

dataloader 包是一个实用程序，它提供批处理和缓存功能。这让我们将各种键批处理在一起，使用一个请求，一次性提供所有数据！

让我们用以下查询来对此进行说明。

有关精选展示及其 tiện nghi 的查询

query GetFeaturedListingsAmenities {
  featuredListings {
    id
    title
    amenities {
      id
      name
      category
    }
  }
}

对于查询解析出的每个精选列表对象，将调用查询。当前，此解析器使用列表 ID 来独立解析 Listing.amenities 解析器。每个请求。（导致对同一端点的三个单独的网络请求！）

我们想要的行为截然不同：我们希望数据加载器收集所有参与查询（也称为密钥）的列表 ID，并执行一个请求。

在我们的示例中，这意味着在使用每个列表的 ID 调用 Listing.amenities 解析器时，它不会直接调用命中我们 REST API 的 ListingAPI的方法；而会将每个密钥传递给一个数据加载器方法，它可以将整个操作所需的密钥批处理在一起。

在将所有列表 ID 收集到一个列表中后，数据加载器可以承担从数据源实际请求数据的责任。它可以一次向 REST API 端点分派一个请求，用于所有 ID同时——与让解析器为每个发起网络请求相比，性能大幅提升！

最棒的是，我们的数据加载器方法会自动对我们传递给它们的标识符进行重复数据删除。这意味着，如果我们的查询包含多个具有相同 ID 的列表，我们只会请求一次列表的便利设施。

数据加载器需要什么

数据加载器正是我们解决应用中性能问题所需的东西，但它们包含需我们考虑的一些要求。我们逐一了解其中的每一个要求。

一次针对多个对象的数据

假设我们的数据加载器收集了我们的query中涉及的所有不同密钥，并且准备发出数据请求。它接下来需要什么呢？

嗯，如果我们思考一下之前用于返回便利设施数据的 REST API 端点，我们会很快发现问题：现在，Listing.amenities 解析器依赖于ListingAPI方法getAmenities将每个列表 ID 单独发送到GET /listings/{listing_id}/amenities端点，它仅为一个单个列表返回数据。

这让我们的数据加载器按预期工作有了第一个重要的要求：我们需要一个数据源能够同时解析多个对象的请求。在实践中，这意味着我们的数据加载器应该能够发送一串密钥（例如["listing-1", "listing-2", "listing-3"]），并获取所有这些密钥的数据。

好消息是，我们的 REST API 中确实有不同的端点，我们可以使用它来请求多个列表的便利设施数据：GET /amenities/listings它接受多个列表 ID，以一个称为ids的query参数字符串的形式连接，一次性返回它们的所有数据。

接收多个键并返回多个值的 REST 端点

GET /amenities/listings?ids=listing-1,listing-2,listing-3

每个键一个值

当数据加载器在请求中发送一串密钥时，它对提供数据的数据源有非常明确的期望：返回的对象数量决不能大于请求中发送的密钥数量。返回的值也应与请求的相应密钥具有相同的顺序。

让我们分解一下这个期望以及数据源如何满足它。

在解决查询的过程中，我们的解析器可能会调用数据加载器三次，向其传递三个键。数据加载器将它们分组到一个列表中（["listing-1", "listing-2", "listing-3"]），然后使用它们来调用GET /amenities/listings。它期望得到什么返回结果？嗯，它放入了一个列表，包含三个键；它期望返回一个包含不超过三个对象列表！

A diagram showing a request with three listing IDs; three lists of amenities are returned

对于每个请求的键，我们期望我们的数据源返回一个便利设施列表。这是因为每个清单都可以具有多个与之关联的便利设施。因此，如果我们请求三个列表 ID 的便利设施数据，则我们的响应应该包含三个便利设施列表。

A diagram showing three listing IDs; and three lists of amenities that map to them

注意：数据加载器还期望每个返回的对象与原始请求中对应键的位置保持一致。例如，如果将“listing-1”作为第一个键发送，则其便利设施列表应该是响应中的第一个对象！

从那里，数据加载器处理将每个便利设施列表映射回请求它的键的逻辑。

当我们请求特色清单数据时，每个对象都包含一个amenities键，它是一个便利设施 ID 数组。

特色清单 JSON 响应中的示例清单对象


{
  "id": "listing-1",
  "title": "Cave campsite in snowy MoundiiX",
  "description": "Enjoy this amazing cave campsite in snow MoundiiX, where you'll be one with the nature and wildlife in this wintery planet. All space survival amenities are available. We have complementary dehydrated wine upon your arrival. Check in between 34:00 and 72:00. The nearest village is 3AU away, so please plan accordingly. Recommended for extreme outdoor adventurers.",
  "costPerNight": 120,
  // ... other properties
  "amenities": [
    {
      "id": "am-2"
    },
    {
      "id": "am-10"
    },
    {
      "id": "am-11"
    },
    {
      "id": "am-12"
    },
    {
      "id": "am-13"
    },
    {
      "id": "am-26"
    },
    {
      "id": "am-27"
    },
    {
      "id": "am-16"
    }
  ]
}

这意味着我们有两种可能的方法可以请求给定清单的后续便利设施数据：我们可以使用清单 ID 向GET /amenities/listings端点发送请求（如我们即将做的那样），或我们可以收集清单amenities属性中的所有便利设施 ID，并向GET /amenities端点发出一次大请求以获取便利设施数据。

我们来使用我们的GetFeaturedListingsAmenities 查询来逐步了解这种第二个选项（通过便利设施 ID 请求便利设施）会是什么样子。

有关精选展示及其 tiện nghi 的查询


query GetFeaturedListingsAmenities {
  featuredListings {
    id
    title
    amenities {
      name
    }
  }
}

对于返回的每一个列表对象，Listing.amenities 解析器会执行。在此处，我们可以访问特定列表的 amenities 字段，映射所有便利设施 ID，并将整个列表传递给数据加载器，以批量处理在一起。

即便我们的精选列表响应中只有三个列表对象，这种情况看起来也会开始变得复杂一些：数据加载器会收集每个列表的便利设施 ID 列表，将它们收集到一个更大的列表中。

使用这种方法存在一个大问题。我们传递到数据加载器的便利设施的每个完整列表都被视为一个键。

因此，如果我们有两个列表包含一些相同的便利设施 ID，我们将无法享受数据加载器去重的好处；它将整个便利设施 ID 列表视为一个整体。

即使ListingAPI包含用于分解便利设施 ID 列表的逻辑，对它们进行去重，并向 GET /amenities端点发出一个大请求，我们也会看到出现另一个问题。

现在我们得到了一大块便利设施数据；如何将此响应映射回数据加载器分发该请求的键列表目前还不清楚。仅仅返回整个数据块来供解析器处理也不行；数据加载器会尝试强制我们获得小于或等于我们提交的键数量的对象。因此，三个键应该意味着至多得到三个对象。

因此，我们需要在ListingAPI中引入另一层逻辑来接收 JSON 结果，映射它们并将便利设施 ID 的每个列表与相应的数据匹配起来。

正因为有此复杂性，所以我们选择使用列表的 id 字段来获取其便利设施：这样更干净，并且允许数据加载器完成大部分工作！

数据加载器作用域

需要记住的最后一个重要要点是。必须在一次请求中限制数据加载器和它们在任何时间处理的键集合。因此，我们在下一课中的实现将确保每个请求都会创建一个新的 DataLoader 实例。

这意味着，如果我们运行一个查询来列出数据，然后依次运行第二个查询，那么这两个查询中的键将不会被批量处理到一起。相反，每个查询将被单独解析。

A diagram demonstrating how a data loader handles two queries separately

明确了这些概念性要点之后，让我们将注意力重新转向代码。我们将更新我们的 Listing.amenities 解析器以在我们的 ListingAPI 类中调用一个新的方法，并从数据加载器中获益！

练习

以下哪些数据加载器语句是正确的？

数据加载器替换了我们应用程序的解析器。数据加载器可以通过减少我们的 GraphQL API 为获取额外数据而进行的调用次数来解决 n+1 问题。数据加载器将一直等到所有查询都运行完后，再批量处理所有请求。数据加载器会用一个批量请求替换多个相似的请求。

关键要点

数据加载器让我们可以将一个 ID（例如 ID）的列表批量处理在一个请求中，而不是为每个 ID 发送一个单独的请求。
在我们数据源（另一个 API 或数据库）能够正常工作之前，数据加载器需要实现一个方法，该方法接受多个键（例如 ID），并返回多个对象。
数据加载器从数据源接收到的对象数量不应超过数据加载器收集的键的数量。（例如，如果数据加载器请求三个 listing 的数据，它最多只应收到三个 listing 对象！）

接下来

我们已经了解了数据加载器及其解决我们应用程序中遇到问题的解决方案。我们还有一个新的数据源方法，该方法接受多个清单 ID，并解析多个便利设施对象。接下来，我们将实现数据加载器逻辑，以便在单个请求中收集多个清单 ID。

上一个

下一个

分享你对本课程的问题和评论

本课程目前处于

beta 版

.你的反馈有助于我们改进！如果你遇到困难或困惑，请告诉我们，我们会帮助你解决。所有评论都是公开的，并且必须遵守 Apollo 行为准则。请注意，已经解决或处理的评论可能会被删除。

你将需要一个 GitHub 帐户才能在下面发帖。还没有吗？转而发布到我们的 Odyssey 论坛。

概述