概述

我们已经设置了我们的实体定义，但路由器究竟如何使用这些实体？

在本课中，我们将

• 了解路由器如何使用实体和查询计划从多个子图连接数据
• 了解实体表示和引用解析器如何协同工作

让我们来看一个示例查询

假设客户端请求应用程序的最新评论。在他们的查询中，他们会请求每个评论的 ID、评论和评分，以及每个评论所在位置的名称。

现在该路由器大显身手了！

步骤 1：构建查询计划

正如我们之前所见，路由器首先构建一个查询计划，它指示将哪些请求发送到哪些子图。

路由器从传入的查询的顶级字段开始，latestReviews。借助超级图模式，路由器看到latestReviews在reviews 子图中定义。

因此，路由器从向reviews 子图发送请求开始构建查询计划。

路由器会持续这样做一段时间，检查查询中的每个字段，并将其与超级图模式进行比较，并将其添加到查询计划中。对于id、comment、rating和location，它们都属于reviews 子图。

但当路由器到达name 字段（针对特定Location时），它会从超级图模式中看到，只有Location.name可以通过locations 子图解析（因为Location.name 字段是在那里定义的）。

这意味着路由器将不得不连接来自不同子图的数据。

要做到这一点，路由器需要从reviews 子图获取更多信息：每个评论对应的Location对象的实体表示。

请记住，实体表示是路由器用来在不同子图之间跟踪特定对象的。要为Location对象创建实体表示，路由器需要位置的类型名称及其主键（在本例中是id 字段）。

路由器可以从reviews 子图获取这两个字段。

接下来，路由器会向其查询计划中添加另一个操作，以请求locations 子图中的位置name。

这样一来，查询中的所有字段都已在查询计划中得到考虑。现在该进入下一步：执行计划。

步骤 2：查询 reviews 子图

路由器首先请求reviews 子图中的数据。

The reviews subgraph resolves all the requested fields as it normally would, including the entity representations for all the requested location objects.

This subgraph doesn't know that the router plans to do anything special with the location's id or typename. It just sends back the data to the router like it was asked.

With that, the router's taken care of the first part of the query plan! The next step is to retrieve the name field from the locations subgraph.

步骤 3：查询 locations 子图

Remember the _entities field that showed up in our subgraph after we first defined an entity? This is where it comes back into the story!

The router builds a request using the _entities field.

This field takes in an argument called representations, which takes in, well, a list of entity representations! This is where the entity representations that the router received from the reviews subgraph will go.

In the same request, the router adds the rest of the fields left in the query plan (in this case, the location's name).

The router sends this request to the location's subgraph.

To resolve the _entities field, the locations subgraph uses its reference resolver. Remember this is a special resolver function used to return all the entity fields that this subgraph contributes.

The locations subgraph looks at the __typename value of each reference object to determine which entity's reference resolver to use. In this case, because typename is "Location", the locations subgraph knows to use the Location entity's reference resolver.

The Location reference resolver runs once for each entity representation in the query. Each time, it uses the entity representation's primary key to return the corresponding Location object.

After the locations subgraph finishes resolving the request, it sends the data back to the router.

这就是执行阶段的全部内容！

步骤 4：向客户端发送最终响应

现在，路由器将从reviews 和 locations 子图 收集到的所有数据组合成一个 JSON 对象。最后，路由器将最终对象发送回客户端。

练习

关键要点

• 当路由器需要从不同的子图查询字段时，它还会请求当前正在查询的子图的实体表示。这些表示将在后续操作的_entities 字段中使用，设置为representations 参数的值。
• 参考解析器获取每个表示，并返回其请求字段的匹配数据。

接下来

现在我们确切地知道路由器的查询计划中发生了什么，以及这些部分是如何组合在一起的！在下一课中，我们将深入代码并从引用来自子图的实体开始。