摘要：關(guān)注業(yè)務(wù)，而不是技術(shù)將數(shù)據(jù)需求放在它們所屬的客戶(hù)端。技術(shù)棧中的每一部分都起著作用技術(shù)棧中所有部分之間的協(xié)作可以借助緩存來(lái)完成。現(xiàn)在，我們來(lái)看看另一個(gè)貫穿整個(gè)技術(shù)棧的功能的例子。你可以認(rèn)為是首個(gè)內(nèi)置細(xì)粒度查看的技術(shù)。

Facebook 開(kāi)源 GraphQL 至今已兩年有余。兩年來(lái)，社區(qū)成倍增長(zhǎng)，成千上萬(wàn)的公司在產(chǎn)品中使用 GraphQL。在今年10月份舉辦的 GraphQL 峰會(huì)上，我有幸在第二天發(fā)表開(kāi)幕主題演講。讀者可以在 YouTube 上觀看完整的演講，或閱讀本文瀏覽概要。

首先，我將介紹一下 GraphQL 的現(xiàn)狀，然后討論在不久的將來(lái)如何發(fā)揚(yáng)它的主要優(yōu)勢(shì)。具體來(lái)說(shuō)，我們將介紹三個(gè)完整的 GraphQL 集成示例：緩存，性能追蹤和模式拼接。讓我們開(kāi)始吧！

有三個(gè)主要因素使得 GraphQL 從其他 API 技術(shù)中脫穎而出：

GraphQL 擁有明確的查詢(xún)語(yǔ)言，這是描述數(shù)據(jù)需求的好方法，還有定義良好的模式，能夠暴露 API 能力。它是唯一能夠指定方程兩側(cè)（譯者注：視圖和模型）的主流技術(shù)，它的所有優(yōu)勢(shì)都源于這兩個(gè)概念的相互作用。

GraphQL 能夠幫你將 API 提供者與消費(fèi)者解耦。在像 REST 這樣基于端點(diǎn)的 API 中，返回?cái)?shù)據(jù)的結(jié)構(gòu)由服務(wù)器決定。在 GraphQL 中，響應(yīng)的結(jié)構(gòu)與使用它的 UI 代碼保持關(guān)聯(lián)，這樣會(huì)更加自然，使得你可以專(zhuān)注于關(guān)注業(yè)務(wù)而不是技術(shù)。

由于 GraphQL 查詢(xún)會(huì)被附加到使用它的代碼上，因此可以將該查詢(xún)視為數(shù)據(jù)獲取單元。GraphQL 能夠預(yù)先知道 UI 組件的所有數(shù)據(jù)需求，從而啟用新的服務(wù)器功能。例如，在單個(gè)查詢(xún)中對(duì)底層 API 調(diào)用進(jìn)行批處理和緩存，代表了 UI 中某一部分所需的數(shù)據(jù)，使用 GraphQL 將會(huì)令其非常簡(jiǎn)單。

關(guān)注業(yè)務(wù)，而不是技術(shù)：GraphQL 將數(shù)據(jù)需求放在它們所屬的客戶(hù)端。

現(xiàn)在，我們來(lái)看看人們對(duì)于數(shù)據(jù)請(qǐng)求經(jīng)常關(guān)注的三個(gè)方面，以及 GraphQL 如何利用上面提到的屬性進(jìn)行全方位改進(jìn)。

請(qǐng)注意，雖然下面討論的許多功能是你現(xiàn)在就能夠使用的，但其中一部分仍屬于未來(lái)的愿景。如果你和我一樣對(duì)這件事感到興奮，那么請(qǐng)滾動(dòng)到底部參與其中。

人們經(jīng)常問(wèn)的第一件事情就是——我怎么用我的 GraphQL API 做交叉請(qǐng)求緩存？將常規(guī) HTTP 緩存應(yīng)用于 GraphQL 時(shí)會(huì)出現(xiàn)這樣一些問(wèn)題：

HTTP 緩存通常不支持 POST 請(qǐng)求或長(zhǎng)緩存鍵

越復(fù)雜的請(qǐng)求可能意味著更少的緩存命中

GraphQL 的傳輸是獨(dú)立的，因此 HTTP 緩存并不總是可行

但是，GraphQL 也帶來(lái)了許多新的可能性：

訪問(wèn)后端時(shí)，在模式和解析器旁聲明緩存控制信息的可能性

