作者 | Khalil Stemmler
策劃 | 田曉旭
在服務器上使用 GraphQL 代替 REST 是有很多好處的，使用 Apollo Client 取代自己編寫的數據獲取邏輯也有很多優勢。在這篇文章中，我們主要討論 GraphQL 最突出的架構優勢。
本文最初發布于 khalilstemmler.com 網站，經原作者授權由 InfoQ 中文站翻譯并分享。
在過去的幾年中，我們已經看到各種規模和形態的公司都開始在整個組織中逐漸采用 GraphQL，例如 Expedia、Nerdwallet 和 Airbnb。在本文中，我們將討論在未來或現有的項目中使用 GraphQL 都將享受哪些架構優勢。
1六邊形架構
Alistair Cockburn 在“六邊形架構”中提到，我們架構的最內層是應用程序和域層。在這一層的外面是適配器（或端口）。
可以將端口視為“將外部世界連接到內部世界的一種方式”。外部世界有很多技術，我們可以在其之上構建應用程序。在外部，你能找到數據庫、外部 API、云服務和種種內容。如果我們采用依賴倒置方法，就可以定義一些端口來將它們安全地包含在我們的應用程序中。端口是抽象、合約。它們通常以接口或抽象類的形式出現。
Alistair Cockburn 的“六邊形架構”
我非常贊同這種類型的架構，因為它使我們能夠：
直到真正有必要做出決策時，才決定到底采用哪種類型的 Web 服務器、數據庫、事務電子郵件提供商或緩存技術。在開發工作早期，我們完全可以使用一個端口的內存內實現。
通過依賴注入方法，這種架構還會讓開發人員優先編寫可以測試的代碼。這樣我們就可以盡可能地減少可能導致代碼不可測試的具體依賴項。
最后，它將我們的關注點轉向了應用程序和特定于域的內容。這些內容是不能直接從市場購買或下載的。
2基礎架構組件
GraphQL 服務器和 HTTP 服務器都屬于基礎架構組件。
基礎架構組件：構成 Web 應用程序基礎的基本組件。根據整潔（或六邊形）架構的思想，數據庫、Web 服務器和緩存都是外層基礎架構組件。
我們之所以將基礎設施組件稱為基礎設施，是因為我們會在它們的基礎上構建應用程序。在這一基礎（即框架）內，我們編寫豐富的、領域特定的應用程序?；A設施只是驅動程序而已。
基礎架構組件的另一個主要特征是，它們不是我們項目開發工作的重心。
基礎架構組件是業界信任的一系列工具，我們只需對其配置即可使其正常工作。
GraphQL API 的配置工作包括：
安裝 GraphQL
公開一個服務器端點
設計一個模式（schema）
將解析器連接到數據源
這是我們需要做的工作，但不是我們項目的工作重心。
如果某項基礎架構技術受到業界的信任，我們就可以選擇用這種工具來完成任務，而不是開發自己的基礎架構組件，這樣就可以加快我們的開發速度。
考慮數據庫。它們也是基礎設施。
例如，Postgres 數據庫是我們可以用于新項目的幾個數據庫選項之一。想象一下，如果你試圖說服你們的團隊，你們的項目應該從頭開始編寫自己的數據庫，其他人會有多么大的反對聲。
如果有人說團隊應該從頭開始研發一種持久性存儲技術，大家肯定會覺得這樣的場面看起來很愚蠢；但選擇你的 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 中）讓開發人員可以編寫幾乎同時解決遠程狀態和本地狀態的查詢。遠程狀態（位于服務器上）感覺比之前近多了。
比如說用這種查詢來按照狗的品種（breed）來獲取一只狗：
查詢 /dog.js
const GET_DOG = gql`query GetDogByBreed($breed: String!) {dog(breed: $breed) {images {urlidisLiked @client # signal to resolve locally}}}`;
在主要用于獲取遠程資源的查詢中，我們可以使用 @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 原則在版本控制方面也有很強的見解。它指出：
“模式應根據實際需求逐步構建，并隨著時間的推移平穩發展?！?/blockquote>這意味著團隊應該通過迭代來做更改，而不是在大版本中一次塞入很多更改，這樣就可以實踐敏捷模式開發了。
聽上去一切都很完美，但是你我都生活在現實世界中。我知道這樣理想化的情況并不總是存在，至少沒有適當的工具鏈是不可能做到的。
Apollo 平臺有一項稱為模式驗證的特性，可讓你針對實時生產流量測試每個更改，并在建議實施重大更改時向你顯示提示，讓團隊可以交流接下來的方案。
這種感覺很順滑！
10總結
在現代 Web 應用程序架構中，GraphQL 和 RESTfulWeb 服務器都是基礎架構組件。
基礎架構組件是基本組件，它們構成了我們編寫的特定領域 Web 應用程序的基礎。
基礎架構組件并不是大多數 Web 開發項目的重心，因此我們應該將大部分時間用于應用程序和域層代碼。
數據圖是一個聲明性的、自文檔化的、組織層面的 GraphQL API，它使遠程狀態更接近客戶端，可以使用 Apollo Federation 來擴展。
前端開發人員可以使用數據圖來創建自己的數據獲取用例，而不必依賴后端開發人員。
GraphQL 消除了管理 API 版本的需要，Apollo 的 GraphManager 可以簡化生產模式驗證。
原文鏈接
https://khalilstemmler.com/articles/graphql/graphql-architectural-advantages/
