GraphQL 查詢多個列表為 arguments

Question

這是關於將 GraphQL 添加到現有的 Java api 中，它將多個列表作為輸入。

背景：

我有一個基於 Java 的現有 REST API getFooInformationByRecognizer ，它接收識別器列表，其中每個識別器 object 包含一個 id 及其類型，並返回與每個 id 對應的信息。 只有 3 種可能的類型是 A、B 或 C。輸入可以是這些類型的任意組合。

例如：

[{"id": "1", "type": "A" }, {"id": "2", "type": "B"},{"id": "3", "type": "C"}, {"id": "4", "type": "A"}, {"id":"5", "type": "B"}]

這是 Java 的表示：

class FooRecognizer{
     String id;
     String FooType;
}

這個 api 做了一些處理。 首先提取所有具有 A 類型 ID 的輸入，並獲取與這些 ID 對應的信息。 類似地，提取具有類型 B 的 id 並獲取與這些 id 對應的信息，對於 C 也是如此。因此，它從 3 個不同的來源獲取數據，最后將它們整理成一個 map 並返回。 例如：

ids of type A --> A SERVICE -> <DATA SOURCE FOR A>
ids of type B --> B SERVICE --> <DATA SOURCE FOR B>
ids of type C --> C SERVICE --> <DATA SOURCE FOR C>

最后這樣做：A信息+B信息+C信息，把這個放到一個Java Hashmap中。

對此服務的請求的 Java 表示為：

class FooRequest{
   private Bar bar;
   List<FooRecognizer> list;
}

來自服務的響應 object 的 Java 表示是：

class FooInformationResponse{
   private Map<String, FooRecognizer> fooInformationCollated;
}

響應的樣本 JSON output 是：

 "output":{
    "fooInformationCollated":{
    "1":{
       "someProperty": "somePropertyValue"
       "listOfNestedProperties": [{"x": "xValue", "y": "yValue", "z","zValue"]
       "nestedProperty":{
          "anotherProperty":{
            "furtherNestedProperty": "value"
          }
        }
      }
   "2":{
        "someProperty": "somePropertyValue"
        "listOfNestedProperties": [{"a": "aValue", "b": "bValue", "c","cValue"]
        "nestedProperty":{
           "anotherProperty":{
             "furtherNestedProperty": "value"
          }
        }
      }
    }... and so on for other ids in the input

現在，我想將此服務轉換為 GraphQL，這是我的查詢。

query{
  getFooInformationByRecognizer(filterBy:{
    fooRecognizer: [{
            id: "1",
            fooType: A
        }],
        bar: {
            barId: "someId",
            ...<other bar info>
        }
  }){
    fooInformationCollated{
      id
      fooInformation{
        someProperty
        listOfNestedProperties
        nestedProperty{
         anotherProperty{
            furtherNestedProperty
          }
        }

      }
    }
  }
}

這是我的 GraphQL 架構：

type Query{
    getFooInfoByRecognizer (filterBy: getFooByRecognizerTypeFilter!):getFooByRecognizerTypeFilterResponse
}

input getFooByIdentifierTypeFilter{
    bar: Bar!
    fooIdentifiers: [FooIdentifier!]!
}

input Bar{
    barId: String!
    ....
}


input FooIdentifier{
    id: String!
    fooIdType: fooIdtype!
}

enum fooIdType{
    A
    B
    C
}

我在這里有幾個問題：

1. 這是表示此查詢的最佳方式/最佳實踐嗎？ 或者我應該 model 我的查詢才能包含 3 個單獨的列表。 例如： query getFooInformationByRecognizer(barId, listOfAs, listOfBs, listOfCs) 。 我必須查詢的任何其他選擇 / model？
2. 我發現擁有復雜的輸入類型是最簡單的。 一般來說，是否有任何特定的理由選擇復雜輸入類型而不是其他選擇，反之亦然？
3. 我應該關注與查詢性能相關的任何事情嗎？ 我試過研究DataLoader / BatchLoading但這似乎不太適合這種情況。 我不認為 N+1 問題應該是一個問題，因為我還將為 A、B 和 C 創建單獨的解析器，但是可以看到，一旦返回 JSON 作為響應，查詢就不會進一步調用后端。

Answer 1

這個問題太寬泛，無法具體回答，但這是我最好的嘗試。

1. 雖然沒有關於 1 個復雜輸入參數與多個更簡單的 arguments 的明確答案，但 1 個復雜參數通常更可取，因為客戶端更容易傳遞單個變量，並且它使 GraphQL 文件更小。 這對於突變來說可能更有趣，但無論如何它都是一個很好的啟發式方法。 請參閱本文中更詳細地解釋它的邏輯。

2. 上面解釋的邏輯與你自己的觀察相呼應

3. 對於您列出的這個特定場景，我看不到任何對性能重要的東西。 您似乎在一個 go（沒有 N+1）中獲取了整個列表，因此與您為 REST 端點所做的沒有太大區別。 現在，我不能說獲取低級字段的成本有多高（例如，您是否需要 JOIN 或 .network 調用或其他），但如果有任何重要的邏輯，您可能希望通過向前看來優化它在解析頂級字段之前進入子選擇。