爲何 GraphQL 是 API 的將來

翻譯：瘋狂的技術宅

medium.freecodecamp.org/why-graphql…

自從 Web 開始迅猛發展，對程序員來講開發 API 是一項很艱鉅的任務。咱們開發 API 的方式必須隨着時間的推移而發展，以便咱們始終能夠開發良好、直觀且設計良好的API。

在過去幾年中，GraphQL 在愈來愈受到開發者的歡迎。許多公司已經開始採用這種技術來構建他們的API。 GraphQL 是一種由 Facebook 在 2012 年開發並於 2015 年公開發布的查詢語言。它已經受到了普遍的關注，並被許多大公司採用，如 Spotify，Facebook，GitHub，NYTimes，Netflix，沃爾瑪等。

在本系列教程中，咱們將研究 GraphQL，瞭解它是什麼，並學習使這種查詢語言如此直觀和易用的緣由是什麼。

先讓咱們研究一下 REST 存在的問題，以及 GraphQL 如何解決它們。咱們還將瞭解那些大公司爲何用 GraphQL 去構建API，以及爲何它是 API 的將來。

REST

好久之前，當咱們把 API 的設計從 SOAP 轉向 REST 時，認爲此舉將會爲工做提供更多的靈活性。咱們不可否認 REST 的運做是良好的，在當時是一個很好的舉措。可是隨着應用和 Web 變得愈來愈複雜，API 也會隨着這些變化而發展。

不過 REST 也確實存在不少問題。讓咱們看看它們是什麼：

太多的端點

REST 中的每一個資源都由端點表示。所以，在實際的程序中，咱們最終會爲這些資源提供大量端點。若是要發出 GET 請求，則須要具備特定參數並特定於該請求的端點。若是要發出 POST 請求，則須要該請求的另外一個端點。

可是這有什麼問題呢？假設咱們正在開發一個像 Facebook 這樣的大型社交媒體應用，最終會獲得不少端點，這意味着開發和維護這些 API 將花費更多的時間和精力。

過分獲取和欠缺的信息

真正使人煩惱的問題是經過 REST API 會過分獲取和欠缺的信息。這是由於 REST API 會始終返回固定的結構。除非咱們再去建立一個特定的端點，不然沒法準確獲取所需的數據。

所以若是咱們只須要一小部分數據，就必須處理整個對象。例如，若是咱們只須要在 REST API 中獲取用戶的 firstName，lastName 和 age，就沒法在不獲取整個對象的狀況下獲得這些數據。

信息欠缺也存在問題。若是咱們想從兩個不一樣的資源獲取數據，就須要分別對兩個不一樣的端點進行調用。在一個巨大的程序中，擴展性會不好，由於在某些狀況下咱們只須要獲取特定的數據，而不是整個對象。假設咱們正在開發一個具備 100 個端點的程序。想象一下工做量和產生的代碼量。隨着時間的推移，開發會變得愈來愈困難，代碼也難以維護，程序員會感到迷茫。

版本控制

在我看來，REST 中的一個痛點就是版本控制。使用 REST API，一般會看到許多帶有 v1 或 v2 的 API。這些在 GraphQL 中並不須要，由於你能夠經過添加或刪除類型來改進 API。

在GraphQL中，你所須要作的就是寫新代碼。能夠編寫新類型、查詢和修改，而無需維護其餘版本的API。

所以你將看不到以下所示具備端點的 GraphQL API：

https://example.com/api/v1/users/12312
https://example.com/api/v2/users/12312
複製代碼

爲何 GraphQL 是將來

早在2012年，Facebook 在開發移動應用時面臨一個問題，這致使他們開發了 GraphQL。這些問題很是廣泛，特別是當咱們談論 RESTful API 設計時。如上所述，這些問題是：

• 表現不佳
• 端點過多
• 過分獲取或欠缺數據
• 每當咱們要增長或刪除某些內容時，須要開發另外一個版本
• API 難以理解

