apollo-client 是一個比較難用的 GraphQL 客戶端，本系列帶你整合 redux，趟平深坑，鑽入原理，讓你在 21 分鐘內學完 apollo-client。
NOTE: 閱讀過程中如果產生任何不適，請及時撥打 120 自行搶救，謝謝。
本系列的目標：
簡單
- 選型建議（是否值得使用 apollo-client）
- 搭建 Apollo client 端，整合 redux
- 使用 apollo-client 來獲取資料
- 修改本地的 apollo store 資料
進階
前置技能
- 瞭解 React + Redux
- 瞭解 GraphQL 的基礎概念
對怎麼寫 Query 等 GraphQL 基礎問題不會提及，請檢視官方文件Queries and Mutations | GraphQL。
限定提示
- 本方案目前僅使用了 Query 功能，不涉及 Mutation
背景
我司本來採用 RESTful api，但是完全遵循 RESTful 以來，隨著業務不斷擴充套件，api endpoint 簡直多到爆炸。
對於前端來說，api 太多也難以維護，尤其是設計初期沒有提前介入，會導致返回類似的 model，其 Schema 可能不同，這種不一致導致了很多髒程式碼的產生；
後端也懶於一遍遍地提供類似的介面。
於是，我們就採用了 GraphQL 來解決這個問題。
這裡要跟大家明確下我們的專案背景，在採用 GraphQL 前：
- 後端已經基於 RESTful api 搭建了一套很完善的工作流，GraphQL 必須要與 RESTful 共存
- 前端基於 Redux + redux-saga + Immutable.js，並做了不少定製化，引入 GraphQL 必須要與之前的資料儲存方案不衝突
後來，後端決定只使用 GraphQL 的 query 功能，也就是隻 GET，其它 http 動作仍然走 RESTful api。
如果你的專案是全盤採用 GraphQL 的，下面的實踐分享可能不適合你，僅供參考。
client 端選型
GraphQL 總體還是比較前後端分離的，不強制你使用某一種 client 方案。從 awesome-graphql 這個庫，進入我們視野的主要有兩個
- Relay
- Apollo
Relay
先說說 Relay。
Relay 是官方出品和推薦的，也是預設的配套方案。文件和解決方案更齊全一點。
我粗略掃了一下 Relay 的文件，從它提供的 api 推測，Relay 不僅僅處理 GraphQL，還接管了狀態管理等等，理論上用了 Relay 可以不用 Flux 、Redux 了。
考慮到可能和我們現存的 Redux 方案可能衝突，就放棄了。
Apollo
然後是 Apollo。
Apollo 在 github 上 star 也不少，文件乍看也還不錯，除 React 外還適配多個框架。
而且有專門提到和 Redux 整合的章節：Integrating with Redux | Apollo React Docs。
時間緊迫，沒有想那麼多，我就用了（手動捂臉哭）。
事後來看，Apollo 的坑不少。而且最終 Apollo 與其說是和 Redux 整合起來，不如說是隔離開來了，因為 Apollo 也相當於單獨維護自己的一個 store。這讓我反思是否最初使用 Relay 也會得到同樣甚至更好的結果。
不管怎麼說，如果你也上了 apollo-client 的賊船，那麼希望本系列文章能讓你少採一點坑。