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-gr...