1. GraphQL的興起

當(dāng)今構(gòu)建API的最佳方式是什么?你可能會(huì)想到REST，但是如果你打算投資構(gòu)建新的軟件，那么可能值得考慮一些不同的選項(xiàng)，并從中選擇最好的。GraphQL作為REST API架構(gòu)的替代方案脫穎而出，主要(但不只是)是因?yàn)樗ㄟ^(guò)設(shè)計(jì)提供了一個(gè)可發(fā)現(xiàn)的API。它還帶有自己的查詢語(yǔ)言和運(yùn)行時(shí)，用于通過(guò)稱為“解析器”的函數(shù)來(lái)執(zhí)行查詢。

GraphQL最初是Facebook在2012年開(kāi)發(fā)的，作為動(dòng)力不足的移動(dòng)設(shè)備更好的數(shù)據(jù)獲取解決方案，2015年開(kāi)源。2018年，它被轉(zhuǎn)移到Linux基金會(huì)的管理下，該基金會(huì)維護(hù)著其他重要的項(xiàng)目，如Node.js、Kubernetes，當(dāng)然還有Linux本身。

希望采用GraphQL的人普遍感到鼓舞。例如，從Stack Overflow Trends可以看出，近幾年來(lái)它的流行迅速上升。在PayPal、Netflix和Coursera等知名公司也有一些成功的案例，GraphQL在大型復(fù)雜架構(gòu)中構(gòu)建靈活、高性能的API方面發(fā)揮了重要作用。

然而，鑒于我們今天所處的動(dòng)態(tài)技術(shù)環(huán)境，你的懷疑是可以原諒的。GraphQL會(huì)成為另一種潮流嗎?如果它對(duì)這些公司有效，是否就一定對(duì)你有效?讓我們討論一下GraphQL的優(yōu)點(diǎn)和挑戰(zhàn)，以便你能夠做出明智的決定。

2. 使用GraphQL的理由

作為一種為靈活性而設(shè)計(jì)的API技術(shù)，GraphQL對(duì)于API的開(kāi)發(fā)者和消費(fèi)者以及其背后的組織來(lái)說(shuō)都是一個(gè)強(qiáng)有力的推動(dòng)者。在本節(jié)中，我們將探討GraphQL的一些關(guān)鍵領(lǐng)域。

(1) One Data Graph for All

對(duì)于擁有多個(gè)團(tuán)隊(duì)和系統(tǒng)，希望通過(guò)一個(gè)統(tǒng)一的API輕松獲得其數(shù)據(jù)的組織而言，GraphQL是一個(gè)絕佳的選擇。

無(wú)論你使用了多少數(shù)據(jù)庫(kù)、服務(wù)、遺留系統(tǒng)和第三方api, GraphQL都可以通過(guò)提供客戶機(jī)可以與之通信的單一端點(diǎn)來(lái)隱藏這種復(fù)雜性。GraphQL服務(wù)器負(fù)責(zé)從正確的位置獲取數(shù)據(jù)，并且客戶端永遠(yuǎn)不需要知道不同數(shù)據(jù)來(lái)自何處的詳細(xì)信息。因此，在為客戶和內(nèi)部用戶輕松提供數(shù)據(jù)時(shí)，GraphQL生態(tài)系統(tǒng)提供了最大的靈活性。

(2) 沒(méi)有過(guò)度獲取或不足獲取

對(duì)于GraphQL API客戶來(lái)說(shuō)，另一個(gè)巨大的好處是他們可以準(zhǔn)確地請(qǐng)求他們所需要的數(shù)據(jù)，甚至跨相關(guān)實(shí)體。這一點(diǎn)尤為重要，因?yàn)椴煌目蛻粲胁煌臄?shù)據(jù)需求，或者因?yàn)椴煌臉I(yè)務(wù)邏輯，或者因?yàn)樗麄冎皇浅尸F(xiàn)了不同的數(shù)據(jù)視圖(例如，Web與移動(dòng))，也可能有不同的硬件限制。

通過(guò)比較，從REST API有效地檢索重要數(shù)據(jù)要困難得多。從單個(gè)端點(diǎn)請(qǐng)求數(shù)據(jù)往往會(huì)返回比實(shí)際需要的更多的數(shù)據(jù)(超取)，而請(qǐng)求幾個(gè)相關(guān)實(shí)體的數(shù)據(jù)通常需要多次調(diào)用API(欠取)或?yàn)樘囟ǖ目蛻舳苏?qǐng)求提供專門的端點(diǎn)(重復(fù)勞動(dòng))。GraphQL通過(guò)準(zhǔn)確地提供每個(gè)客戶端請(qǐng)求的數(shù)據(jù)來(lái)解決此問(wèn)題，僅此而已。

(3) 更好的開(kāi)發(fā)人員體驗(yàn)

GraphQL生態(tài)系統(tǒng)附帶許多工具，使使用GraphQL變得輕而易舉。像GraphiQL和GraphQL Playground這樣的工具提供了豐富的體驗(yàn)，允許開(kāi)發(fā)人員以最小的努力檢查和嘗試API，這要?dú)w功于我們將在下一節(jié)中討論的自我文檔化特性。

