graphql - 您如何处理需要来自 AppSync/GraphQL 中的多个数据源的连接数据的列表？

Question

type Employee {
    id: String!
    name: String
    lastObservedStatus: String
}

type Query {
    employees: [Employee]
}

这是一个虚构的模式来说明我的问题。我有两个单独的数据源，它们返回需要加入以填充响应的列表。第一个数据源'employee list api' 是一个http API，我可以查询以获取我可以用来填充 id 的权威员工列表。和 name列。例如，我得到这样的回应:

[
    {"id": "001", "name": "Harry"},
    {"id": "002", "name": "Jerry"},
    {"id": "003", "name": "Larry"}
]

我有第二个 http API“员工观察日志”，我可以查询以获取状态列表以及关联的 ID。 id 允许我将号码与员工记录中的条目相关联，并且我有一个记录日期。状态记录可能不止一个，但在 GraphQL 中我只想选择最近的一个。示例响应:

[
    {"id":"002", "TimeStamp":"2021-07-01T12:30:00Z", "status": "eating"},
    {"id":"002", "TimeStamp":"2021-07-01T13:10:00Z", "status": "staring out the window"},
    {"id":"001", "TimeStamp":"2021-07-01T16:00:00Z", "status": "sleeping in lobby"}
]

现在，我希望 graphQL 响应返回如下内容:

{
  "data": {
    "employees": [
      {
        "id": "001",
        "name": "Harry",
        "lastObservedStatus": "sleeping in lobby"
      },
      {
        "id": "002",
        "name": "Jerry",
        "lastObservedStatus": "staring out the window"
      },
      {
        "id": "003",
        "name": "Larry",
        "lastObservedStatus": null
      }
    ]
  }
}

由于“employee list api”是有关哪些员工存在的权威来源，因此对“employee”字段的所有查询都应始终触发对该 api 的查询，但仅当“lastObservedStatus”字段时才应触发“employee watch log” api在查询中被选中。
对于这样的模式，应该在哪里注册解析器？我已经读到最佳实践是始终在叶节点上附加解析器，但我不确定在这种情况下如何做到这一点。我什至不确定如果在列表的子字段上附加解析器会发生什么。
我觉得处理这个问题的正确方法是将 lambda 解析器附加到 employees字段，并在 lambda 解析器中检查查询的 selectionSetList 以检查是否已选择“lastObservedStatus”字段。如果不是，则 lambda 仅查询“员工列表 api”，否则 lambda 还会查询“员工观察日志”并在返回结果之前执行类似于 SQL 连接的操作。但这是处理这个问题的正确方法吗？

Answer 1

听起来您需要的是 lastObservedStatus 上的解析器使用您的第二个 API('员工观察日志')作为数据源的字段，其中查询字段 employees正在使用第一个 API 作为其数据源。
这个解析器应该使用 context source field 做一个查询(“父”值，在本例中是 id 和 name 的 Employee，您可以引用)。您可以使用 $ctx.source.id 在 VTL 代码中引用它例如，或 $ctx.source.name如果你需要名字。
这个解析器应该只查询 的状态单例员工，因为它会被每 调用一次每结果在您的查询字段 employees .
还有另一种选择，那就是拥有一个 2 函数管道解析器，其中每个函数指向不同的数据源:

第 1 步解析除 lastObservedStatus 之外的所有字段

第 2 步解决 lastObservedStatus并用 $ctx.prev.result 缝合结果.

这将更难以实现，但如果设计得当，将需要更少的 API 调用。