摘要：什么是先貼官網(wǎng)英文中文。所有的操作必須指明到最底層的，并且返回值為標(biāo)量，以確保響應(yīng)結(jié)果的結(jié)構(gòu)明白無(wú)誤。對(duì)于前端來(lái)說(shuō)，在查詢的時(shí)候基本都要了解上面說(shuō)的這幾個(gè)概念，具體應(yīng)用可參見(jiàn)我的這篇文章如何利用開發(fā)個(gè)人博客。

本文主要結(jié)合GitHub GraphQL API，從前端使用者的角度來(lái)談GraphQL，沒(méi)有GraphQL項(xiàng)目的同學(xué)可以拿GitHub GraphQL API練手，具體代碼可參見(jiàn)我的GitHub Blog，歡迎star、fork。

以我的博客為例，目前列表頁(yè)，每篇文章需要的數(shù)據(jù)結(jié)構(gòu)如下：

{
    "title": "前端應(yīng)該知道的GraphQL",
    "updatedAt": "2018-04-22T03:46:34Z",
    "bodyText": "本文主要結(jié)合...",
}

而文章詳情頁(yè)的數(shù)據(jù)結(jié)構(gòu)為：

{
    "title": "前端應(yīng)該知道的GraphQL",
    "updatedAt": "2018-04-22T03:46:34Z",
    "bodyHTML": "
本文主要結(jié)合...",
}

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

{
    "title": "前端應(yīng)該知道的GraphQL",
    "updatedAt": "2018-04-22T03:46:34Z",
    "bodyHTML": "
本文主要結(jié)合...",
    "view": "29898",
}

那么問(wèn)題來(lái)了：兩個(gè)頁(yè)面的數(shù)據(jù)結(jié)構(gòu)title和updateAt的數(shù)據(jù)是重復(fù)的，而body是不同的，并且還有一個(gè)希望現(xiàn)在就設(shè)計(jì)好以后需要的時(shí)候再用到的view字段。如果為了方便，只寫一個(gè)接口，同時(shí)返回bodyText和bodyHTML，那總有數(shù)據(jù)是多余的，這樣也不合理。但如果分兩個(gè)接口，又顯的有點(diǎn)麻煩和浪費(fèi)。

這還只是一個(gè)簡(jiǎn)單的例子，平時(shí)開發(fā)過(guò)程中，需求變化特別頻繁，遇到的問(wèn)題也會(huì)更復(fù)雜，目前主流的RESTful API所暴露出來(lái)的問(wèn)題也越來(lái)越明顯。

如果能從源頭出發(fā)，接口返回的數(shù)據(jù)不是由生產(chǎn)方（后端），而是由使用方（前端）來(lái)決定，就可以達(dá)到所見(jiàn)即所得的效果，這時(shí)候GraphQL也就應(yīng)運(yùn)而生了。

先貼官網(wǎng)：英文 | 中文 。

GraphQL 既是一種用于 API 的查詢語(yǔ)言，也是一個(gè)滿足你數(shù)據(jù)查詢的運(yùn)行時(shí)。 GraphQL 對(duì)你的 API 中的數(shù)據(jù)提供了一套易于理解的完整描述，使得客戶端能夠準(zhǔn)確地獲得它需要的數(shù)據(jù)，而且沒(méi)有任何冗余，也讓 API 更容易地隨著時(shí)間推移而演進(jìn)，還能用于構(gòu)建強(qiáng)大的開發(fā)者工具。

也就是說(shuō)，GraphQL能夠在你調(diào)用api的時(shí)候來(lái)決定api返回的數(shù)據(jù)結(jié)構(gòu)，以此達(dá)到精準(zhǔn)、沒(méi)有冗余的拿到所需要的數(shù)據(jù)。GraphQL這么厲害，是如何做到的呢？我們先從我的博客文章詳情頁(yè)接口入手來(lái)揭示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
  })
})

