為什麼使用 GraphQL？
以下是 GraphQL 在標準 REST API 技術上獲得發展的原因。
-- Zach Lendon
正如我以前所寫，GraphQL是一種下一代 API 技術，它正在改變客戶端應用程序與後端系統的通信方式以及後端系統的設計方式。
由於一開始就從創建它的組織 Facebook 獲得了支持，並得到了其他技術巨頭（如 Github、Twitter 和 AirBnB）的支持，因此 GraphQL 作為應用程序系統的關鍵技術的地位似乎是穩固的 —— 無論現在還是將來。
GraphQL 的崛起
移動應用程序性能和組織敏捷性重要性的提高為 GraphQL 登上現代企業體系結構的頂端提供了助推器。
鑒於REST是一種非常流行的體系結構風格，早已提供了數據交互機制，與REST相比，GraphQL 這項新技術具有哪些優勢呢？GraphQL 中的 「QL」 代表著查詢語言，而這是一個很好的起點。
藉助 GraphQL，組織內的不同客戶端應用程序可以輕鬆地僅查詢所需數據，這一點超越了其它 REST 方法，並帶來了實際應用程序性能的提高。使用傳統的RESTAPI 端點，客戶端應用程序將詳詢伺服器資源，並接受包含了與請求匹配的所有數據的響應。如果來自RESTAPI 端點的成功響應返回 35 個欄位，那麼客戶端應用程序就會收到 35 個欄位。
獲取的問題
傳統上，RESTAPI 沒有為客戶端應用程序提供簡便的方法來僅檢索或只更新它們關心的數據。這通常被描述為「過度獲取(over-fetching)」的問題。隨著移動應用程序在人們的日常生活中的普遍使用，過度獲取問題會給現實世界帶來不良後果。移動應用程序發出的每個請求、每一個位元組的接受和發送，對終端用戶的性能影響越來越大。數據連接速度較慢的用戶尤其會受到不太好的 API 設計方案的影響。使用移動應用程序而性能體驗不佳的客戶更有可能不購買產品或不使用服務。低效的 API 設計只會浪費企業的錢。
並非只有「過度獲取」是問題，「欠缺獲取」同樣也是問題。默認情況下，端點只返回客戶端實際需要的部分數據，這需要客戶端進行額外的調用以滿足其數據需求，這就產生了額外的 HTTP 請求。由於過度和欠缺的獲取問題及其對客戶端應用程序性能的影響，促進有效獲取的 API 技術才有機會在市場上引起轟動 —— GraphQL 大膽地介入並填補了這一空白。
REST 的應對
RESTAPI 設計師不甘心不戰而退，他們試圖通過以下幾種方式來應對移動應用程序性能問題：
? 「包含」和「排除」查詢參數，允許客戶端應用程序通過可能較長的查詢格式來指定所需的欄位。
?「複合」服務，將多個端點組合在一起，以使客戶端應用程序在其發出的請求數量和接收到的數據方面更高效。儘管這些模式是RESTAPI 社區為解決移動客戶端所面臨的挑戰而做出的英勇嘗試，但它們在以下幾個關鍵方面仍存在不足：
?包含和排除查詢鍵/值對很快就會變得混亂，特別是對於需要用嵌套「點表示法」語法（或類似方法）以對目標數據進行包含和排除的深層對象圖而言，更是如此。此外，在此模型中調試查詢字元串的問題通常需要手動分解 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 並非沒有實施挑戰。一些例子包括：
? 為RESTAPI 建立的緩存機制更加成熟。
? 使用REST來構建 API 的模式更加完善。
? 儘管工程師可能更喜歡 GraphQL 等新技術，但與 GraphQL 相比，市場上的人才庫更多是從事於構建基於REST的解決方案。
結論
通過同時提高性能和組織敏捷性，GraphQL 在過去幾年中被企業採納的數量激增。但是，與 API 設計的 RESTful 生態系統相比，它確實還需要更成熟一些。
GraphQL 的一大優點是，它並不是作為替代 API 解決方案的批發替代品而設計的。相反，GraphQL 可以用來補充或增強現有的 API。因此，鼓勵企業探索在 GraphQL 對其最有意義的地方逐步採用 GraphQL —— 在他們發現它對應用程序性能和組織敏捷性具有最大的積極影響的地方。
via:https://opensource.com/article/19/6/why-use-graphql
作者：Zach Lendon選題：lujun9972譯者：wxy校對：wxy
本文由LCTT原創編譯，Linux中國榮譽推出
