我很高興地宣佈，Spring for GraphQL 1.2.0 的第一個里程碑版本現已從我們的里程碑倉庫釋出。此版本將隨定於本週四釋出的 Spring Boot 3.1.0-M2 一同提供。

第一個里程碑將基準提升至 GraphQL Java 20.0，未來我們將遵循新的 GraphQL Java 釋出策略。我們還將升級到下一代 Spring Framework、Spring Data 和 Spring Security。

分頁支援

在使用 GraphQL 導航大型結果集時，遊標連線規範非常流行。藉助新增的對它的支援功能，Spring for GraphQL 應用可以利用該規範，並向客戶端提供現代化的分頁和滾動功能。

該規範為每個結果項分配一個唯一的遊標，客戶端可以使用該遊標來請求遊標引用之後或之前的專案，作為向前或向後導航的一種方式。

使用以下 schema，我們會注意到“Connection”欄位型別，但沒有對應的型別宣告

Query {
    books: BookConnection
}

type Book {
    id: ID!
    title: String!
}

Spring for GraphQL 將自動新增所需的樣板程式碼和 schema 型別定義 - 您無需在 schema 中編寫以下內容

type BookConnection {
    edges: [BookEdge]!
    pageInfo: PageInfo!
}

type BookEdge {
    node: Book!
    cursor: String!
}

type PageInfo {
    hasPreviousPage: Boolean!
    hasNextPage: Boolean!
    startCursor: String
    endCursor: String
}

此外，也無需更改您的 Controller 來返回和填充此類 Connection 型別，封裝底層資料項並建立項遊標。有一個新的 ConnectionAdapter 契約，它一次性實現這些樣板工作，並將其應用於每個 Connection 型別欄位。

開發者可以實現自己的介面卡，或使用針對現有 Spring Data Slice 分頁型別和新 Window 型別的內建介面卡。我們與 Spring Data 團隊合作，提供了與 GraphQL 應用需求一致的遊標支援。有關更多詳細資訊，請參閱關於支援基於偏移量和基於鍵的分頁的新 Spring Data Scroll API 的部落格文章。

要了解有關 Spring GraphQL 1.2 M1 中分頁支援的更多資訊，請查閱專案的更新參考文件。

啟動時的 Schema 對映檢查

Spring for GraphQL 偏愛 schema-first 方法，其中 schema 是與客戶端簽訂的、編寫良好、有文件的契約。Controller 註解模型使得無需編寫樣板程式碼即可輕鬆對映到該 schema。然而，一個方面是，在開發週期中，您的程式碼中的某個地方可能遺漏了 Java 屬性或 @SchemaMapping 註解，結果導致某個欄位未被對映。開發者在測試 GraphQL API 時會注意到這一點，並且它會在響應圖中返回意外的 null 值。

社群要求 Spring for GraphQL 在啟動時警告他們，如果他們的 DataFetcher 或 @Controller 配置未能滿足整個 schema。在啟動階段，您將看到類似以下的日誌

INFO 91221 --- [  restartedMain] efaultSchemaResourceGraphQlSourceBuilder :
  GraphQL schema inspection found missing mappings for: Query[authorById], Book[missing].

Spring for GraphQL 將遞迴訪問 Query、Mutation 和 Subscription 型別，檢查欄位是否註冊了 DataFetcher 例項或 Controller 處理程式，或者是否存在 Java 屬性。缺失的條目不會導致啟動序列失敗，但會在控制檯日誌中報告。

這可能是邁向更豐富功能的第一步，但目前我們尚未暴露任何用於配置它的公共 API。我們也意識到了一些限制，例如 Union 型別的檢查（這些型別會被完全跳過）。請在我們的 issue tracker 中報告您在 schema 中遇到的問題！

帶註解的異常處理方法

我們一開始並未新增此功能，因為認為應用可以註冊任意數量的 DataFetchingExceptionResolver 例項，每個例項處理特定異常。然而，缺少內建的異常匹配功能導致了大量的 instanceof 型別檢查，並且通常只有一個解析器來處理所有異常。

第一個 1.2 里程碑版本提供了對 @GraphQlExceptionHandler 註解的處理方法的支援，這些方法可以在 @Controller 中本地宣告和應用，或者透過 @ControllerAdvice 在多個 Controller 和資料抓取器之間應用。

這種帶註解的異常處理方法也可以處理 @SubscriptionMapping 方法丟擲的異常，無論是方法在被呼叫返回 Publisher 時發生的異常，還是在 Publisher 開始發出資料後發生的異常。

如何提供幫助？

如果您有一般性問題，請在 stackoverflow.com 上使用 spring-graphql 標籤提問。

專案主頁 | GitHub | 問題跟蹤 | 文件 | Stack Overflow