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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在位于基礎設施層中的 GraphQL API 之外緩存整個響應。

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

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

將復雜度轉移到位于客戶端和服務器之間新的分層。

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

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

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

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

使用 apollo-cache-control-js 的緩存控制標識

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

目前為止，我們一直在談論單個客戶端和單個服務器之間的交互。我們的最后一個例子，一起來看看我們如何通過 GraphQL 來模塊化我們的架構。

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

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

這有一個例子：

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

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

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

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

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

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

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

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

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

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

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

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

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

終于寫完了……