1. GraphQL的興起

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

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

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

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

2. 使用GraphQL的理由

作為一種為靈活性而設計的API技術，GraphQL對于API的開發者和消費者以及其背后的組織來說都是一個強有力的推動者。在本節中，我們將探討GraphQL的一些關鍵領域。

(1) One Data Graph for All

對于擁有多個團隊和系統，希望通過一個統一的API輕松獲得其數據的組織而言，GraphQL是一個絕佳的選擇。

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

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

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

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

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

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

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

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

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

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

(4) 更高質量的系統

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

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

(5) 為變化而建

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

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

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

GraphQL是構建可擴展和靈活的API的優秀工具，但它不是萬能的，當然也不是每個人都適合。

(1) 學習曲線

REST是一種簡單而熟悉的API構建方法，而GraphQL則完全不同。開發人員和基礎架構工程師都需要學習如何有效地開發和部署GraphQL API，這是一項需要適應的任務。

因此，時間緊湊的團隊可能更適合使用他們已經熟悉的技術。

(2) 基礎架構和工具

部署GraphQL，尤其是大規模部署，可能需要在基礎設施和工具上進行大量投資。使用它并不能讓你省去部署虛擬機或容器、設置網絡基礎架構，以及在大型環境中部署和維護GraphQL服務器軟件。

(3) 性能與安全性

你還必須格外小心，GraphQL提供的額外靈活性不會導致惡意或意外地降低或關閉你的系統的查詢。這可以通過限制或限制查詢復雜性和深度來解決。

最后，保護不應該公開的數據始終很重要。在其他網絡技術中流行的認證和授權機制也可以使用GraphQL。此外，請注意內省，因為如果沒有正確保護，它可能泄漏內部類型。

總結

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

GraphQL允許你構建可進化和可查詢的API，隱藏用于檢索各種數據的內部系統的復雜性，并利用類型系統，從而實現自動和最新的API文檔。這些功能以及它的工具和生態系統，使GraphQL成為API和客戶端開發者的一個高效和有效的工具。

雖然GraphQL確實需要一些投資，但在有大量數據和服務的情況下，它的優勢遠遠超過了現有的和未來的API客戶端的訪問。