1. GraphQL的興起

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

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

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

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

2. 使用GraphQL的理由

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

(1) One Data Graph for All

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

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

(2) 沒有過度獲取或不足獲取

對于GraphQL API客戶來說，另一個巨大的好處是他們可以準(zhǔn)確地請求他們所需要的數(shù)據(jù)，甚至跨相關(guān)實體。這一點尤為重要，因為不同的客戶有不同的數(shù)據(jù)需求，或者因為不同的業(yè)務(wù)邏輯，或者因為他們只是呈現(xiàn)了不同的數(shù)據(jù)視圖(例如，Web與移動)，也可能有不同的硬件限制。

通過比較，從REST API有效地檢索重要數(shù)據(jù)要困難得多。從單個端點請求數(shù)據(jù)往往會返回比實際需要的更多的數(shù)據(jù)(超取)，而請求幾個相關(guān)實體的數(shù)據(jù)通常需要多次調(diào)用API(欠取)或為特定的客戶端請求提供專門的端點(重復(fù)勞動)。GraphQL通過準(zhǔn)確地提供每個客戶端請求的數(shù)據(jù)來解決此問題，僅此而已。

(3) 更好的開發(fā)人員體驗

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

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

客戶端緩存在幾個客戶端庫中是開箱即用的。

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

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

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

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

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

(5) 為變化而建

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

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

3. 采用GraphQL之前的注意事項

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

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

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

因此，時間緊湊的團(tuán)隊可能更適合使用他們已經(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提供的額外靈活性不會導(dǎo)致惡意或意外地降低或關(guān)閉你的系統(tǒng)的查詢。這可以通過限制或限制查詢復(fù)雜性和深度來解決。

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

總結(jié)

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

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

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