另外，像GraphQL Code Generator這樣的代碼生成工具可以用來(lái)進(jìn)一步加快開(kāi)發(fā)速度，而其他工具和最佳實(shí)踐也可以用來(lái)解決具體問(wèn)題，包括：

客戶端緩存在幾個(gè)客戶端庫(kù)中是開(kāi)箱即用的。

基于游標(biāo)的分頁(yè)(Cursor-based pagination)提供了一種跨數(shù)據(jù)列表提供分頁(yè)的方法。

DataLoader通過(guò)批處理數(shù)據(jù)提取請(qǐng)求來(lái)提高性能，并且還提供了服務(wù)器端緩存的基本級(jí)別。

(4) 更高質(zhì)量的系統(tǒng)

GraphQL API是圍繞著類型系統(tǒng)構(gòu)建的，它列出了每個(gè)字段的名稱和類型，以及不同實(shí)體之間的關(guān)系。這種類型的系統(tǒng)或架構(gòu)用于驗(yàn)證客戶端發(fā)送的查詢。schema可以通過(guò)一個(gè)叫做自省(introspection)的功能進(jìn)行查詢，自省通常用于生成文檔和代碼，這些文檔和代碼將在客戶端集成API時(shí)使用。

因此，使用GraphQL時(shí)，只需花費(fèi)最少的精力即可獲得文檔齊全的API。這為第一次使用API的開(kāi)發(fā)者提供了極大的透明度，使開(kāi)發(fā)更加順利和高效。

(5) 為變化而建

REST APIs提供同一API的多個(gè)版本是很常見(jiàn)的，這樣就可以在不破壞現(xiàn)有功能的情況下進(jìn)行更改。GraphQL鼓勵(lì)使用另一種API修改方法：演進(jìn)。

當(dāng)需要進(jìn)行突破性的改變時(shí)(例如，當(dāng)重命名一個(gè)字段或改變它的類型時(shí))，你可以引入一個(gè)新的字段并廢棄舊的字段，可能在以后當(dāng)你確定它不再被使用時(shí)完全刪除它。這意味著你仍然可以改變你的API，同時(shí)保持向后的兼容性和單一的API。

3. 采用GraphQL之前的注意事項(xiàng)

GraphQL是構(gòu)建可擴(kuò)展和靈活的API的優(yōu)秀工具，但它不是萬(wàn)能的，當(dāng)然也不是每個(gè)人都適合。

(1) 學(xué)習(xí)曲線

REST是一種簡(jiǎn)單而熟悉的API構(gòu)建方法，而GraphQL則完全不同。開(kāi)發(fā)人員和基礎(chǔ)架構(gòu)工程師都需要學(xué)習(xí)如何有效地開(kāi)發(fā)和部署GraphQL API，這是一項(xiàng)需要適應(yīng)的任務(wù)。

因此，時(shí)間緊湊的團(tuán)隊(duì)可能更適合使用他們已經(jīng)熟悉的技術(shù)。

(2) 基礎(chǔ)架構(gòu)和工具

部署GraphQL，尤其是大規(guī)模部署，可能需要在基礎(chǔ)設(shè)施和工具上進(jìn)行大量投資。使用它并不能讓你省去部署虛擬機(jī)或容器、設(shè)置網(wǎng)絡(luò)基礎(chǔ)架構(gòu)，以及在大型環(huán)境中部署和維護(hù)GraphQL服務(wù)器軟件。

(3) 性能與安全性

你還必須格外小心，GraphQL提供的額外靈活性不會(huì)導(dǎo)致惡意或意外地降低或關(guān)閉你的系統(tǒng)的查詢。這可以通過(guò)限制或限制查詢復(fù)雜性和深度來(lái)解決。

最后，保護(hù)不應(yīng)該公開(kāi)的數(shù)據(jù)始終很重要。在其他網(wǎng)絡(luò)技術(shù)中流行的認(rèn)證和授權(quán)機(jī)制也可以使用GraphQL。此外，請(qǐng)注意內(nèi)省，因?yàn)槿绻麤](méi)有正確保護(hù)，它可能泄漏內(nèi)部類型。

總結(jié)

毫無(wú)疑問(wèn)，REST可以完成工作，但如果你正處于需要一種更好的方式來(lái)構(gòu)建API并為不同的客戶提供服務(wù)的階段，那么你可能應(yīng)該嘗試一下GraphQL。

GraphQL允許你構(gòu)建可進(jìn)化和可查詢的API，隱藏用于檢索各種數(shù)據(jù)的內(nèi)部系統(tǒng)的復(fù)雜性，并利用類型系統(tǒng)，從而實(shí)現(xiàn)自動(dòng)和最新的API文檔。這些功能以及它的工具和生態(tài)系統(tǒng)，使GraphQL成為API和客戶端開(kāi)發(fā)者的一個(gè)高效和有效的工具。

雖然GraphQL確實(shí)需要一些投資，但在有大量數(shù)據(jù)和服務(wù)的情況下，它的優(yōu)勢(shì)遠(yuǎn)遠(yuǎn)超過(guò)了現(xiàn)有的和未來(lái)的API客戶端的訪問(wèn)。