翻譯：瘋狂的技術宅
自從 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 如何與型別一起工作，並建立我們的第一個查詢和修改。
所以請繼續關注並希望在下一個教程中見到你！