基于模式的自動(dòng)化細(xì)粒度緩存控制，而不必多帶帶考慮每個(gè)請(qǐng)求

我們應(yīng)該如何使用 GraphQL 來(lái)生效緩存，以及如何利用好這些新的可能性呢？

首先，我們得確定緩存功能應(yīng)該設(shè)計(jì)在哪。一開(kāi)始的直覺(jué)可能是緩存邏輯應(yīng)該放在 GraphQL 服務(wù)器本身內(nèi)。然而，像 DataLoader 這樣簡(jiǎn)單的工具在同時(shí)執(zhí)行多個(gè) GraphQL 請(qǐng)求時(shí)并不能很好地工作，而將緩存功能放在我們的服務(wù)器代碼中會(huì)使實(shí)現(xiàn)變得非常復(fù)雜。因此我們應(yīng)該把它放在別的地方。

事實(shí)證明，就像在 REST 中一樣，在 API 層的兩端都進(jìn)行緩存是有意義的：

在位于基礎(chǔ)設(shè)施層中的 GraphQL API 之外緩存整個(gè)響應(yīng)。

緩存 GraphQL 服務(wù)器底層對(duì)數(shù)據(jù)庫(kù)和微服務(wù)的請(qǐng)求。

對(duì)于第二點(diǎn)，需要你現(xiàn)有的緩存基礎(chǔ)設(shè)施工作良好。對(duì)于第一點(diǎn)，我們需要一個(gè)位于 API 之外的層，并且能夠以 GraphQL 的方式執(zhí)行緩存等操作。本質(zhì)上講，這種架構(gòu)能夠?qū)?fù)雜度從 GraphQL 服務(wù)器中分離出來(lái)：

將復(fù)雜度轉(zhuǎn)移到位于客戶(hù)端和服務(wù)器之間新的分層。

我將這個(gè)組件稱(chēng)之為 GraphQL 網(wǎng)關(guān)。在 Apollo 團(tuán)隊(duì)內(nèi)部，我們認(rèn)為這個(gè)新的網(wǎng)關(guān)層非常重要，每個(gè)人都需要將其作為 GraphQL 基礎(chǔ)架構(gòu)的一部分。

這就是為什么在今年的 GraphQL 峰會(huì)期間，我們推出了首個(gè) GraphQL 網(wǎng)關(guān) Apollo Engine。

正如我在開(kāi)始時(shí)提到的那樣，GraphQL 的一大優(yōu)點(diǎn)是其擁有巨大的工具生態(tài)系統(tǒng)，所有工具都圍繞著 GraphQL 的查詢(xún)和模式來(lái)工作。我認(rèn)為像緩存這樣的功能也應(yīng)該以同樣的方式工作。這就是為什么我們要介紹 Apollo 緩存控制，它使用了 GraphQL 規(guī)范中內(nèi)置的一個(gè)名為 擴(kuò)展 的特性，將緩存控制信息包含在響應(yīng)中。

使用我們的 JavaScript 參考實(shí)現(xiàn)，可以很容易在你的 schema 中添加緩存控制標(biāo)識(shí)：

使用 apollo-cache-control-js 的緩存控制標(biāo)識(shí)

這個(gè)新的緩存控制規(guī)范建立在 GraphQL 的主要優(yōu)勢(shì)上，我對(duì)此感到非常興奮。它使你能夠細(xì)粒度地指定相關(guān)數(shù)據(jù)的信息，并利用 GraphQL 執(zhí)行將相關(guān)的緩存控制標(biāo)識(shí)發(fā)回給調(diào)用者，而且這與語(yǔ)言和傳輸方式無(wú)關(guān)。

自從我在 GraphQL Summit 上發(fā)表這個(gè)演講后，Oleg Ilyenko 已經(jīng)發(fā)布了 Sangria 的緩存控制工作版本，由他維護(hù)的 Scala GraphQL 實(shí)現(xiàn)。

現(xiàn)在我們可以在 GraphQL 服務(wù)器中返回緩存控制標(biāo)識(shí)，所以我們有一個(gè)明確的方法來(lái)在網(wǎng)關(guān)中進(jìn)行緩存。技術(shù)棧中的每一部分都起著作用：

技術(shù)棧中所有部分之間的協(xié)作可以借助緩存來(lái)完成。

