前端應該知道的GraphQL

lansheng228 發布于2019-08-22 16:45 / 2462人閱讀

摘要：什么是先貼官網英文中文。所有的操作必須指明到最底層的，并且返回值為標量，以確保響應結果的結構明白無誤。對于前端來說，在查詢的時候基本都要了解上面說的這幾個概念，具體應用可參見我的這篇文章如何利用開發個人博客。

本文主要結合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": "

本文主要結合...", }

又想記錄下文章的瀏覽量，日后成為大V，再展示出來 hhh~

{ "title": "前端應該知道的GraphQL", "updatedAt": "2018-04-22T03:46:34Z", "bodyHTML": "

本文主要結合...", "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": "本文主要結合...",
                "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的優勢想必大家都了解了，但為何這么好的技術并沒有得到廣泛的應用和推廣呢？

要在前端爽爽地使用 GraphQL，必須得在服務端搭建符合 GraphQL spec 的接口，基本上是整個改寫服務端暴露數據的方式。痛點是前端的，卻要后端來改造，誰會去做？

改成GraphQL對用戶體驗來說并沒有什么提升，而且對后端水平要求也高，改起來不簡單，需要花費大量的時間，老板不用付你工資的嗎？

GraphQL意味著一個中心化的API網關，中心化流量要求巨大的中心化集群，技術上運維上又是一個難題。

基于以上，GraphQL目前基本也就一些比較有技術追求和實力的創業公司和一線大廠在使用，希望Facebook能更進一步，給出一個基于云端的解決方案，解放前端。

歡迎討論，點個贊再走吧～

文章同步于以下社區，可以選一個關注我噢 ?????

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

云服務器 GPU云服務器你應該知道 GraphQL 你不知道的你不知道的javascript

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/94625.html

GraphQL 技術棧揭秘

摘要：關注業務，而不是技術將數據需求放在它們所屬的客戶端。技術棧中的每一部分都起著作用技術棧中所有部分之間的協作可以借助緩存來完成。現在，我們來看看另一個貫穿整個技術棧的功能的例子。你可以認為是首個內置細粒度查看的技術。本文整理自2017年 GraphQL 峰會上的演講，詳述緩存、追蹤、模式拼接和 GraphQL 未來發展等有關話題。 Facebook 開源 GraphQL 至今已兩年有余...

zzbo 2019-08-21 17:48 評論0 收藏0
GraphQL：一種更高效、強大和靈活的數據提供方式

摘要：我們知道是一種從服務器公開數據的流行方式。描述所有的可能類型系統基于類型和字段的方式進行組織，而非入口端點。因此，需要對后端進行調整，以滿足新的數據需求，這會降低生產力并顯著降低將用戶反饋集成到產品中的能力。 showImg(https://segmentfault.com/img/remote/1460000017875905?w=2234&h=974); 在前幾天的《StateOf...

waruqi 2019-07-01 11:12 評論0 收藏0
GraphQL：一種更高效、強大和靈活的數據提供方式

摘要：我們知道是一種從服務器公開數據的流行方式。描述所有的可能類型系統基于類型和字段的方式進行組織，而非入口端點。因此，需要對后端進行調整，以滿足新的數據需求，這會降低生產力并顯著降低將用戶反饋集成到產品中的能力。 showImg(https://segmentfault.com/img/remote/1460000017875905?w=2234&h=974); 在前幾天的《StateOf...

zzbo 2019-08-23 14:41 評論0 收藏0
GraphQL：一種更高效、強大和靈活的數據提供方式

摘要：我們知道是一種從服務器公開數據的流行方式。描述所有的可能類型系統基于類型和字段的方式進行組織，而非入口端點。因此，需要對后端進行調整，以滿足新的數據需求，這會降低生產力并顯著降低將用戶反饋集成到產品中的能力。 showImg(https://segmentfault.com/img/remote/1460000017875905?w=2234&h=974); 在前幾天的《StateOf...

eccozhou 2019-08-16 14:26 評論0 收藏0
GraphQL：一種更高效、強大和靈活的數據提供方式

摘要：我們知道是一種從服務器公開數據的流行方式。描述所有的可能類型系統基于類型和字段的方式進行組織，而非入口端點。因此，需要對后端進行調整，以滿足新的數據需求，這會降低生產力并顯著降低將用戶反饋集成到產品中的能力。 showImg(https://segmentfault.com/img/remote/1460000017875905?w=2234&h=974); 在前幾天的《StateOf...

DTeam 2019-07-30 18:46 評論0 收藏0