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

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

GraphQL 幾年來(lái)一直是人們關(guān)注的焦點(diǎn)。在您將這個(gè)好看的縮寫(xiě)添加到您的簡(jiǎn)歷之前，我想分享一下根據(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(shuō)它更像是用于更具體業(yè)務(wù)案例的 SOAP。下面我將通過(guò)展示它們之間的相似之處來(lái)提供更多關(guān)于這一點(diǎn)的細(xì)節(jié)。

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

它涵蓋了以下情況：

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

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

GraphQL 帶來(lái)了權(quán)衡

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

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

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

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

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

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

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

結(jié)束

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