我列出了一些 GraphQL hidden rocks，當您選擇構建新 API 的方法時應該牢記這些。

很容易愛上專業營銷人員銷售的技術。然而，軟件工程很難，因為沒有一種解決方案可以適用于所有情況。

GraphQL 幾年來一直是人們關注的焦點。在您將這個好看的縮寫添加到您的簡歷之前，我想分享一下根據生產經驗總結的觀點和想法。有大名鼎鼎的Alex Xu的新鮮好料，大家先看看，這里不贅述，不贅述。

雖然我完全支持視頻中提到的擔憂，但我想補充幾點：

GraphQL 不會取代 REST 或 SOAP

這只是構建 API 的另一種方式，但絕對不是“最好的方式，因為新的”。我什至會說它更像是用于更具體業務案例的 SOAP。下面我將通過展示它們之間的相似之處來提供更多關于這一點的細節。

創建 GraphQL 是為了解決一些特定問題

它涵蓋了以下情況：

1. 您正在開展業務，其中大多數用戶都是通過“智能手機”運行的。此類用戶經常在移動時切換網絡/ISP，并且可能使用不可靠或不良的連接。基本上，GraphQL 允許您執行較少數量的從移動應用程序到 API 的請求。然而，細節決定成敗。
2. 您可以輕松地將所有數據(您需要在客戶端/UI 上使用的數據)放入單個數據模型(或數據圖)中。這可能是因為您從事大數據工作，或者有統一的方式來表示來自各種來源的信息。

GraphQL 允許您優化開發團隊的吞吐量，方法是讓您的前端團隊考慮他們想從 API 中獲得什么，而不是您的后端團隊提出他們的數據模型或猜測什么是最佳 API 和數據模型。每次需要更改 UI 端時都等待 API 更改(后端工程師)，效率不是很高。因此，UI 開發人員很高興，因為他們可以使用數據并找到各種使用或顯示數據的方法。但是，他們的知識是否足以安全地執行此操作?這種好處是有代價的。

GraphQL 帶來了權衡

不過，它要求您做好一些準備：

您必須生成 API 的架構，就像在 SOAP 的情況下一樣。這并不是什么新鮮事，當您獨自負責后端和前端(構建“Hello，World!”)時，這可能看起來很正常。當您的團隊可以擠在一個房間(或共享 2 個比薩餅)并且可以非常快速地輕松地互相交談時，這沒關系。但是，如果您的團隊很大和/或頻繁更新 API 對象，您很快就會厭倦這個過程。每次后端工程師更新 API 并重新生成架構時，他們都必須與一些需要獲取更新的對等方建立連接。他們必須花費更多精力來構建和維護額外的 CI 自動化步驟，以及使用聊天、信使等更好、更頻繁地進行交流。顯然，. 它無法像 REST 那樣在實驗中提供如此大的靈活性。

它將API 性能的控制權從后端開發團隊手中轉移到客戶(UI/客戶端開發團隊)手中。使用其強類型 GraphQL 可以實現所謂的客戶端指定查詢。在更壞的情況下，它會導致N+1 問題。GraphQL 為客戶團隊提供的靈活性伴隨著進行不可預測的緩慢數據庫查詢的可能性。當然，這可以通過手動或自動測試來緩解，但值得牢記。當然，在某些情況下這可能是不可接受的。

關于 GraphQL 模式拼接

為了解決耦合問題，有模式拼接的想法。簡而言之，您可以采用兩個或多個 GraphQL 模式，并將它們全部合并在一起以供客戶端使用，同時單獨生成它們。模式聯合是要走的路。

但問題是，即使是這個想法也遠非完美的解決方案。這就是為什么公司圍繞 GraphQL 構建復雜工具的原因，特別是 Apollo 最近(截至 2022 年夏季)引入了Federation v2.0 和 supergraph 的想法。

在我看來，這都是協議核心出現問題的跡象。它給軟件沙堡世界增加了不必要的認知負擔和架構復雜性，變得更加脆弱。

結束

顯然，GraphQL 縮小了它解決的用例數量，并不是靈丹妙藥。在您對它提供的好處感到驚訝之前，您必須評估視頻和上面列表中提到的權衡。