一塊兒走進GraphQL

本文原創：yinyue

什麼是GraphQL？

GraphQL 是一種面向數據的 API 查詢語言（規範），是一種協議而非存儲。GraphQL對你的API中的數據提供了一套易於理解的完整描述，使得客戶端可以準確地得到它須要的數據，並且沒有任何冗餘。

GraphQL由Facebook發起，其手機客戶端自2012年起，就全面採用了GraphQL查詢語言， 2015年， Facebook全面開源了第一份GraphQL規範。到目前爲止，在Twitter，Github，Pinterest，Shopify等大型網站也獲得了普遍的實踐。語言也從最初的js，擴展到java ，python，Go。

強類型語言

其實GraphQL所須要學習的語法不多，大部分語法與咱們平時的語法一致，能夠經過官網詳細瞭解 graphql.cn。 能夠本身實現增刪改查等操做。 須要特別注意的是，GraphQL是一門強類型語言，咱們須要定義每個屬性的類型。以下圖所示：

下面是一個簡單的類型定義，先是定義了一個枚舉，而後咱們定義了一個類型，類型中有四個屬性：id、 name、 friends、 appearsIn,其中id和name是標量類型，而friends是一個Person類型。

enum Episode {
  NEWHOPE
  EMPIRE
  JEDI
}
type Person{
     id: ID! 
     name: String!
     friends: [Person]
     appearsIn: [Episode]! 
} 複製代碼

核心概念

Schema能夠說是GraphQL最具核心的部分，其描述了整個接口向外暴露的形式。

像Restful API，咱們會定義一個查詢全部人的接口url定義爲： /api/v1/user/getUsers

查詢人具體信息的接口url爲： /api/v1/user/getUserById

新增一我的員的接口url定義爲： /api/v1/user/createUser

這樣前端人員調用起來會很直觀。

可是graphql是徹底不同的使用方式，其向前端暴露的url就一個像/api/graphql之類的，那這麼多接口怎麼區分呢？ 咱們來看看：

奧妙就是上面這張圖，一個graphql接口都有一個Schema定義。

其定義三種操做方式：query（查詢）,mutation（變動）和subscription（監聽）。

再往下延伸，一個查詢中包含多個field，也就是多種不一樣的查詢，好比query user查詢人，query message查詢消息，query weather查詢天氣。

經過這些就實現了Restful API使用多個url來達到不一樣操做的效果。

GraphQL和傳統REST相比有什麼不一樣？

相同點：

• 二者都有資源的概念，並能夠爲這些資源指定ID。
• 二者均可以經過HTTP GET請求獲取URL。
• 二者均可以在請求中返回JSON數據。

不一樣點：

• 在REST中，您調用的端點是該對象的標識。 在GraphQL中，標識與獲取它的方式是分開的。
• 在REST中，資源的類型和大小由服務器決定。 在GraphQL中，服務器聲明哪些資源可用，客戶端詢問它須要什麼

GraphQL的優勢和缺點

優勢：

• 能夠經過請求控制返回的數據。
• 減小網絡請求次數。能夠經過一個資源入口訪問到關聯的其餘資源，只要事先在schema中定義好資源之間的關係便可，傳輸不同的數據，而REST則提供多個URL端點來獲取相關的資源。
• 參數類型強檢驗。REST方案自己沒有對參數的類型作規定，每每都須要自行實現參數的校驗機制，以確保安全。但GraphQL提供了強類型的schema機制，從而確保了參數類型的合法性。
• 文檔清晰。GraphQL會把schema定義和相關的註釋生成可視化的文檔，從而使代碼的變動，直接反映到最新的文檔上，避免像REST中手工維護可能會形成代碼、文檔不一致的問題。
• 擴展性好。

缺點：

• GraphQL查詢的複雜性。
• 查詢頻率限制。
• GraphQL緩存。由於REST強制使用具備緩存機制的HTTP協議，你能夠經過它避免獲取多餘資源。GraphQL沒有緩存機制,它把緩存的重任交給了用戶。