需要注意的一件很酷的事情是，大多數(shù)人已經(jīng)在他們的 GraphQL 棧中擁有了一個(gè)緩存：比如 Apollo Client 和 Relay 這樣的庫(kù)在前端緩存你的數(shù)據(jù)。在 Apollo 客戶(hù)端的未來(lái)版本中，來(lái)自響應(yīng)的緩存控制信息將被用于自動(dòng)在前端過(guò)期舊數(shù)據(jù)。所以，就像 GraphQL 的其他部分一樣，服務(wù)器描述它的功能，客戶(hù)端指定它的數(shù)據(jù)需求，然后一切工作配合正常。

現(xiàn)在，我們來(lái)看看另一個(gè)貫穿整個(gè)技術(shù)棧的 GraphQL 功能的例子。

借助 GraphQL，前端開(kāi)發(fā)人員能夠以相較基于端點(diǎn)的系統(tǒng)更精細(xì)的方式處理數(shù)據(jù)。他們可以確切地請(qǐng)求他們需要的數(shù)據(jù)，并跳過(guò)他們不打算使用的字段。受益于此，我們可以展示詳細(xì)的性能信息，并以前所未有的方式使其具有可操作性。

不要滿(mǎn)足于不透明的總查詢(xún)時(shí)間—— GraphQL 使你能夠獲曉字段級(jí)別的詳細(xì)耗時(shí)。

你可以認(rèn)為 GraphQL 是首個(gè)內(nèi)置細(xì)粒度查看的 API 技術(shù)。這不是借助某個(gè)特定的工具—— GraphQL 第一次合理地讓前端開(kāi)發(fā)人員能夠獲得逐個(gè)字段的執(zhí)行時(shí)間，然后調(diào)整他們的查詢(xún)來(lái)解決問(wèn)題。

事實(shí)證明，追蹤跟緩存一樣，對(duì)于整個(gè)棧的協(xié)作大有裨益。

每一部分在提供追蹤數(shù)據(jù)和使其具有可操作性方面發(fā)揮著作用。

服務(wù)器能夠提供相關(guān)信息作為響應(yīng)結(jié)果的一部分，就像提供緩存標(biāo)識(shí)一樣，網(wǎng)關(guān)可以提取和聚合這些信息。重申，使用網(wǎng)關(guān)組件來(lái)處理復(fù)雜的功能，而不是在服務(wù)器進(jìn)程中處理。

在這種情況下，客戶(hù)端的主要功能是將查詢(xún)與 UI 組件連接起來(lái)。這非常關(guān)鍵，因此你可以將 API 層的性能與其對(duì)前端的影響聯(lián)系起來(lái)。這將是首次，你可以直接將后端請(qǐng)求的性能與其在頁(yè)面上受影響的 UI 組件關(guān)聯(lián)起來(lái)。

就像緩存一樣，通過(guò)利用 GraphQL 的響應(yīng)擴(kuò)展功能，能夠以服務(wù)器無(wú)關(guān)的方式實(shí)現(xiàn)上述功能。Apollo Tracing 規(guī)范已經(jīng)在 Node，Ruby， Scala，Java 和 Elixir 上實(shí)現(xiàn)了，其定義了一種 GraphQL 服務(wù)器以標(biāo)準(zhǔn)方式為解析器返回耗時(shí)數(shù)據(jù)的方式，能夠被任何工具所使用。

想象一下，你所有的 GraphQL 工具都可以訪問(wèn)性能數(shù)據(jù)：

共享抽象允許工具使用諸如追蹤數(shù)據(jù)等信息。

借助 Apollo Tracing，你可以在 GraphiQL，編輯器或其他任何地方獲取性能數(shù)據(jù)。

目前為止，我們一直在談?wù)搯蝹€(gè)客戶(hù)端和單個(gè)服務(wù)器之間的交互。我們的最后一個(gè)例子，一起來(lái)看看我們?nèi)绾瓮ㄟ^(guò) GraphQL 來(lái)模塊化我們的架構(gòu)。

GraphQL 最好的地方就是可以在一個(gè)地方訪問(wèn)所有的數(shù)據(jù)。但是，這樣做的代價(jià)是：你需要將整個(gè) GraphQL 模式作為單個(gè)代碼庫(kù)來(lái)實(shí)現(xiàn)，以便能夠在一個(gè)請(qǐng)求中查詢(xún)它。 如果你擁有一個(gè)模塊化的架構(gòu)，而該架構(gòu)同時(shí)具有單個(gè)統(tǒng)一 GraphQL API 的好處呢？

