GraphQL does not replace redux, Apollo sort of does but they solve different overlapping problems. GraphQL is serializable & a graphQL query or mutation is con

GraphQL does not replace redux, Apollo sort of does but they solve different overlapping problems. GraphQL is serializable & a graphQL query or mutation is conceptually the same as a standard FLUX action used by Redux. The main difference is Redux intends to separate async logic & mutations, to make them easier to reason about in isolation. Apollo intends to remove the need to reason about async logic. In Apollo, you still have to deal with state mutations by refetching everything after any change, or writing verbose cache invalidation logic. So both Redux & Apollo make you reason about state mutations. Apollo-link is like Redux middleware, it uses observables so its like redux-observable middleware. If you treated Apollo like Redux, you'd have to fire a graphQL mutation as if it were a Redux action. In redux you can ignore an action. In Apollo, to ignore a mutation you would have to write custom apollo-link middleware to handle that action (mutation). As you can see redux & apollo solve overlapping but different problems. If you are coalescing multiple API responses coming in over time, you may have a need for RxJS, not Redux. That is inherently a stream of events happening over time, so use a streams library (perhaps together with Redux).