GraphQL 如何取代 Redux

簡評：使用 GraphQL 能夠大大簡化客戶端狀態管理部分的代碼。

⚛️切換到React

故事背景：在 2016 年，Pathwright 的前端團隊就開始將客戶端的代碼從 Backbone & Marionette 切換到 React。 對於咱們來講 UI 的聲明性模型比 MVC 模型更具意義。

咱們使用 flux 架構來管理隨着應用狀態，隨着業務變得複雜，它添加了愈來愈多間接層。當咱們着手處理 store 或者狀態樹中的一個分支邏輯的時候，其實是將服務端業務數據和關係複製到客戶端上。

咱們擁有優雅的聲明式 React 組件，可是數據層確是 action、reducers、異步中間件和去賦範的數據邏輯。

這一切都感受很是的錯誤。

↪️切換到GraphQL

當咱們嘗試 GraphQL 的時候立刻就愛上了它。咱們將 GraphQL 替換了一堆 REST API。當咱們 UI 使用這些新的 GraphQL 時再也不須要 store。咱們一般須要建立一個 stores，action 等待，可是最終咱們將這部份內容刪除了，由於實在沒有必要。

產生這種觀點的三個主要緣由

1. 咱們大部分的狀態管理代碼關注的是未來自分散的 REST 資源合併和變換成適用於咱們 UI 的數據。
2. 不少複雜的狀態管理就是有序的獲取全部異步數據（sagas, 中間件, thunks 等等.） 實際除了上面這部份內容，咱們使用自帶的
3. React state 能夠很好的知足咱們平常業務。

關於 GraphQL 和 Redux

前面可能有點標題黨。咱們真正替換的是 REST API，當成功替換後咱們發現大多數狀態管理代碼再也不必要。

當客戶端能夠控制服務端返回數據的具體模板（只須要一個請求），這大大簡化了咱們應用邏輯（主要是狀態管理部分），咱們甚至再也不須要使用狀態管理庫來幫忙管理咱們的庫，由於應用邏輯變得足夠簡單。

爲了說明這一點，假設咱們的 UI 經過狀態管理庫和後端服務進行通訊。

這多是這樣的：

上圖就直觀的列出了 Redux/REST 和 Apollo/GraphQL 的區別, Redux 爲咱們實現了不少的內容，可是不可避免的要處理多個請求。而 GraphQL 則直接從縮減處理邏輯來大大簡化這部份內容。

我認爲對於大部分客戶端應用程序， GraphQL 能夠徹底取代對 Redux 的需求。這並非說 Redux 不能知足需求（實際上這是一個很棒的庫）。並且 Redux 有助於咱們處理 REST（由於不少時候咱們沒法控制後端的接口使用 GraphQL ，大部分仍是使用 REST）。

但。。。

若是你可使用 GraphQL 而不是 REST，那麼我建議使用 GraphQL 的優點消除客戶端狀態管理中的複雜性邏輯。

原文：https://hackernoon.com/how-graphql-replaces-redux-3fff8289221d