這就是一個(gè)基于GitHub GraphQL API的請(qǐng)求，跟普通請(qǐng)求唯一的區(qū)別就在請(qǐng)求參數(shù)data，并不是 JSON 對(duì)象，而是一個(gè)字符串，這個(gè)字符串描述了客戶端希望服務(wù)端返回?cái)?shù)據(jù)的具體結(jié)構(gòu)，如下JSON：

{
    "data": {
        "repository": {
            "issue": {
                "bodyHTML": "
本文主要結(jié)合...",
                "title": "前端應(yīng)該知道的GraphQL",
                "updatedAt": "2018-04-22T03:46:34Z",
            }
        }
    }
}

結(jié)合這個(gè)例子，我來(lái)介紹GraphQL的幾個(gè)核心概念：

query的中文意思是查詢，也就對(duì)應(yīng)RESTful標(biāo)準(zhǔn)中的get，而mutation的意思是變更，對(duì)應(yīng)post、delete、patch和put。

connection讓你能在同一個(gè)請(qǐng)求中查詢關(guān)聯(lián)的對(duì)象。通過(guò)connection，你只需要一個(gè)GraphQL請(qǐng)求就可以完成RESTful API中多個(gè)請(qǐng)求才能做的事。

比如，GitHub GraphQL API文檔中，我們?cè)诓樵僫ssue對(duì)象的同時(shí)，還可以查labels對(duì)象。

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

field是你可以從對(duì)象中獲取的數(shù)據(jù)單元。正如GraphQL官方文檔所說(shuō)：“GraphQL查詢語(yǔ)言本質(zhì)上就是從對(duì)象中選擇field”。所有的GraphQL操作必須指明到最底層的field，并且返回值為標(biāo)量，以確保響應(yīng)結(jié)果的結(jié)構(gòu)明白無(wú)誤。

argument跟RESTful API標(biāo)準(zhǔn)中一致，表示我們?cè)谡?qǐng)求該接口是傳的參數(shù)，比如上面issue的number 參數(shù)，表示請(qǐng)求的第${articleId}個(gè)issue。

對(duì)于前端來(lái)說(shuō)，在查詢GraphQL API的時(shí)候基本都要了解上面說(shuō)的這幾個(gè)概念，具體應(yīng)用可參見(jiàn)我的這篇文章如何利用GitHub GraphQL API開發(fā)個(gè)人博客？。詳情代碼可查看我的github：simbawus/blog，歡迎star、fork。

GraphQL的優(yōu)勢(shì)想必大家都了解了，但為何這么好的技術(shù)并沒(méi)有得到廣泛的應(yīng)用和推廣呢？

要在前端爽爽地使用 GraphQL，必須得在服務(wù)端搭建符合 GraphQL spec 的接口，基本上是整個(gè)改寫服務(wù)端暴露數(shù)據(jù)的方式。痛點(diǎn)是前端的，卻要后端來(lái)改造，誰(shuí)會(huì)去做？

改成GraphQL對(duì)用戶體驗(yàn)來(lái)說(shuō)并沒(méi)有什么提升，而且對(duì)后端水平要求也高，改起來(lái)不簡(jiǎn)單，需要花費(fèi)大量的時(shí)間，老板不用付你工資的嗎？

GraphQL意味著一個(gè)中心化的API網(wǎng)關(guān)，中心化流量要求巨大的中心化集群，技術(shù)上運(yùn)維上又是一個(gè)難題。

基于以上，GraphQL目前基本也就一些比較有技術(shù)追求和實(shí)力的創(chuàng)業(yè)公司和一線大廠在使用，希望Facebook能更進(jìn)一步，給出一個(gè)基于云端的解決方案，解放前端。

文章同步于以下社區(qū)，可以選一個(gè)關(guān)注我噢 ?????

simbawu | github | segmentfault | 知乎 | 簡(jiǎn)書 | 掘金