考慮到許多概念，Facebook 的開發人員開使用了一種更好的方法來設計 API，後來將其命名爲 GraphQL。基本上它是 REST 的替代品，作了不少改進。

使用 GraphQL，咱們能夠得到許多新功能，在構建 API 時爲你提供強大的功能。下面讓咱們一個一個地審視它們：

單端點

根本沒有必要構建不少端點！GraphQL 只須要一個端點，經過它咱們能夠在單個請求中得到儘量多的數據。基本上 GraphQL 會將你的全部查詢、修改和訂閱封裝在一個端點中，並供你調用。它改善了你的開發週期，由於你沒必要向兩個不一樣的資源發出請求來獲取數據。此外，當咱們開發一個大型的應用時，沒必要再像 REST 同樣得到大量端點和代碼。咱們只須要得到一個端點，並根據須要開發儘量多的請求便可。

正如我上面所說，「單端點」方法使你的 API 可以自我描述，你再也不須要再去構建文檔，由於你的程序員已經知道應該如何使用。他們只需查看代碼便可瞭解API。咱們稍後會詳細瞭解它（本系列的下一篇教程）。看起來很神奇，但這就是 GraphQL！

使用 GraphQL，你只能獲取所需的數據

沒有過分獲取或未被充分利用的信息，你只獲取本身需的數據。還記得咱們最初討論的性能問題嗎？不會再像那樣了，由於 GraphQL 提升了 API 的性能，特別是在網絡鏈接速度較慢的狀況下。

GraphQL 使得開發 API 變得容易並保持一致

不少人認爲 GraphQL 很是複雜，由於它涉及模式和單個端點。可是你一旦開始用它開發 API，會發現它比你想象的要容易得多。當你開發網站或應用時，「單端點」 API 會給你很大幫助。它使你的 API 更加可以自我描述，而且無需爲它編寫大量的文檔。

若是你並非把 JavaScript 做爲主要語言，那也不是問題。 GraphQL 是一種查詢語言，這意味着你可使用任何本身熟悉的語言。在編寫本教程時，GraphQL 支持的語言已經超過了 12 種。

GraphQL 是將來

GraphQL 是一種開源查詢語言，這意味着社區能夠爲其作出貢獻並對加以改進。當 Facebook 將其發佈到社區時，獲得了大量的認同。如今隨着愈來愈多的程序員用它構建 API，GraphQL 一直在快速增加。可是也有些人一直在問它是否真的要取代 REST，或者成爲構建 API 的新方法。

起初，我認爲 GraphQL 是一個炒做，僅僅是建立 API 的另外一種方式。可是當我開始研究它時，發現 GraphQL 具備爲現代應用程序建立 API 所需的基本功能，由於它很是適合現今的技術棧。

因此若是我要對你說些什麼，我會說：是的，GraphQL的確是API的將來。這就是大公司在它身上押注的緣由。

在2018年11月，GraphQL 與 Linux Foundation 合做建立了一個 GraphQL Foundation。這種查詢語言鼓勵其開發人員建立更多的文檔、工具和語言支持。這將確保 GraphQL 的穩定、中立和可持續發展的將來。所以這也是將 GraphQL 視爲 API 的將來的另外一個緣由。

固然 GraphQL 不會當即取代 REST，由於許多應用仍然在使用它，也不可能在一晚上之間重寫它們。隨着愈來愈多的公司採用 GraphQL，UX 和 DX 都將獲得改進。

結論

GraphQL 的確是API的將來，咱們須要瞭解更多信息。這就是我決定撰寫這一系列教程的緣由，這些教程將爲咱們展現如何用好 GraphQL，先從查詢和修改開始，而後是訂閱和身份驗證。

在本系列的下一篇教程中，我將深刻研究 GraphQL，展現 GraphQL 如何與類型一塊兒工做，並建立咱們的第一個查詢和修改。

因此請繼續關注並但願在下一個教程中見到你！

歡迎關注公衆號：前端先鋒，獲取更多前端乾貨。