GraphQL is a convention on communication, like REST. Redux is a way to manage application state. They are apples and oranges. You could ostensibly feed a Redux store with GraphQL.

This post is like all the others that tout, "moving from X language to Y saved us $3,000 per month on AWS" – it's usually not the transition from one tool to another, it's the fact that you rewrote your application with more knowledge and insight into the problem and have simply done a better job. Or in this case, a misuse of Redux led to a transition to GraphQL which painted Redux in a poor light.

There still isn't a compelling solution to problems like this... Apollo certainly isn't it. I want to feed GraphQL & REST into a central datastore in my application (be-it a Web/SPA/Browser app, or a local app) and abstract away the guts. A lot of devs are leaning on GraphQL for small experimental apps, fetching data in their components and violating every rule in the book on SRP and SOLID. It works for MVP's and hobby projects, but when you have a larger team, userbase, etc... the abstractions become critical.

We, as an ecosystem, need to focus more on those abstractions and not on the one-size-fits-all buzzword tooling. Server <> Datastore <> Application, not Server <> Application with the library of the week bolted in.