模式拼接的概念很簡(jiǎn)單：GraphQL 可以很容易地將多個(gè) API 合并為一個(gè)，因此你可以將模式的不同部分實(shí)現(xiàn)為獨(dú)立的服務(wù)。這些服務(wù)可以分開(kāi)部署，用不同的語(yǔ)言編寫(xiě)，甚至可以由不同的組織維護(hù)。

這有一個(gè)例子：

在單個(gè)查詢(xún)中結(jié)合來(lái)自 GraphQL 峰會(huì)的票務(wù)系統(tǒng)和天氣 API 的數(shù)據(jù)：
https://launchpad.graphql.com/130rr3r49

在上面的截圖中，你可以看到對(duì)于一個(gè)拼接 API 的單個(gè)查詢(xún)是如何將提供不同服務(wù)的兩個(gè)獨(dú)立查詢(xún)合并在一起，這種方式對(duì)客戶(hù)端來(lái)說(shuō)是完全不可見(jiàn)的。通過(guò)這種方式，你可以像使用樂(lè)高積木般合并多個(gè) GraphQL 模式。

我們實(shí)現(xiàn)了一個(gè)能用的版本，放到了 Apollo graphql-tools 庫(kù)里，你可以現(xiàn)在去試用。具體查看文檔。

模式拼接的概念在整個(gè)棧中也可以很好地工作。我們認(rèn)為新的網(wǎng)關(guān)層長(zhǎng)期來(lái)看會(huì)是一個(gè)執(zhí)行拼接操作的好地方，你可以使用任何你想要的技術(shù)構(gòu)建你的模式，如 Node.js，Graphcool 或 Neo4j。

事實(shí)證明，模式拼接與 GraphQL 棧的每一部分都息息相關(guān)。

客戶(hù)端也可以加入進(jìn)來(lái)！就像你使用一個(gè)查詢(xún)從多個(gè)后端加載數(shù)據(jù)一樣，你也可以在客戶(hù)端上組合數(shù)據(jù)源。最近發(fā)布的 Apollo Client 2.0 中的新客戶(hù)端狀態(tài)管理功能使你可以在單個(gè)查詢(xún)中獲取來(lái)自于客戶(hù)端狀態(tài)和任意數(shù)量后端的數(shù)據(jù)。

希望你通過(guò)閱讀這篇文章或者看完演講后能知道一件事情，那就是盡管現(xiàn)今的 GraphQL 工具已經(jīng)很棒了，未來(lái)還有更多的潛力。我們只是抓住了 GraphQL 提供的抽象和功能的表面。

我想以上述提到的概念的待辦事項(xiàng)清單來(lái)結(jié)束本篇文章：

整合這些新功能還有很多工作要做，特別是在開(kāi)發(fā)者工具和編輯器方面。

要發(fā)掘 GraphQL 的全部潛力，還有很多事情要做。在 Apollo 團(tuán)隊(duì)，我們正在盡我們所能來(lái)做這件事情，但多帶帶的一個(gè)人，團(tuán)隊(duì)或組織不可能獨(dú)自完成這個(gè)目標(biāo)。為了實(shí)現(xiàn)未來(lái)的愿景，我們需要共同合作，共同構(gòu)建出所有這些解決方案。

無(wú)論我們?cè)谀睦铮幸稽c(diǎn)是明確的：GraphQL 已經(jīng)成千上萬(wàn)的公司的變革技術(shù)，而這只是一個(gè)開(kāi)始！ 我迫不及待地想知道在接下來(lái)的兩年，五年和十年中編寫(xiě)應(yīng)用程序會(huì)是什么樣子，因?yàn)檫@將是不可思議的。

如果你像 Apollo 一樣對(duì) GraphQL 的潛力感興趣，請(qǐng)考慮加入我們的社區(qū)。我們已經(jīng)組建了一個(gè)幫助頁(yè)面 來(lái)幫助你入門(mén)。

GraphQL 峰會(huì)上的其他會(huì)議即將發(fā)布！在Twitter上關(guān)注 @graphqlsummit 或訂閱 Apollo 的 Youtube 頻道 以獲取最新內(nèi)容。

終于寫(xiě)完了……