為什麼使用 GraphQL？

以下是 GraphQL 在標準 REST API 技術上獲得發展的原因。

正如我所寫，GraphQL 是一種下一代 API 技術，它正在改變用戶端應用程式與後端系統的通訊方式以及後端系統的設計方式。

由於一開始就從建立它的組織 Facebook 獲得了支援，並得到了其他技術巨頭（如 Github、Twitter 和 AirBnB）的支援，因此 GraphQL 作為應用程式系統的關鍵技術的地位似乎是穩固的 —— 無論現在還是將來。

GraphQL 的崛起

移動應用程式效能和組織敏捷性重要性的提高為 GraphQL 登上現代企業體系結構的頂端提供了助推器。

鑑於 REST 是一種非常流行的體系結構風格，早已提供了資料互動機制，與 REST 相比，GraphQL 這項新技術具有哪些優勢呢？GraphQL 中的 “QL” 代表著查詢語言，而這是一個很好的起點。

借助 GraphQL，組織內的不同用戶端應用程式可以輕鬆地僅查詢所需資料，這一點超越了其它 REST 方法，並帶來了實際應用程式效能的提高。使用傳統的 REST API 端點，用戶端應用程式將詳詢伺服器資源，並接受包含了與請求匹配的所有資料的響應。如果來自 REST API 端點的成功響應返回 35 個欄位，那麼用戶端應用程式就會收到 35 個欄位。

獲取的問題

傳統上，REST API 沒有為用戶端應用程式提供簡便的方法來僅檢索或只更新它們關心的資料。這通常被描述為“過度獲取over-fetching”的問題。隨著移動應用程式在人們的日常生活中的普遍使用，過度獲取問題會給現實世界帶來不良後果。移動應用程式發出的每個請求、每一個位元組的接受和傳送，對終端使用者的效能影響越來越大。資料連線速度較慢的使用者尤其會受到不太好的 API 設計方案的影響。使用移動應用程式而效能體驗不佳的客戶更有可能不購買產品或不使用服務。低效的 API 設計只會浪費企業的錢。

並非只有“過度獲取”是問題，“欠缺獲取”同樣也是問題。預設情況下，端點只返回用戶端實際需要的部分資料，這需要用戶端進行額外的呼叫以滿足其資料需求，這就產生了額外的 HTTP 請求。由於過度和欠缺的獲取問題及其對用戶端應用程式效能的影響，促進有效獲取的 API 技術才有機會在市場上引起轟動 —— GraphQL 大膽地介入並填補了這一空白。

REST 的應對

REST API 設計師不甘心不戰而退，他們試圖通過以下幾種方式來應對移動應用程式效能問題：

• “包含”和“排除”查詢引數，允許用戶端應用程式通過可能較長的查詢格式來指定所需的欄位。

• “復合”服務，將多個端點組合在一起，以使用戶端應用程式在其發出的請求數量和接收到的資料方面更高效。    儘管這些模式是 REST API 社群為解決移動用戶端所面臨的挑戰而做出的英勇嘗試，但它們在以下幾個關鍵方面仍存在不足：

• 包含和排除查詢鍵/值對很快就會變得混亂，特別是對於需要用巢狀“點表示法”語法（或類似方法）以對目標資料進行包含和排除的深層物件圖而言，更是如此。此外，在此模型中偵錯查詢字串的問題通常需要手動分解 URL。

• 包含和排除查詢的伺服器的實現往往是自定義的，因為基於伺服器的應用程式沒有標準的方式來處理包含和排除查詢的使用，就像沒有定義包含和排除查詢的標準方式一樣。

• 複合服務的興起形成了更加緊密耦合的後端和前端系統，這就需要加強協調以交付專案，並且將曾經的敏捷專案轉回瀑布式開發。這種協調和耦合還有一個痛苦的副作用，那就是減宦了組織的敏捷性。此外，顧名思義，組合服務不是 RESTful。   

  GraphQL 的起源

對於 Facebook 來說，從其 2011-2012 年基於 HTML5 版本的旗艦移動應用程式中感受到的痛點和體驗，才造就了 GraphQL。Facebook 工程師意識到提高效能至關重要，因此意識到他們需要一種新的 API 設計來確保最佳效能。可能考慮到上述 REST 的局限性，並且需要支援許多 API 用戶端的不同需求，因此人們可以理解是什麼導致其共同建立者 Lee Byron 和 Dan Schaeffer（那時尚是 Facebook 員工）建立了後來被稱之為 GraphQL 的技術的早期種子。

通過 GraphQL 查詢語言，用戶端（通常是單個 GraphQL 端點）應用程式通常可以顯著減少所需的網路呼叫數量，並確保僅檢索所需的資料。在許多方面，這可以追溯到早期的 Web 程式設計模型，在該模型中，用戶端應用程式程式碼會直接查詢後端系統 —— 比如說，有些人可能還記得 10 到 15 年前在 JSP 上用 JSTL 編寫 SQL 查詢的情形吧！

現在最大的區別是使用 GraphQL，我們有了一個跨多種用戶端和伺服器語言和庫實現的規範。借助 GraphQL 這樣一種 API 技術，我們通過引入 GraphQL 應用程式中間層來解耦後端和前端應用程式系統，該層提供了一種機制，以與組織的業務領域相一致的方式來存取組織資料。

除了解決軟體工程團隊遇到的技術挑戰之外，GraphQL 還促進了組織敏捷性的提高，特別是在企業中。啟用 GraphQL 的組織敏捷性通常歸因於以下因素：

• GraphQL API 設計人員和開發人員無需在用戶端需要一個或多個新欄位時建立新的端點，而是能夠將這些欄位包含在現有的圖實現中，從而以較少的開發工作量和跨應用程式系統的較少更改的方式展示出新功能。
• 通過鼓勵 API 設計團隊將更多的精力放在定義物件圖上，而不是在專注於用戶端應用程式交付上，前端和後端軟體團隊為客戶交付解決方案的速度日益解耦。    ### 採納之前的注意事項

儘管 GraphQL 具有引人注目的優勢，但 GraphQL 並非沒有實施挑戰。一些例子包括：

• 為 REST API 建立的快取機制更加成熟。
• 使用 REST 來構建 API 的模式更加完善。
• 儘管工程師可能更喜歡 GraphQL 等新技術，但與 GraphQL 相比，市場上的人才庫更多是從事於構建基於 REST 的解決方案。

結論

通過同時提高效能和組織敏捷性，GraphQL 在過去幾年中被企業採納的數量激增。但是，與 API 設計的 RESTful 生態系統相比，它確實還需要更成熟一些。

GraphQL 的一大優點是，它並不是作為替代 API 解決方案的批發替代品而設計的。相反，GraphQL 可以用來補充或增強現有的 API。因此，鼓勵企業探索在 GraphQL 對其最有意義的地方逐步採用 GraphQL —— 在他們發現它對應用程式效能和組織敏捷性具有最大的積極影響的地方。