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