GraphQL是為聚合統一而構建的 - thenewstack

當組織達到一定規模時，他們會圍繞團隊進行組織。團隊通常具有職能職責——營銷、財務、工程等。API 遵循類似的功能對齊方式；我們看到提供營銷功能（促銷、產品描述等）、電子商務功能（購物車等）、財務功能（訂單到現金等）的 API 集。這些 API 通常由專門的開發團隊獨立開發，即使在組織上它們可能在同一個工程組織中。

隨著組織在其 API 旅程中逐漸成熟，並且隨著 GraphQL 被用作下一波 API 技術，他們意識到必須將他們的 REST 用於 GraphQL API。關於將什麼公開為 GraphQL 的決定可以是集中的，也可以由職能團隊決定。隨著團隊和組織變得更大，一個常見的模式是將這些決策分散。因此，企業可能有一個營銷 GraphQL 端點、一個電子商務 GraphQL 端點和一個財務 GraphQL 端點，每個端點都由各自的團隊負責。

然而，現代數字體驗不僅僅建立在一種功能性 GraphQL API 上。例如，電子商務網站可能會結合營銷、電子商務和物流 GraphQL API，僅舉幾例。這些不同的 GraphQL API 如何整合到一個統一的 GraphQL 層中，從而構建這些數字體驗？

關於這些功能性 GraphQL API 如何組合成一個統一層，有多種術語：模式拼接和聯合是最常見的。

讓我們首先闡明構建這個統一的 GraphQL API 需要什麼：

• 這一層應該沒有業務邏輯。它應該主要是佈線和裝配層。換句話說，就電腦科學而言，這一層有責任將請求分散到正確的功能 GraphQL API 並收集結果以返回答案。
• GraphQL 層必須呼叫具有正確身份驗證和授權的功能性 GraphQL API。畢竟不同的功能可以選擇實現自己的機制。
• 它必須能夠處理常見錯誤，包括無響應

當您檢視上述注意事項時，該統一層所需的內容與構建任何其他一個功能性 GraphQL API 所需的內容之間只有一個區別：

功能性 GraphQL API 的後端可以是任何東西：REST、SOAP、資料庫；但這一統一層的後端完全是 GraphQL。

就是這樣！功能式 API 和統一的 GraphQL 層都需要能夠將多個後端連線在一起：

• 兩者都需要在前端和後端處理身份驗證和授權。
• 兩者都需要處理錯誤和效能問題。

在 StepZen 中，任何開發人員——無論是構建功能式 GraphQL API 還是在這一層——都使用四個概念：

• 每個後端公開一個迷你 GraphQL 子圖。這個子圖可以通過內省自動生成，從一些預製的公共端點中選擇，和/或通過將 @rest、@dbquery 和 @graphql 構造新增到手工編寫的 GraphQL 模式檔案 (SDL) 來編寫。
• 這些子圖可以通過使用@materializer 構造將一個子圖中的查詢/變異與另一個子圖中產生的資料連線在一起來連線在一起。
• 一個 YAML 配置檔案，包括對 API 和後端資料來源的訪問控制。該檔案與上面的圖表分開。
• API 和配置交給 StepZen 執行，系統負責優化、快取、錯誤處理等的標準方式。沒有執行或管理的基礎設施，我們保證您的 API 99.99% 的可用性。

使用這四個概念，開發人員可以利用之前對現有 API 和基礎設施的所有投資。

與此同時，組織和前端團隊可以獲得所有 API 都使用一個 GraphQL API 的所有額外好處。