GraphQL 最突出的架構優勢是什麼？

作者 | Khalil Stemmler

策劃 | 田曉旭

在服務器上使用 GraphQL 代替 REST 是有很多好處的，使用 Apollo Client 取代自己編寫的數據獲取邏輯也有很多優勢。在這篇文章中，我們主要討論 GraphQL 最突出的架構優勢。

1 六邊形架構

Alistair Cockburn 在 “六邊形架構” 中提到，我們架構的最內層是應用程序和域層。在這一層的外面是適配器（或端口）。

可以將端口視爲 “將外部世界連接到內部世界的一種方式”。外部世界有很多技術，我們可以在其之上構建應用程序。在外部，你能找到數據庫、外部 API、雲服務和種種內容。如果我們採用依賴倒置方法，就可以定義一些端口來將它們安全地包含在我們的應用程序中。端口是抽象、合約。它們通常以 接口 或 抽象類 的形式出現。

Alistair Cockburn 的 “六邊形架構”

我非常贊同這種類型的架構，因爲它使我們能夠：

• 最後，它將我們的關注點轉向了應用程序和特定於域的內容。這些內容是不能直接從市場購買或下載的。

2 基礎架構組件

GraphQL 服務器和 HTTP 服務器都屬於基礎架構組件。

基礎架構組件：構成 Web 應用程序基礎的基本組件。根據整潔（或六邊形）架構的思想，數據庫、Web 服務器和緩存都是外層基礎架構組件。

我們之所以將基礎設施組件稱爲基礎設施，是因爲 我們會在它們的基礎上構建應用程序。在這一基礎（即框架）內，我們編寫豐富的、領域特定的應用程序。基礎設施只是驅動程序而已。

基礎架構組件的另一個主要特徵是，它們不是我們項目開發工作的重心。

基礎架構組件是業界信任的一系列工具，我們只需對其配置即可使其正常工作。

GraphQL API 的配置工作包括：

• 安裝 GraphQL

• 公開一個服務器端點

• 設計一個模式（schema）

• 將解析器連接到數據源

如果有人說團隊應該從頭開始研發一種持久性存儲技術，大家肯定會覺得這樣的場面看起來很愚蠢；但選擇你的 Web 應用程序 API 樣式（傳輸 / 客戶端 - 服務器技術）其實也是一樣的道理。

去年（2019 年），我意識到 API 在技術棧中的深度已經超出了我們的想象。API 的觸角伸到了前端框架的數據存儲，也伸到了後端服務的合約層面。

這聽起來可能有點虛幻，但它的確就是那樣。在 Apollo GraphQL，我們將這種虛擬層稱爲數據圖。並且 Apollo 構建了很多可提高開發人員生產效率的工具。

3 數據圖

數據圖 這個理念我是最早在 2019 年 GraphQL 峯會上聽 Apollo GraphQL 的首席技術官 Matt DeBergalis 提出的。我強烈推薦 Matt 在 2019 年 GraphQL 峯會上的演講，他介紹了數據圖的概念。

https://youtu.be/EDqw-sGVq3k

數據圖是虛擬層，位於我們的客戶端應用程序和 GraphQL 服務器之間。它保存了整個組織的數據，並提供了用來在整個組織內獲取和更改狀態的語言。

數據圖是一個聲明性的、自文檔化的、組織層面的 GraphQL API。

對我來說，數據圖是現代應用程序技術棧中之前 缺少的一個層。

基本的全棧 Apollo Client+Server 應用程序棧

4 數據圖讓遠程狀態更接近客戶端本地狀態

所有前端框架都需要解決的三個挑戰分別是數據存儲、更改檢測和數據流。

React 開發人員通常需要修補 Redux 或 Context，並編寫大量樣板代碼來滿足這些要求。

Apollo 發佈了帶有 apollo-link-state 的 Apollo Client 後，React 開發人員就能用更少的代碼滿足所有這三個需求了。

Apollo-link-state（現已直接放入 Apollo Client 2 和 3 中）讓開發人員可以編寫幾乎同時解決遠程狀態和本地狀態的查詢。遠程狀態（位於服務器上）感覺比之前近多了。

 1const GET_DOG = gql`
 2  query GetDogByBreed($breed: String!) {
 3    dog(breed: $breed) {
 4      images {
 5        url
 6        id
 7        isLiked @client # signal to resolve locally
 8      }
 9    }
10  }
11`;
12

在主要用於獲取遠程資源的查詢中，我們可以使用 @client 指令來引用要基於一個客戶端模式從本地緩存中獲取的屬性。我們可以在同一請求中完成這一操作，這很厲害。想想之前在 Redux 環境我們要執行的 spread 和 Object.assign() 操作的數量有多少，就可以對比出差異了。

簡化的數據獲取架構，其中視圖可以是任意前端框架——nerdwallet

數據圖在連接的兩端均有 Apollo 服務器和客戶端，它可以簡化獲取邏輯、錯誤邏輯、重試邏輯、分頁、緩存、optimistic UI 以及其他各種類型的樣板數據管道代碼。

數據圖從客戶端延伸到服務器，併爲現代 Web 應用程序中獲取數據和更改狀態時面臨的最常見基礎架構問題提供了答案

爲了通過 GraphQL 與後端服務通信，Apollo Client 公開了幾種客戶端方法，這些方法在被調用時會將操作轉換爲適當的 API 以跨越數據圖。

在 Apollo Server 端，這些 API 調用將控制權轉交給負責使用 ORM、原始 SQL、緩存、其他 RESTfulAPI 或任何你想到的方法來獲取數據的解析器。對於突變，解析器可以簡單地將控制權傳遞給一個應用層用例。

