摘要：開發者體驗可以幫助團隊更快地實現功能上線，因為它對開發者的體驗非常好。可以顯示每個的埋點指標，可以幫忙你定位錯誤，可以分析中請求的每個字段的分布頻率。產品案例雖然規范是由在年公布的，但是自年以來，就是移動應用開發的重要組成部分。

在大前端應用的開發過程中，如何管理好數據是一件很有挑戰的事情。后端工程師需要聚合來自多個數據源的數據，再分發到大前端的各個端中，而大前端工程師需要在實現用戶體驗好的視圖 (optimistic UI¹) 的基礎上，需要考慮如何管理端上的狀態。

在團隊中使用 GraphQL 能夠很好的解決數據管理的痛點。本文接下來會介紹 GraphQL 聲明式(declarative)獲取數據的方法，這將簡化數據管理的難度，并且提升網絡性能。還會介紹 Apollo² 如何通過一系列對開發者體驗好的工具，提高工程師的開發效率。

譯注1：optimistic UI 是一種 UI 設計模式。例如，你在微信上發送消息會直接顯示，而不用等到消息的網絡請求成功或失敗后再顯示。optimistic UI 的數據管理很復雜，需要先顯示模擬數據，再等待網絡請求成功或失敗后，再顯示真正的數據。通過 Apollo 可以輕易地實現 optimistic UI。
譯注2：Apollo 是實現，GraphQL 是標準，和 JS/ECMA 的關系一樣。

Apollo 可以幫助團隊更快地實現功能上線，因為它對開發者的體驗非常好。Apollo 目標是"讓各端的數據管理變得簡單"(simplify data management across the stack)。通過 Apollo Client、Apollo Server 和 Apollo Engine，以前需要花上一些功夫實現的功能，比如全棧緩存、數據規范化、optimistic UI，現在變得很簡單。

GraphQL 強類型查詢語言的特性，使得開發者可以利用牛逼的工具來請求 GraphQL 接口。借助 GraphQL 內省系統(introspection system)，開發者可以查詢 GraphQL schema ³信息，包括字段和類型。內省系統擁有一些非常炫酷的功能，比如自動生成的文檔、代碼自動補全等等。

譯注3：schema 用于描述你所要數據的結構和字段，如：

 {
   dogs {
     id
     breed
     image {
       url
     }
     activities {
       name
     }
   }
 }

GraphQL Playground
Prisma 團隊開發的 GraphQL Playground 工具是一款非常優秀的 IDE，它可以把自定義的 schema 和查詢歷史自動地生成文檔。只要看一下，你就知道 GraphQL API 中有哪些能獲取到的數據，而不用研究后端代碼或了解數據來源。

Apollo Server 2.0 內置了 GraphQL Playground，更方便你瀏覽 schema 和執行查詢命令。

Apollo DevTools
Apollo DevTools 是 Chrome 的擴展程序，可以查詢 Apollo 的前端緩存(Cache)，記錄查詢(Queries)和變更(Mutations)。你還可以使用 Apollo DevTools 中的 GraphiQL 來方便地測試前端查詢。

如果你使用過 REST 和狀態管理庫，如 Redux，為了發一個網絡請求，你需要寫 action creators、reducers、mapStateToProps 并集成中間件。使用 Apollo Client，你再也不用關系這些東西。Apollo Client 解決了一切，你只需要專注于查詢，而不需要寫一堆狀態管理的代碼。

import ApolloClient from "apollo-boost";

const client = new ApolloClient({
  uri: "https://dog-graphql-api.glitch.me/graphql"
});

有團隊聲稱他們切換成 Apollo Client 后，刪除了上千行狀態管理代碼和一堆復雜邏輯。這得益于 Apollo Client 不僅支持遠程數據管理，還支持本地數據管理， Apollo 緩存就是當前應用全局狀態的單一事實來源。

Apollo platform⁴ 可以讓團隊使用現代化的工具，幫忙他們快速發現錯誤、查看 API、開發具有挑戰的緩存功能。

譯注4：Apollo platform 是云平臺。Apollo 在本文中有兩層含義，首先 Apollo 是 GraphQL 的一個開源實現，其次 Apollo 是開發 Apollo platform 、Apollo Client 、Apollo Server 等產品的公司。

Apollo Engine 是 GraphQL 生態系統中唯一可以為你的 API 提供監控和分析的工具。Engine 可以顯示每個 resolver⁵ 的埋點指標，可以幫忙你定位錯誤， 可以分析 schema 中請求的每個字段的分布頻率。 你還可以將這些數據傳輸到你正在用的其他分析平臺，如 DataDog，并在某些數據超過報警闕值設置時進行報警。

譯注5：resolver 處理返回字段的函數

使用 GraphQL 的一個主要優點是它有聲明式數據獲取的能力，不需要前端請求多個接口，不需要手動的聚合數據，只需要你精確地描述你所要的數據，然后 GraphQL 就會將你要的數據返回給你。而使用 REST ，你需要調用每一個接口，并過濾出你要的數據，然后將過濾后的數據構造成組件所需要的結構。

GET /api/dogs/breeds
GET /api/dogs/images
GET /api/dogs/activities

REST 的方法不僅不好使，而且容易出錯，難以跨平臺重用邏輯。對比一下 GraphQL 聲明式的方式：

