前端應當曉得的GraphQL

2024年1月31日 132次阅读 来源: simbawu

本文重要連繫GitHub GraphQL API，從前端運用者的角度來談GraphQL，沒有GraphQL項目的同硯可以拿GitHub GraphQL API練手，詳細代碼可拜見我的GitHub Blog，迎接star、fork。

為什麼須要GraphQL？

以我的博客為例，如今列表頁，每篇文章須要的數據構造以下：

{
    "title": "前端應當曉得的GraphQL",
    "updatedAt": "2018-04-22T03:46:34Z",
    "bodyText": "本文重要連繫...",
}

而文章概況頁的數據構造為：

{
    "title": "前端應當曉得的GraphQL",
    "updatedAt": "2018-04-22T03:46:34Z",
    "bodyHTML": "<p>本文重要連繫...",
}

又想紀錄下文章的瀏覽量，往後成為大V，再展現出來 hhh~

{
    "title": "前端應當曉得的GraphQL",
    "updatedAt": "2018-04-22T03:46:34Z",
    "bodyHTML": "<p>本文重要連繫...",
    "view": "29898",
}

那末題目來了：兩個頁面的數據構造title和updateAt的數據是反覆的，而body是差別的，而且另有一個願望如今就設計好今後須要的時刻再用到的view字段。假如為了輕易，只寫一個接口，同時返回bodyText和bodyHTML，那總有數據是過剩的，如許也不合理。但假如分兩個接口，又顯的有點貧苦和糟蹋。

這還只是一個簡樸的例子，日常平凡開闢過程當中，需求變化迥殊頻仍，碰到的題目也會更龐雜，如今主流的RESTful API所暴露出來的題目也愈來愈顯著。

假如能從泉源動身，接口返回的數據不是由臨盆方（後端），而是由運用方（前端）來決議，就可以到達所見即所得的效果，這時刻GraphQL也就應運而生了。

什麼是GraphQL？

先貼官網：英文 | 中文 。

GraphQL 既是一種用於 API 的查詢言語，也是一個滿足你數據查詢的運行時。 GraphQL 對你的 API 中的數據供應了一套易於邃曉的完全形貌，使得客戶端可以正確地取得它須要的數據，而且沒有任何冗餘，也讓 API 更容易地跟着時候推移而演進，還能用於構建壯大的開闢者東西。

也就是說，GraphQL可以在你挪用api的時刻來決議api返回的數據構造，以此到達精準、沒有冗餘的拿到所須要的數據。GraphQL這麼兇猛，是怎樣做到的呢？我們先從我的博客文章概況頁接口入手來展現GraphQL的廬山真面目：

let data = {
  query: `query {
      repository(owner:"simbawus", name: "blog") {
        issue(number: ${articleId}) {
          title
          updatedAt
          bodyHTML
        }
      }
    }`
};

Actions.getIssues(data).then((res) => {
  let issue = res.data.data.repository.issue;

  this.setState({
      title: issue.title,
      updatedAt: new Date(issue.updatedAt).format('yyyy-MM-dd'),
      bodyHTML: issue.bodyHTML
  })
})

這就是一個基於GitHub GraphQL API的請求，跟一般請求唯一的區分就在請求參數data，並非 JSON 對象，而是一個字符串，這個字符串形貌了客戶端願望服務端返回數據的詳細構造，以下JSON：

{
    "data": {
        "repository": {
            "issue": {
                "bodyHTML": "<p>本文重要連繫...",
                "title": "前端應當曉得的GraphQL",
                "updatedAt": "2018-04-22T03:46:34Z",
            }
        }
    }
}

連繫這個例子，我來引見GraphQL的幾个中間觀點：

query & mutation

query的中文意義是查詢，也就對應RESTful規範中的get，而mutation的意義是變動，對應post、delete、patch和put。

connection

connection讓你能在同一個請求中查詢關聯的對象。經由過程connection，你只須要一個GraphQL請求就可以完成RESTful API中多個請求才做的事。

比方，GitHub GraphQL API文檔中，我們在查詢issue對象的同時，還可以查labels對象。

let data = {
  query: `query {
      repository(owner:"simbawus", name: "blog") {
        issue(number: ${articleId}) {
          title
          updatedAt
          bodyHTML
        }
        labels(first: 100){
          nodes{
            name
          }
        }
      }
    }`
};

field

field是你可以從對象中獵取的數據單位。正如GraphQL官方文檔所說：“GraphQL查詢言語本質上就是從對象中挑選field”。一切的GraphQL操縱必需指明到最底層的field，而且返回值為標量，以確保相應效果的構造邃曉無誤。

argument

argument跟RESTful API規範中一致，示意我們在請求該接口是傳的參數，比方上面issue的number 參數，示意請求的第${articleId}個issue。

關於前端來講，在查詢GraphQL API的時刻基礎都要相識上面說的這幾個觀點，詳細運用可拜見我的這篇文章怎樣應用GitHub GraphQL API開闢個人博客？。概況代碼可查看我的github：simbawus/blog，迎接star、fork。

GraphQL的將來

GraphQL的上風想必人人都相識了，但為什麼這麼好的手藝並沒有獲得普遍的運用和推行呢？

  1. 要在前端爽爽地運用 GraphQL，必需得在服務端搭建相符 GraphQL spec 的接口，基礎上是全部改寫服務端暴露數據的體式格局。痛點是前端的，卻要後端來革新，誰會去做？
  2. 改成GraphQL對用戶體驗來講並沒有什麼提拔，而且對後端程度請求也高，改起來不簡樸，須要消費大批的時候，老闆不必付你工資的嗎？
  3. GraphQL意味着一个中間化的API網關，中間化流量請求龐大的中間化集群，手藝上運維上又是一個困難。

基於以上，GraphQL如今基礎也就一些比較有手藝追乞降氣力的創業公司和一線大廠在運用，願望Facebook能更進一步，給出一個基於雲端的解決方案，解放前端。

迎接議論，點個贊再走吧～

文章同步於以下社區，可以選一個關注我噢 ｡◕‿◕｡

simbawu | github | segmentfault | 知乎 | 簡書 | 掘金

    原文作者：simbawu
    原文地址: https://segmentfault.com/a/1190000014613288
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