GraphQL 科普 前端向

簡介

GraphQL是基於「類型系統」來執行查詢的查詢語言。

Facebook 2012 年開始使用 GraphQL，15年開源。

graph定義了一套標準，用於描述服務端和客戶端的通訊。可使用任意語言來實現graph所描述的功能。就和ECMAScript標準之於JavaScript同樣。

樣例

前端傳入字段和結構。後臺按照前端的需求返回數據。

一個GraphQL請求由兩部分組成。 操做符 和 文檔。

操做符

GraphQL做爲先後臺交互的中間層，不能只有查詢功能，在REST中，有GET、POST、DELETE等類型的請求。

GraphQL則將先後臺通訊直接分爲兩大類 query和mutation。

query

顧名思義，query是默認的操做符，表明查詢，是不會給服務端帶來反作用的請求。沒有操做符的話會默認是query操做符，上面的動圖就是省略了query操做符。 完整的請求實際上是這樣的。

query {
    hero {
       name
    }
}

mutation

mutation表明一個動做，會給服務器帶來修改。好比增刪改。例如：

mutation addMessage($input: MessageType!) {
  addMessage(input: $input) {
    id
    text
  }
}

返回結果

{
    "addMessage": {
      "label": "測試的一個message",
      "id": "0RaqSeOL0"
    }
}

對($input: MessageType!) 可能會一頭霧水，這寫只是定義傳參的一些語法，過過文檔就能夠學會。

subscription

subscription， 訂閱操做符還未歸入標準，可是已經被實現應用了。訂閱操做符的功能是像服務端監聽一個操做。就像VUE裏面的watch同樣。只是咱們watch的是服務端。一旦服務端發生了咱們訂閱的改變，服務端就會主動把變化推送給咱們。本身的業務代碼裏面不再要維護什麼輪詢，定時器啦。

文檔

文檔部分：

{
  hero {
    name
    height
  }
}

文檔就是前端向後臺描述所需的字段。也是前端以爲最爽的地方，數據結構清晰明瞭。發送什麼樣的請求，拿到什麼樣的數據。

觀察文檔，文檔是由 類型 和 字段 構成的。GraphQL是強類型語言。若是使用過typescript就很好理解。

能夠認爲，咱們規定了一種對象，它們必定有定義的屬性。

hero就是一個類型。name 和 height就是字段。

特色

• 獲取多類資源，只用一個請求。
• 前端控制：是客戶端指定的查詢，端從被動爲主動，想要什麼拿什麼。
• 層次結構化： 操做粒度爲字段級別，可讀性好，查詢的結構和結果很是類似。
• 開發友好：得益於強類型，GraphQL能夠在編寫代碼時就檢查語句是否錯誤，也能智能提示類型下的字段。能夠自動生成文檔，提供豐富的體驗。
• 下降先後端溝通成本。

和REST對比

• 隨着系統發展，REST的接口持續平面增加，GraphQL 只需增長類型，更加利於維護。
• 若是是複雜的客戶端，一個頁面每每須要調用多個接口，GraphQL 只需調用一次便可，一次請求到全部數據。
• REST 所操做的資源相對是離散的（接口接口接口），GraphQL的數據更有總體性(由於是類型構成)。

社區框架

目前前端客戶端主要有Apollo和Relay，他們的做用就和axios同樣，方便咱們構造請求。由於業務中主要用到vue，有vue-apollo因此我選擇的是Apollo。

vue-apollo自帶了store層，方便進行數據緩存，vuex也能夠去掉了。

資料

我用vue-cli生成了一個簡單的增刪改查的項目。 能夠對照着文檔本身敲代碼。 GraphQL_demo

文章

• 阻礙你使用 GraphQL 的十個問題
• 30分鐘理解GraphQL核心概念
• RPC vs REST vs GraphQL

文檔

• graphql官方文檔
• vue-apollo文檔
• apollo文檔
• github的graph樣例接口（在線把玩）