將用例作爲應用程序的重心後，從 REST 切換到 GraphQL（或同時支持兩者）變得輕而易舉。

5GraphQL 是自文檔化的

維護 RESTfulAPI 時需要做的一件麻煩事是保持文檔及時更新和內容全面。

RESTfulAPI 有兩處可以更改。

• 路由 + 方法組合

• 請求形式 + 參數

路由 + 方法組合 的一個例子是，某人可以很簡單地將 創建一個用戶 的操作從 POST /users 移至 POST /users/new。這樣的 API 更改可能不會引起注意，卻會破壞 API 的所有客戶端，並且 API 客戶端幾乎不可能檢測到該組合的更改。

請求形式 + 參數 的一個例子是，一個對 /users/new 的 POST 請求過去只需要一個 email 和一個 password，但現在它還需要一個 username 屬性。API 客戶端了解如何解決該請求的唯一方法是檢查錯誤響應（指望錯誤消息描述了所需的信息，否則也沒用）。

如果你認爲自省（introspection）是全面的文檔，那麼可以說 GraphQL 是自文檔化的，並且你的 API 文檔無法失去同步。

使用 GraphQL Playground，可以瀏覽 GraphQL 端點的所有功能。

由於具備執行自省查詢的能力，所以 GraphQL Playground 的 GraphQL 資源管理器可以顯示 GraphQL 端點的所有功能

在 REST 領域中，我只看到了使用 Swagger 構建的 API 具有這麼大的元數據量。這是一項非常強大的特性，它不僅讓代碼成爲了文檔的唯一真實來源，而且爲我們提供了通過代碼生成來自動創建 TypeScript 類型、客戶端庫或服務到服務通信的基礎。

由於 GraphQL 語言是通行（ubiquitous）且標準化的，因此人類 和機器 會更容易理解如何集成和使用它。

6 關注點的擴展和分離

GraphQL 原則指出，

“你的公司應該有一個統一的圖，而不是讓各個團隊創建很多圖。”

隨着越來越多的團隊開始使用 GraphQL，公司內部會出現多個圖的情況。

使用 Apollo Federation，每個服務團隊都可以從其限界上下文中構建和管理自己的 GraphQL 服務，將其註冊到一個 Apollo 網關，從而在整個企業中分佈化 GraphQL 的運維工作。

通過 Apollo Federation，我們可以繪製並公開由多個 GraphQL 端點組成的單個數據圖

在 Federation 中，你可以組成模式並解析其他服務 / 限界上下文中的字段。收到請求時，將從相應的服務中解析這些字段。

對於規模龐大的組織來說，這種需求並不罕見。

7 單一端點

SOLID 原則中的開閉原則指出：

“組件 / 系統 / 類應對擴展開放，但對修改封閉”。

在架構層面，由於 GraphQL 僅向客戶端公開單個端點，因此它滿足了這一原則。

客戶端隱藏了字段解析機制的所有複雜性，它只需關注如何在 GraphQL 服務器之上構建即可。

該圖描述了組織的數據圖隨時間的演變

8 擴張前端開發人員的權力

數據圖減少了前端開發人員對後端開發人員的依賴，這樣前者就可以自行爲新的用例開發新的端點。

很多時候，我們對 UI 所做的微小改動也會讓我們替換掉組件，或意識到我們錯誤地判斷了數據需求，並且需要爲一些組件添加更多字段。因爲這種情況經常發生，並且因爲 REST 如此嚴格，所以每當我們需要調整的時候都必須依賴後端團隊來更改 REST API。

根據團隊的結構，以下每個問題都可能意味着開發人員的生產力下降，並需要依賴後端團隊。

• 團隊是碎片化的嗎？前端開發人員是隻做前端開發，還是允許他們完成技術棧另一端的工作？

• 你的後端開發人員是否在遠程工作？

• 你的後端開發人員在辦公室工作嗎？

9GraphQL 消除了管理 API 版本的需求

GraphQL 原則在版本控制方面也有很強的見解。它指出：

“模式應根據實際需求逐步構建，並隨着時間的推移平穩發展。”

這意味着團隊應該通過迭代來做更改，而不是在大版本中一次塞入很多更改，這樣就可以實踐敏捷模式開發了。

聽上去一切都很完美，但是你我都生活在現實世界中。我知道這樣理想化的情況並不總是存在，至少沒有適當的工具鏈是不可能做到的。

Apollo 平臺有一項稱爲模式驗證的特性，可讓你針對實時生產流量測試每個更改，並在建議實施重大更改時向你顯示提示，讓團隊可以交流接下來的方案。

這種感覺很順滑！

10 總結

• 在現代 Web 應用程序架構中，GraphQL 和 RESTfulWeb 服務器都是基礎架構組件。

• 基礎架構組件是基本組件，它們構成了我們編寫的特定領域 Web 應用程序的基礎。

• 基礎架構組件並不是大多數 Web 開發項目的重心，因此我們應該將大部分時間用於應用程序和域層代碼。

• 數據圖是一個聲明性的、自文檔化的、組織層面的 GraphQL API，它使遠程狀態更接近客戶端，可以使用 Apollo Federation 來擴展。

• 前端開發人員可以使用數據圖來創建自己的數據獲取用例，而不必依賴後端開發人員。

• GraphQL 消除了管理 API 版本的需要，Apollo 的 GraphManager 可以簡化生產模式驗證。

原文鏈接

https://khalilstemmler.com/articles/graphql/graphql-architectural-advantages/

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/hdtjwcHALXggHPQgEJu21w