[[321285]]

以下是 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 —— 在他們發現它對應用程序性能和組織敏捷性具有最大的積極影響的地方。