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

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

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

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

GraphQL 不會(huì)取代 REST 或 SOAP

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

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

它涵蓋了以下情況：

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

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

GraphQL 帶來了權(quán)衡

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

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

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

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

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

但問題是，即使是這個(gè)想法也遠(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ù)量，并不是靈丹妙藥。在您對(duì)它提供的好處感到驚訝之前，您必須評(píng)估視頻和上面列表中提到的權(quán)衡。