我列出了一些 GraphQL hidden rocks，當(dāng)您選擇構(gòu)建新 API 的方法時應(yīng)該牢記這些。

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

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

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

GraphQL 不會取代 REST 或 SOAP

這只是構(gòu)建 API 的另一種方式，但絕對不是“最好的方式，因為新的”。我什至?xí)f它更像是用于更具體業(yè)務(wù)案例的 SOAP。下面我將通過展示它們之間的相似之處來提供更多關(guān)于這一點的細(xì)節(jié)。

創(chuàng)建 GraphQL 是為了解決一些特定問題

它涵蓋了以下情況：

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

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

GraphQL 帶來了權(quán)衡

不過，它要求您做好一些準(zhǔn)備：

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

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

關(guān)于 GraphQL 模式拼接

為了解決耦合問題，有模式拼接的想法。簡而言之，您可以采用兩個或多個 GraphQL 模式，并將它們?nèi)亢喜⒃谝黄鹨怨┛蛻舳耸褂茫瑫r單獨生成它們。模式聯(lián)合是要走的路。

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

在我看來，這都是協(xié)議核心出現(xiàn)問題的跡象。它給軟件沙堡世界增加了不必要的認(rèn)知負(fù)擔(dān)和架構(gòu)復(fù)雜性，變得更加脆弱。

結(jié)束

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