联邦是如何处理N+1查询问题的

GraphQL开发者很快就会遇到著名的“N+1 查询问题”，这个问题在返回列表的操作中尤为常见：

1
query TopReviews {
2
  topReviews(first: 10) {
3
    id
4
    rating
5
    product {
6
      name
7
      imageUrl
8
    }
9
  }
10
}

在单体GraphQL服务器中，执行引擎采取以下步骤：

1. 解析Query.topReviews 字段，它返回一个Review列表。
2. 对于列表中的每个Review，解析Review.product字段

如果Query.topReviews字段返回10条评论，则执行器将解析Review.product字段 10次。如果Reviews.product字段针对单个Product执行数据库或REST查询，则会看到对数据源的10个唯一调用。这从以下原因看是不太理想的：

• 一次性查询10个产品更有效率（例如SELECT * FROM products WHERE id IN (<product ids>)）。
• 如果有任何评论引用了同一产品，那么我们正在浪费资源去获取已经拥有的数据。

针对单体GraphQLAPI的解决方案是dataloader模式。所有 GraphQL服务器实现都支持这种模式。Apollo服务器文档解释了如何在Node.js服务器中使用JavaScript实现。

联邦图中的N+1问题

考虑相同的TopReviews 操作，但我们已经在单独的子图中实现了Review和Product类型：

1
type Query {
2
  topReviews(first: Int): [Review]
3
}
4

5
type Review {
6
  id: ID
7
  rating: Int
8
  product: Product
9
}
10

11
type Product @key(fields: "id") {
12
  id: ID
13
}

1
type Product @key(fields: "id") {
2
  id: ID!
3
  name: String
4
  imageUrl: String
5
}

幸运的是，查询计划默认处理Product类型等实体的N+1查询！此操作的查询计划如下：

1. 首先，我们使用根字段Query.topReviews从Review子图中Fetch列表中的Review。我们还请求每个相关产品的id。
2. 接下来，我们提取 Product 实体 引用并将其批量检索到 Products 子图中的 Query._entities 根字段。
3. 返回 Product 实体后，我们在 Flatten 步骤中将它们合并到 Review 列表中。

1
QueryPlan {
2
  Sequence {
3
    Fetch(service: "reviews") {
4
      {
5
        topReviews(first: 10) {
6
          id
7
          rating
8
          product {
9
            __typename
10
            id
11
          }
12
        }
13
      }
14
    },
15
    Flatten(path: "reviews.@") {
16
      Fetch(service: "products") {
17
        {
18
          ... on Product {
19
            __typename
20
            id
21
          }
22
        } =>
23
        {
24
          ... on Product {
25
            name
26
            imageUrl
27
          }
28
        }
29
      },
30
    },
31
  },
32
}

编写高效的实体解析器

在大多数 subgraph 实现（包括 @apollo/subgraph）中，我们不直接编写 Query._entities 解析器。相反，我们使用 引用解析器 API 来解析单个实体引用：

1
const resolvers = {
2
  Product: {
3
    __resolveReference(productRepresentation) {
4
      return fetchProductByID(productRepresentation.id);
5
    },
6
  },
7
};

此 API 的动机与 subgraph 规范的微妙、关键方面相关：解析实体的顺序必须与给定实体引用的顺序匹配。如果我们以错误的顺序返回实体，则这些 字段 将与错误的实体合并，我们将得到错误的结果。为了避免此类问题，大多数 subgraph 库会为您处理实体顺序。

但这会再次引入 N+1 查询问题：在上面的示例中，我们将为每个实体引用调用一次 fetchProductByID。

幸运的是，在单体图中也存在相同的解决方案：数据加载器。在几乎所有情况下，引用 解析器 都应该使用数据加载器。

1
const resolvers = {
2
  Product: {
3
    __resolveReference(product, context) {
4
      return context.dataloaders.products(product.id);
5
    },
6
  },
7
};

现在，当查询规划器调用带有产品实体批的产品子图时，我们将对产品数据源发出单个批处理请求。