在 AppSync/GraphQL 中如何處理需要來自多個數據源的連接數據的列表？

Question

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

type Query {
    employees: [Employee]
}

這是一個虛構的模式來說明我的問題。 我有兩個單獨的數據源，它們返回需要加入以填充響應的列表。 第一個數據源“員工列表 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的查詢，但'employee observation log'api僅應在'lastObservedStatus'字段時觸發在查詢中被選中。

對於這樣的模式，應該在哪里注冊解析器？ 我讀過，最佳做法是始終在葉節點處附加解析器，但我不確定在這種情況下如何做到這一點。 我什至不確定如果您在列表的子字段上附加解析器會發生什么。

我覺得處理此問題的正確方法是將 lambda 解析器附加到employees字段，並在 lambda 解析器中檢查查詢的 selectionSetList 以檢查是否已選擇“lastObservedStatus”字段。 如果不是，則 lambda 僅查詢“員工列表 api”，否則 lambda 還會查詢“員工觀察日志”，並在返回結果之前執行類似於 SQL 連接的操作。 但這是處理這個問題的正確方法嗎？

Answer 1

聽起來您需要的是lastObservedStatus字段上的解析器，它使用您的第二個 API（“員工觀察日志”）作為數據源，其中查詢字段employees使用第一個 API 作為其數據源。

此解析器應使用上下文源字段（“父”值，在本例中為您可以引用的Employee的id和name ）進行查詢。 您可以在 VTL 代碼中引用它，例如使用$ctx.source.id或$ctx.source.name如果您需要名稱）。

這個解析器應該只查詢單個Employee 的狀態，因為它會在您的查詢字段employees中的每個結果中調用一次。

還有另一種選擇，即有一個 2 function 管道解析器，其中每個 function 指向不同的數據源：

• 第 1 步解析除lastObservedStatus之外的所有字段
• 第 2 步解析lastObservedStatus並將結果與$ctx.prev.result 。

這實現起來會比較麻煩，但如果設計得當，將需要更少的 API 調用。