简评：使用GraphQL可以大大简化客户端状态管理部分的代码。??切换到React的故事背景：2016年，Pathwright的前端团队开始将客户端代码从Backbone&Marionette切换到React。对我们来说，UI的声明模型比MVC模型更有意义。我们使用通量架构来管理应用程序状态，随着业务变得复杂，它会添加越来越多的间接层。当我们开始处理存储或状态树中的一个分支逻辑时，我们实际上是将服务器端的业务数据和关系复制到客户端。我们有优雅的声明式React组件，但数据层实际上是操作、reducer、异步中间件和非规范化数据逻辑。这一切都感觉很不对劲。??切换到GraphQL当我们尝试使用GraphQL时，我们立即爱上了它。我们用GraphQL替换了一堆RESTAPI。当我们的UI使用这些新的GraphQL时，就不再需要商店了。我们平时需要创建一个store，actionwait，但是最后我们去掉了这部分，因为没有必要。出现这种观点的三个主要原因我们的大多数状态管理代码都与将来自不同REST资源的数据合并和转换为我们UI可用的数据有关。很多复杂的状态管理就是有序的获取所有的异步数据（sagas,middleware,thunks等）。其实除了上面的内容，我们使用内置的Reactstate也能很好的满足我们的日常业务。关于GraphQL和Redux可能会有一些头条新闻。我们真正要替换的是RESTAPI，当我们成功时，我们发现大部分状态管理代码都不再需要了。当客户端可以控制服务端返回数据的具体模板（只需要一次请求），这就大大简化了我们的应用逻辑（主要是状态管理部分），甚至不需要使用状态管理库帮助管理我们的图书馆。因为应用程序逻辑变得足够简单。为了说明这一点，假设我们的UI通过状态管理库与后端服务通信。可能是这样的：上图直观的列出了Redux/REST和Apollo/GraphQL的区别。Redux为我们实现了很多内容，但是处理多个请求是不可避免的。而GraphQL则直接从归约处理逻辑上大大简化了这部分内容。我认为GraphQL可以完全替代大多数客户端应用程序对Redux的需求。这并不是说Redux不能满足要求（它实际上是一个很棒的库）。而Redux帮我们处理REST（因为很多时候我们无法控制后端接口使用GraphQL，大部分还是使用REST）。但。..如果您可以使用GraphQL而不是REST，那么我建议使用GraphQL的优势来从客户端状态管理中移除复杂的逻辑。原文：https://hackernoon.com/how-gr...
