[[321285]]

以下是 GraphQL 在標準 REST API 技術(shù)上獲得發(fā)展的原因。

正如我以前所寫，GraphQL 是一種下一代 API 技術(shù)，它正在改變客戶端應用程序與后端系統(tǒng)的通信方式以及后端系統(tǒng)的設(shè)計方式。

由于一開始就從創(chuàng)建它的組織 Facebook 獲得了支持，并得到了其他技術(shù)巨頭（如 Github、Twitter 和 AirBnB）的支持，因此 GraphQL 作為應用程序系統(tǒng)的關(guān)鍵技術(shù)的地位似乎是穩(wěn)固的 —— 無論現(xiàn)在還是將來。

GraphQL 的崛起

移動應用程序性能和組織敏捷性重要性的提高為 GraphQL 登上現(xiàn)代企業(yè)體系結(jié)構(gòu)的頂端提供了助推器。

鑒于 REST 是一種非常流行的體系結(jié)構(gòu)風格，早已提供了數(shù)據(jù)交互機制，與 REST 相比，GraphQL 這項新技術(shù)具有哪些優(yōu)勢呢？GraphQL 中的 “QL” 代表著查詢語言，而這是一個很好的起點。

借助 GraphQL，組織內(nèi)的不同客戶端應用程序可以輕松地僅查詢所需數(shù)據(jù)，這一點超越了其它 REST 方法，并帶來了實際應用程序性能的提高。使用傳統(tǒng)的 REST API 端點，客戶端應用程序?qū)⒃斣兎掌髻Y源，并接受包含了與請求匹配的所有數(shù)據(jù)的響應。如果來自 REST API 端點的成功響應返回 35 個字段，那么客戶端應用程序就會收到 35 個字段。

獲取的問題

傳統(tǒng)上，REST API 沒有為客戶端應用程序提供簡便的方法來僅檢索或只更新它們關(guān)心的數(shù)據(jù)。這通常被描述為“過度獲取over-fetching”的問題。隨著移動應用程序在人們的日常生活中的普遍使用，過度獲取問題會給現(xiàn)實世界帶來不良后果。移動應用程序發(fā)出的每個請求、每一個字節(jié)的接受和發(fā)送，對終端用戶的性能影響越來越大。數(shù)據(jù)連接速度較慢的用戶尤其會受到不太好的 API 設(shè)計方案的影響。使用移動應用程序而性能體驗不佳的客戶更有可能不購買產(chǎn)品或不使用服務。低效的 API 設(shè)計只會浪費企業(yè)的錢。

并非只有“過度獲取”是問題，“欠缺獲取”同樣也是問題。默認情況下，端點只返回客戶端實際需要的部分數(shù)據(jù)，這需要客戶端進行額外的調(diào)用以滿足其數(shù)據(jù)需求，這就產(chǎn)生了額外的 HTTP 請求。由于過度和欠缺的獲取問題及其對客戶端應用程序性能的影響，促進有效獲取的 API 技術(shù)才有機會在市場上引起轟動 —— GraphQL 大膽地介入并填補了這一空白。

REST 的應對

REST API 設(shè)計師不甘心不戰(zhàn)而退，他們試圖通過以下幾種方式來應對移動應用程序性能問題：

• “包含”和“排除”查詢參數(shù)，允許客戶端應用程序通過可能較長的查詢格式來指定所需的字段。

• “復合”服務，將多個端點組合在一起，以使客戶端應用程序在其發(fā)出的請求數(shù)量和接收到的數(shù)據(jù)方面更高效。    盡管這些模式是 REST API 社區(qū)為解決移動客戶端所面臨的挑戰(zhàn)而做出的英勇嘗試，但它們在以下幾個關(guān)鍵方面仍存在不足：

• 包含和排除查詢鍵/值對很快就會變得混亂，特別是對于需要用嵌套“點表示法”語法（或類似方法）以對目標數(shù)據(jù)進行包含和排除的深層對象圖而言，更是如此。此外，在此模型中調(diào)試查詢字符串的問題通常需要手動分解 URL。

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

