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.
They mention it in the article but forgot the caveat in the title:
 Or any well designed back end API
How GraphQL Replaces Redux
 For some narrow, often simple applications. And even in those cases it usually doesn't replace redux as much as it augments it.
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).
I started using the Apollo Universal Starter Kit. They were using both Redux with Apollo GraphQL. This really bothered me because there were two stores. Apollo 2 doesn't use Redux for the cache anymore. I went ahead and first pulled out the Redux dependency using Apollo Link State. Then I went ahead and removed the Redux-Form dependency using Formik instead. The project maintainers thought it was a good idea and removed Redux and Redux-Form dependencies from all the packages. If you are looking for a way to not use Redux with Apollo, it has been solved. Although Apollo Link State requires some more code, it does normalize the data which means selectors are not needed which is a nice way to think about the data.
The title is a little click-baity, but if I have it right, the OP is saying that: because you can control the shape of your data on the client (graphql) you don't have to write code to wrangle your response data into the shape of your react component's properties (redux).
Which kind of makes sense, but I'm more biased towards thinking you'd almost always need some client-side work to reshape the response data because the front-end will always evolve at a different pace to the graphql endpoint, which ultimately has to be implemented by the server. Unless the entire team reaches this amazing point where the "graphql schema" and the abstractions in the app are just always in sync. Isn't it?
(Also, I love redux. Almost can't imagine using react without redux for any application. I started using react unreservedly, because redux. After disastrous attempts at flux. Redux is not going away I think.)
Sounds like you could have made your feed items REST API return the top 3 comments as well...
Maybe the lesson here isn't that GraphQL is a magic bullet, but that designing your API for your business needs solves a lot of frontend complexity (even if it's not pure "REST").
Seems like you were just using Redux incorrectly.
What protections can you put in place to limit the client query?
It seems with an appropriate GraphQL query it would be possible to generate significant data retrieval server side.
Redux is useful, just not as a primary store for model data.
For example, Found (https://github.com/4Catalyzer/found) uses Redux to keep route state. It's nice to use Redux in that context, because route state is global but also simple, not very hierarchical.
But for model state, Found integrates with Relay (https://github.com/4Catalyzer/found-relay/), because, as this article says, GraphQL reduces a lot of the REST/UI impedance.
For a better introduction on how Apollo v2 (the graphql client) could replace redux, read this: https://dev-blog.apollodata.com/the-future-of-state-manageme...
I’ve personally tried it (with special attention on its capability to manage local state) and it did work out pretty well, with a lot of redux boilerplate code eliminated and a more effecient workflow, better yet, now you just need to learn one graphql syntax to rule them all.
TL;DR click bait. The author is replacing Redux with Apollo - a client side graphql library that HAS BUILT IN STATE MANAGEMENT, which he fails to differentiate or mention... Apollo is similar to the firebase event / subscription model.
Question for Apollo Client users.
I've been using Apollo Client. When I add or delete data, I need to update the local store on Apollo.
How have you found your experience using the local store on Apollo versus Redux?
I'm a bit lost. Aren't they two different things? One is a DSL for APIs, the other one is a state manager.
actually, apollo-client is building in support for REST, so you will be able to use apollo-link-state with your restful api AS WELL AS your graphql api.
That's the true "replaces redux" statement.
Will you make a fresh HTTP request every time the client needs to render a component? You could persist data client-side to make things more efficient. It would be best to use a state container to manage this. Maybe something like Redux?