繼 Spring GraphQL 專案的公告和 1.0 里程碑版本的可用性之後，這篇部落格文章旨在提供更多詳細資訊。

簡介

如果您想開始使用，請前往我們的參考文件並閱讀 "Boot Starter" 區段，或執行範例。

如果您對 GraphQL 不太了解，有很多不錯的資源。您可以從 graphql.org/learn 開始。

根據 InfoQ 2020 年的 架構趨勢，GraphQL 已被 廣泛採用，並且處於 "早期多數" 階段。 它提供了一種更注重資料的 REST API 替代方案，並為客戶端提供架構和查詢語言。 從客戶端角度來看，這種吸引力在這份 State of JavaScript 報告中顯而易見。 您可以閱讀 GitHub 的故事，了解他們為何使用 GraphQL。

基礎支援

正如 Andy Marek 在開篇部落格中所寫，Spring GraphQL 被認為是 GraphQL Java 團隊的 GraphQL Java Spring 專案的繼承者。 這就是為什麼我們合作的最初重點是匹配該功能，並以最佳方式整合 GraphQL Java 和 Spring。

為此，我們建立了以下基礎支援：

• HTTP 處理器 -- 適用於 Spring MVC 和 WebFlux，建立在 WebMvc 和 WebFlux functional endpoint APIs 之上。
• WebSocket 處理器 -- 遵循來自 graphql-ws 的 協議，支援 GraphQL 訂閱流。
• Web 攔截 -- 能夠攔截每個 GraphQL 請求，檢查 HTTP 標頭，並修改 GraphQL ExecutionInput 或 ExecutionResult。
• Boot starter -- 將所有內容整合到一個可運行的應用程式中。

除此之外，我們開始關注安全性、測試和指標等關鍵方面。

安全性

GraphQL 端點的 URL 像往常一樣容易保護。 為了更精細的安全性，應用程式可以在資料檢索方法上使用 Spring Security 註解。 這需要 Spring Security 上下文傳播到資料檢索方法，雖然 GraphQL Java 對 執行緒是中性的，但執行中的元件本身可以是異步的，並導致執行緒切換。

這促使我們添加了從 Web 框架層級、通過 GraphQL 引擎以及到資料提取元件的上下文傳播支援。 這包括 Spring MVC 和 WebFlux 應用程式的 ThreadLocal 上下文和 Reactor Context。 在這些功能就位後，Spring Security 無需任何進一步的專門整合即可運作。

webmvc-http 和 webflux-security 範例展示了 Spring Security 的使用。

例外處理

Spring GraphQL 讓應用程式能夠建立多個獨立的 GraphQlExceptionResolver 元件，以將異常解析為 GraphQL 錯誤，以便包含在 GraphQL 回應中。 它還提供了一個 ErrorType 類型，用於對具有常見類別的錯誤進行分類，例如預設情況下的 BAD_REQUEST、UNAUTHORIZED、FORBIDDEN、NOT_FOUND 或 INTERNAL_ERROR。

測試

您可以使用 WebTestClient 測試 GraphQL 請求，只需發送和接收 JSON。 然而，GraphQL 特定的細節使這種方法比應有的更加繁瑣。

這就是 Spring GraphQL 包含 WebGraphQlTester 的原因，它定義了測試 GraphQL 請求的工作流程。 它提供以下好處：

• 驗證 GraphQL 回應是否為 200 (OK)。
• 驗證回應的 "errors" 鍵下沒有意外的錯誤。
• 解碼回應中的 "data" 鍵。
• 使用 JsonPath 解碼回應的不同部分。
• 測試訂閱。

所有 範例 都使用 GraphQlTester。

指標

當存在 starter spring-boot-starter-actuator 時，會收集 GraphQL 請求的指標，包括請求和 DataFetcher 執行計時器以及錯誤計數器。

Querydsl 整合

Querydsl 提供了一種靈活且類型安全的方法來表達查詢謂詞。 Spring GraphQL 建立在 Spring Data Querydsl 擴展之上，使其易於建立 Querydsl 支持的 DataFetcher。 它從 GraphQL 請求參數準備 Querydsl Predicate，並使用它來提取資料，適用於 JPA、MongoDB 和 LDAP。

webmvc-http 範例使用 Querydsl。

Schema-First vs Object-First (先架構還是先物件)

GraphQL 提供了一種架構語言，可幫助客戶端建立有效的請求，啟用 GraphiQL UI 編輯器，促進團隊之間的通用詞彙等等。 它還提出了schema vs object-first 開發的老問題。

我們的看法是，應優先選擇 schema-first 開發。 它有助於技術和非技術背景的人員進行對話，有助於工具，更容易追蹤變更等等。 GraphQL 架構和 Java 類型之間也沒有一對一的映射。

也就是說，程式碼產生也有空間，可以開始，客戶端可以建立查詢等等。 像 Netflix DGS 這樣的框架對此有很好的支援，可以與 Spring GraphQL 一起使用。

Roadmap (路線圖) 和意見回饋

我們計劃在 SpringOne (9月2日至3日) 之前發布第二個里程碑版本。 我們已經從早期回饋中獲得了一些M2 的問題，包括對 GraphQL 客戶端、BatchLoader 註冊、檔案上傳等的支援。

里程碑階段將持續到 11 月 Spring Boot 2.6 之後，屆時 Boot starter 計劃移至 Spring Boot 儲存庫，以便包含在 Boot 2.7 中。

我們的目標是擁有穩定的 API，並在今年稍晚進入 RC 階段。為了達成這個目標，我們需要您的回饋。請試用看看，並在我們的 issue tracker 中創建 issue，或在現有的 issue 下方留言。

資源

有關 Spring GraphQL 功能的更多詳細資訊，請查看參考文檔。

GraphQL Java 和 Spring 團隊將在今年的 SpringOne 會議上聯合發表，今年這場會議將再次免費且線上舉辦，這已是連續第二年。 請註冊參加我們的演講，並與講者和與會者互動。