什麼是GraphQL？

現實APP開發過程中，我們使用了大量的API，包括用於收集和存儲數據的API。我們將軟件構建為微服務，除非需要，否則我們不會直接公開每個服務。但是，由於API中需要獲取大量數據，需要能夠方便，安全地公開它。為了處理數據公開並使最終用戶保持簡單，我們使用GraphQL。

GraphQL是API的查詢語言。它最初由Facebook開發供內部使用，然後在2015年開源的！

隨著Facebook公開採購其GraphQL規範，它可以與大多數編程語言一起使用。GraphQL的主要客戶端包括Apollo客戶端和Relay。GraphQL服務器可用於多種語言，包括Haskell，JavaScript，Python，Ruby，Java，C＃，Scala，Go，Elixir，Erlang，PHP，R和Clojure。

您可能使用了具有無數終結點的API，沒有清楚地表明數據的實際外觀，並且文檔非常差。可悲的是，這可能是跨不同體系結構（REST，SOAP等）的常見問題。

GraphQL模式支持查詢，修改，訂閱。模式就像我們希望數據如何工作/看起來的藍圖。模式使您更容易理解可用的數據和格式。我們將創建一個基本模式進行查詢。

首先，讓我們定義查詢和架構。我們將創建一個名為“getRestaurants”的查詢，該查詢將調用類型“ Restaurant”。

我們已經創建了第一個查詢。我們定義一個名為“getRestaurants”的查詢，該查詢返回“ Restaurant”類型。當GraphQL執行此查詢時，它將查找相關的類型和解析器以驗證數據。

讓我們創建“餐廳”類型：

在此示例中，我們說明“餐館”類型具有以下條件：

名稱必須為字符串。

category必須是字符串。

location必須是字符串。

operationTimes必須是字符串數組。

minSpend必須是有符號的32位整數。

感嘆號表示該字段也是不可為空的，並且GraphQL服務承諾在查詢該字段時始終返回一個值。

我們需要創建的最後一件事是解析器。

我們在這裡所做的是返回一個對象，以針對架構進行驗證。

GraphQL是強類型的

查詢API時，您想確切地知道您將獲取哪些數據以及採用哪種格式。如果您要通過API獲取特定商品的價格，並且它返回一個字符串，那麼您可能會遇到問題…

制定嚴格的約束，清楚地描述可用數據的類型，對於確保您的應用程序按預期工作至關重要。GraphQL服務描述其類型，並根據該架構驗證查詢。

為什麼GraphQL有助於清潔API設計

假設我們有一個客戶希望加入送外賣服務。向用戶展示相關餐廳有幾個因素：

1. 它必須在用戶的特定半徑內，比如3公里。
2. 該餐廳必須當前開放並接受訂單要求。
3. 用戶可以搜索所需的食物類型。

讓我們開始為此構建一個基本的API。我們將通過查詢基本的RESTful和GraphQL API，來區分2種方式的不同。

我們假設API已經知道用戶的位置並且在交付範圍之內。而且我們只顯示2家餐廳。

RESTful API

接口：/ api /餐廳/漢堡

相應：

如果這是一個真實世界的API，那麼這個JSON響應可能會非常龐大，因為可能一個地方會有很多的漢堡店。

用戶請求獲取出售漢堡的餐館列表。在用戶請求的這個階段，用戶僅需要一份在其所在地區出售漢堡並可以送貨的餐館清單。`menu`數組將不被使用。使用RESTful接口，您將獲得所有這些數據，但是前端開發人員將不會使用它們。但是，它可能返回很多不會使用的數據（，這增加了等待時間，並增加了數據返回給用戶的等待時間，特別是當我們的網速不給力的時候，這種情況很折磨人。

GraphQL API

接口：/ graphql

查詢發送到GraphQL ：

響應：

用戶仍然請求獲取出售漢堡的餐館列表。當用戶處於瀏覽階段時，他們不在乎菜單上的內容。他們只想知道有哪些餐館，以便他們決定從哪裡用餐。此響應更加簡潔。

GraphQL將僅返回您的要求-僅此而已。這意味著我們可以通過查詢獲得更多相關信息，而不會浪費用戶的帶寬和時間！

現在，假設API不知道用戶的位置，但需要它來返回相關的餐廳。

RESTful API

接口：/ API /餐館/位置/漢堡/

現在，我們需要一個不同的接口來查找在指定範圍內出售漢堡的餐廳列表。我們可需要根據不同的情況，創建不同的接口列表，並且需要對保證API使用版本控制。 同時，他還會返回用戶可能不需要的大量數據。

GraphQL API

接口：/ graphql

查詢發送到GraphQL ：

我們的GraphQL解析器將查詢相關數據源並返回結果。可以看到，我們的接口沒有發生變化，這是修改了查詢邏輯，僅此而已，就是GraphQL的強大之處。

假設用戶現在已經選擇了一家餐館並選擇了幾款漢堡，並準備確認他們的訂單。這個時候，我們還需要顯示有關其訂單當前狀態的進度數據（是否接單，是否送達等）。

顯示其訂單的當前狀態需要幾個步驟：

• 當客戶點擊“跟蹤訂單”頁面時，我們需要獲取其訂單ID。
• 我們需要將該訂單ID發送到負責跟蹤訂單的服務。
• 然後，我們需要將狀態返回給用戶。

RESTful API

首先，我們需要發送請求以獲取該訂單的用戶訂單ID。

接口：/ api / orders / UID /

相應：

然後，我們需要獲取該orderNumber併發送一個請求以檢查訂單的狀態。

接口：/ api / orders / state / orderNumber/

相應：

GraphQL API

接口：/ graphql

查詢發送到GraphQL ：

我們的GraphQL查詢`order`將在後端調用其解析器，該解析器將獲取訂單號，然後向

接口 / api / orders / state / orderNumber發送請求。

響應：

GraphQL可以使前端從不必要的API調用和複雜性中抽象出來，使我們可以專注於其實際需要–簡潔的數據。

使用GraphQL，我們可以簡化客戶端與API交互的方式。想象一下，我們允許用戶從其智能手錶訂購顯示信息的空間更少，並且（可能）更大的延遲。返回的數據僅應是該特定用戶和客戶端所需的數據。

當然，如果需要進行兩次API調用才能返回數據，則GraphQL將無法神奇地僅發出一個請求。解析器仍將需要查詢單獨的數據源。但是，無論客戶端是什麼（手機，智能手錶，冰箱？），客戶端都將輕鬆得多。

RESTful服務流程示例

前端服務必須先查詢兩個單獨的API，然後才能將信息返回給用戶。如果用戶的連接速度很慢，這可能會很痛苦。此流還將返回在餐館上市階段將永遠不會使用的數據。

GraphQL服務流程示例

前端服務只需要查詢GraphQL服務。然後，GraphQL服務將具有解析器，以查詢兩個單獨的RESTful服務，並解析並返回前端請求的數據。

綜上所述，有了GraphQL，我們就可以像使用SQL語言查詢數據庫一樣，只需要列出我們需要查詢的數據就行了，其它的交給數據庫進行處理即可。