const GET_DOGS = gql`
  query {
    dogs {
      id
      breed
      image {
        url
      }
      activities {
        name
      }
    }
  }
`;

在上面，我們定義了我們想要從服務端獲取的對象的結構。GraphQL 負責組合和過濾數據，同時返回我們想要的數據字段和結構。

如何使用 GraphQL 查詢？Apollo Client 構建了 GraphQL 聲明式請求數據的方法。在 React 應用中，獲取數據、跟蹤加載和錯誤狀態以及更新 UI 的所有邏輯，都封裝在一個 Query 組件中。這種封裝方式使數據獲取組件和展示組件很容易的組合在一起。讓我們看看，如何在 React 應用中使用 Apollo Client 獲取 GraphQL 數據：

const Feed = () => (
  {/* 數據獲取組件 Query*/} 
  
    {/* 展示組件：由 Error、Fetching、DogList 等組成的函數組件 */}
    {({ loading, error, data }) => {
      if (error) return 
      if (loading || !data) return ;
    
      return 
    }}
  
);

Apollo Client 管理整個請求的周期，從請求開始到請求結束，包括為你跟蹤加載和錯誤狀態。這里不用設置中間件，不用寫模板代碼，不用重構的數據結構，不用關心請求緩存。你所需要做的就是描述你組件要的數據，然后讓 Apoolo Client 去完成那些繁重的工作。

當你使用 Apollo Client 時，你會發現你能刪除很多不需要的數據管理方面的代碼。具體能夠刪除多少行代碼，要根據你項目的情況來判斷，但有些團隊聲稱他們刪除了數千行代碼。要了解更多 Apollo Client 的牛逼功能，例如 optimistic UI、重新獲取、分頁獲取，請查看我們的狀態管理指南。

在許多情況下，在現有的 REST 接口層之上增加 GraphQL API 層，可以提高你 App 的網絡性能，特別是在網絡差的情況下。雖然，你應該通過網絡性能監控來衡量 GraphQL 如何影響你的 App，但大家通常認為 GraphQL 通過避免客戶端與服務端的往返通訊(round trips)，和減少請求數據的大小來提升網絡性能的。

因為從服務端返回的響應中只包含你指定的查詢數據，所以 GraphQL 相對于 REST 可以顯著地減少請求數據的大小。讓我們看看前面文章中的例子：

const GET_DOGS = gql`
  query {
    dogs {
      id
      breed
      image {
        url
      }
      activities {
        name
      }
    }
  }
`;

GraphQL 服務響應中只包括 dogs 對象的 id、breed、image、activities 字段，即便 REST 層的接口 dogs 是帶有 100 個字段的對象也是如此，所有多余的字段都將在返回給客戶端之前過濾掉。

由于每個 GraphQL 請求只返回一個響應，使用 GraphQL 可以幫助你避免客戶端到服務端的往返通訊。使用 REST，請求一個資源就是一次往返通訊，往返通訊會快速地增加。如果你請求要列表中的每一項，每一項都需要一次往返，每一項中的每個資源也需要一次往返，總次數就是二者的乘積⁶，這就導致了請求時間過長。

譯注6：極端 REST 例子，列表長度 N，每一項 3 個資源，請求次數就是 3*N

GET /api/dogs/breeds
GET /api/dogs/images
GET /api/dogs/activities

使用 GraphQL，每個查詢代表一次往返通訊。如果你希望進一步的減少往返，你可以實現查詢批處理(query batching)，將多個查詢封裝到單個請求中。

雖然 GraphQL 規范是由 Facebook 在 2015 年公布的，但是自 2012 年以來，GraphQL 就是 Facebook 移動應用開發的重要組成部分。

在 Apollo 團隊，我們發現 GraphQL 為我們現有方案中遇到的很多問題提供了出色的解決方案，現在我們用它來優化我們的技術基礎設施。幾年來，我們和開源社區、客戶、合作伙伴一起，為開源項目 Apollo 帶了了諸多創新。我們很驕傲，Apollo 適用于各類公司，從創業公司到大型企業。

除了我們自己的經驗，我們還收到了積極地在生產環境中使用 Apollo GraphQL 的企業客戶的廣泛反饋、貢獻和支持。一些最值得借鑒的案例是：

The New York Times(https://open.nytimes.com/the-...: 學習 The New York Times 如何從 Relay 切換到 Apollo，實現他們 App 的 SSR 和持久化 queries。

Airbnb(https://medium.com/airbnb-eng...: Airbnb 在 Apollo 平臺上下了重注，去強化他們微服務的數據層。

Express(https://dev-blog.apollodata.c...:使用易上手的 Apollo 分頁功能，優化我們團隊的關鍵應用。

Major League Soccer(https://dev-blog.apollodata.c...: 團隊的數據管理工具從 Redux 切換到了 Apollo，幫忙他們刪除了幾乎所有的 Redux 代碼。

Expo(https://dev-blog.apollodata.c...: 使用 Apollo 開發 React Native App 使得團隊可以專注于改善產品功能，而不是寫數據抓取的邏輯。

KLM(https://youtu.be/T2njjXHdKqw): 學習 KLM 團隊如何使用 GraphQL 和 Apollo 擴展他們的 Angular app。