• 復合服務的興起形成了更加緊密耦合的后端和前端系統(tǒng)，這就需要加強協(xié)調(diào)以交付項目，并且將曾經(jīng)的敏捷項目轉(zhuǎn)回瀑布式開發(fā)。這種協(xié)調(diào)和耦合還有一個痛苦的副作用，那就是減宦了組織的敏捷性。此外，顧名思義，組合服務不是 RESTful。   

  GraphQL 的起源

對于 Facebook 來說，從其 2011-2012 年基于 HTML5 版本的旗艦移動應用程序中感受到的痛點和體驗，才造就了 GraphQL。Facebook 工程師意識到提高性能至關(guān)重要，因此意識到他們需要一種新的 API 設(shè)計來確保最佳性能?？赡芸紤]到上述 REST 的局限性，并且需要支持許多 API 客戶端的不同需求，因此人們可以理解是什么導致其共同創(chuàng)建者 Lee Byron 和 Dan Schaeffer（那時尚是 Facebook 員工）創(chuàng)建了后來被稱之為 GraphQL 的技術(shù)的早期種子。

通過 GraphQL 查詢語言，客戶端（通常是單個 GraphQL 端點）應用程序通常可以顯著減少所需的網(wǎng)絡(luò)調(diào)用數(shù)量，并確保僅檢索所需的數(shù)據(jù)。在許多方面，這可以追溯到早期的 Web 編程模型，在該模型中，客戶端應用程序代碼會直接查詢后端系統(tǒng) —— 比如說，有些人可能還記得 10 到 15 年前在 JSP 上用 JSTL 編寫 SQL 查詢的情形吧！

現(xiàn)在最大的區(qū)別是使用 GraphQL，我們有了一個跨多種客戶端和服務器語言和庫實現(xiàn)的規(guī)范。借助 GraphQL 這樣一種 API 技術(shù)，我們通過引入 GraphQL 應用程序中間層來解耦后端和前端應用程序系統(tǒng)，該層提供了一種機制，以與組織的業(yè)務領(lǐng)域相一致的方式來訪問組織數(shù)據(jù)。

除了解決軟件工程團隊遇到的技術(shù)挑戰(zhàn)之外，GraphQL 還促進了組織敏捷性的提高，特別是在企業(yè)中。啟用 GraphQL 的組織敏捷性通常歸因于以下因素：

• GraphQL API 設(shè)計人員和開發(fā)人員無需在客戶端需要一個或多個新字段時創(chuàng)建新的端點，而是能夠?qū)⑦@些字段包含在現(xiàn)有的圖實現(xiàn)中，從而以較少的開發(fā)工作量和跨應用程序系統(tǒng)的較少更改的方式展示出新功能。
• 通過鼓勵 API 設(shè)計團隊將更多的精力放在定義對象圖上，而不是在專注于客戶端應用程序交付上，前端和后端軟件團隊為客戶交付解決方案的速度日益解耦。    ### 采納之前的注意事項

盡管 GraphQL 具有引人注目的優(yōu)勢，但 GraphQL 并非沒有實施挑戰(zhàn)。一些例子包括：

• 為 REST API 建立的緩存機制更加成熟。
• 使用 REST 來構(gòu)建 API 的模式更加完善。
• 盡管工程師可能更喜歡 GraphQL 等新技術(shù)，但與 GraphQL 相比，市場上的人才庫更多是從事于構(gòu)建基于 REST 的解決方案。

結(jié)論

通過同時提高性能和組織敏捷性，GraphQL 在過去幾年中被企業(yè)采納的數(shù)量激增。但是，與 API 設(shè)計的 RESTful 生態(tài)系統(tǒng)相比，它確實還需要更成熟一些。

GraphQL 的一大優(yōu)點是，它并不是作為替代 API 解決方案的批發(fā)替代品而設(shè)計的。相反，GraphQL 可以用來補充或增強現(xiàn)有的 API。因此，鼓勵企業(yè)探索在 GraphQL 對其最有意義的地方逐步采用 GraphQL —— 在他們發(fā)現(xiàn)它對應用程序性能和組織敏捷性具有最大的積極影響的地方。