GraphQL 如何取代 Redux

簡評：使用 graphql 可以大大簡化客戶端狀態管理部分的**。

故事背景：在 2016 年，pathwright 的前端團隊就開始將客戶端的**從 backbone & marionette 切換到 react。對於我們來說 ui 的宣告性模型比 mvc 模型更具意義。

我們使用 flux 架構來管理隨著應用狀態，隨著業務變得複雜，它新增了越來越多間接層。當我們著手處理 store 或者狀態樹中的乙個分支邏輯的時候，實際上是將服務端業務資料和關係複製到客戶端上。

我們擁有優雅的宣告式 react 元件，但是資料層確是 action、reducers、非同步中介軟體和去賦範的資料邏輯。

這一切都感覺非常的錯誤。

當我們嘗試 graphql 的時候馬上就愛上了它。我們將 graphql 替換了一堆 rest api。當我們 ui 使用這些新的 graphql 時不再需要 store。我們通常需要建立乙個 stores，action 等待，但是最終我們將這部分內容刪除了，因為實在沒有必要。

我們大部分的狀態管理**關注的是將來自分散的 rest 資源合併和變換成適用於我們 ui 的資料。

很多複雜的狀態管理就是有序的獲取所有非同步資料（sagas, 中介軟體, thunks 等等.）實際除了上面這部分內容，我們使用自帶的

react state 可以很好的滿足我們日常業務。

前面可能有點標題黨。我們真正替換的是 rest api，當成功替換後我們發現大多數狀態管理**不再必要。

當客戶端可以控**務端返回資料的具體模板（只需要乙個請求），這大大簡化了我們應用邏輯（主要是狀態管理部分），我們甚至不再需要使用狀態管理庫來幫忙管理我們的庫，因為應用邏輯變得足夠簡單。

為了說明這一點，假設我們的 ui 通過狀態管理庫和後端服務進行通訊。

這可能是這樣的：

上圖就直觀的列出了 redux/rest 和 apollo/graphql 的區別, redux 為我們實現了很多的內容，但是不可避免的要處理多個請求。而 graphql 則直接從縮減處理邏輯來大大簡化這部分內容。

我認為對於大部分客戶端應用程式， graphql 可以完全取代對 redux 的需求。這並不是說 redux 不能滿足需求（實際上這是乙個很棒的庫）。而且 redux 有助於我們處理 rest（因為很多時候我們無法控制後端的介面使用 graphql ，大部分還是使用 rest）。

但。。。

如果你可以使用 graphql 而不是 rest，那麼我建議使用 graphql 的優勢消除客戶端狀態管理中的複雜性邏輯。

原文：