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

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

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

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

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

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

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

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

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

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

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

HTTP 緩存通常不支持 POST 請求或長緩存鍵

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

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

但是，GraphQL 也帶來了許多新的可能性：

訪問后端時，在模式和解析器旁聲明緩存控制信息的可能性

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

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

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

事實證明，就像在 REST 中一樣，在 API 層的兩端都進行緩存是有意義的：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這有一個例子：

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

在上面的截圖中，你可以看到對于一個拼接 API 的單個查詢是如何將提供不同服務(wù)的兩個獨立查詢合并在一起，這種方式對客戶端來說是完全不可見的。通過這種方式，你可以像使用樂高積木般合并多個 GraphQL 模式。

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

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

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

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

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

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

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

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

無論我們在哪里，有一點是明確的：GraphQL 已經(jīng)成千上萬的公司的變革技術(shù)，而這只是一個開始！ 我迫不及待地想知道在接下來的兩年，五年和十年中編寫應(yīng)用程序會是什么樣子，因為這將是不可思議的。

如果你像 Apollo 一樣對 GraphQL 的潛力感興趣，請考慮加入我們的社區(qū)。我們已經(jīng)組建了一個幫助頁面 來幫助你入門。

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

終于寫完了……