本文簡單的介紹了 GraphQL，希望能夠幫助大家對這個方便的查詢語言有一個簡單的認識
GraphQL 是什麼
GraphQL 是一種 API 查詢語言，是一個對自定義類型系統執行查詢的服務端運行環境。它相當於客戶端和伺服器之間的中介，將客戶端發來的所需數據的請求處理之後在一次請求之中就能獲得符合客戶端需求的響應數據。它還有個好處就是它是一種當作一種組織，管理數據的能力來使用，而不綁定在什麼資料庫上面，數據存在於哪裡與它無關。
對比 Rest API
Rest API 是和 GraphQL 同類的用於查詢的語言。Rest 把每個資源都用一個 URL 表示，訪問這個 URL 就能夠得到一份 JSON 格式的數據響應，但是這有一個缺點，你可能會得到與需求不相關的數據。而 GraphQL 則不會，發送過去的請求中指定了需要哪個資源，舉個簡單的例子，你需要這本書的作者的姓資源，那麼 Rest API 會把把作者的名字也發給你，因為你是通過訪問作者的信息的 URL 來獲得姓的，而 GraphQL 則會只把需要的信息發過來，換句話說，需要什麼資源是用戶來決定的。
RPC vs REST vs GraphQL（參考資料點擊這裡）
在合適的時候選擇合適的工具是重要的，下面則列舉了在一些場景下最好使用什麼工具來作為參考
1、如果是 Management API，這類 API 的特點如下：
- 關注於對象與資源
- 會有多種不同的客戶端
- 需要良好的可發現性和文檔
這種情景使用 REST + JSON API 可能會更好。
2、如果是 Command or Action API，這類 API 的特點如下：
- 面向動作或者指令
- 僅需要簡單的交互
這種情況使用 RPC 就足夠了。
3、如果是 Internal Micro Services API，這類 API 的特點如下：
- 消息密集型
- 對系統性能有較高要求
這種情景仍然建議使用 RPC。
4、如果是 Micro Services API，這類 API 的特點如下：
- 消息密集型
- 期望系統開銷較低
這種情景使用 RPC 或者 REST 均可。
5、如果是 Data or Mobile API，這類 API 的特點是：
- 數據類型是具有圖狀的特點
- 希望對於高延遲場景可以有更好的優化
這種場景無疑 GraphQL 是最好的選擇。
GraphQL 的查詢與變更——如何查詢 GraphQL 伺服器
以一個查詢結果為例：
{
hero {
name
}
}
該查詢將會獲得一個與其結構幾乎一樣的結果：
{
"data": {
"hero": {
"name": "R2-D2"
}
}
}
這是 GraphQL 最重要的特性，因為這樣一來，你就總是能得到你想要的數據，而伺服器也準確地知道客戶端請求的欄位。並且在GraphQL中查詢是可交互的，你可以按你喜歡來改變查詢，然後看看新的結果。
在查詢時可以添加上參數，結果也會顯得更有趣。參數可以是多種不同的類型。GraphQL 自帶一套默認類型，但是 GraphQL 伺服器可以聲明一套自己的定製類型，只要能序列化成你的傳輸格式即可。
例如，有如下查詢：
{
human(id: "1000") {
name
height
}
}
其結果為：
{
"data": {
"human": {
"name": "Luke Skywalker",
"height": 1.72
}
}
}
在類似 REST 的系統中，你只能傳遞一組簡單參數 —— 請求中的 query 參數和 URL 段。但是在 GraphQL 中，每一個欄位和嵌套對象都能有自己的一組參數，從而使得 GraphQL 可以完美替代多次 API 獲取請求。甚至你也可以給 標量（scalar）欄位傳遞參數，用於實現服務端的一次轉換，而不用每個客戶端分別轉換。
