Apollo Client Cache vs. Redux
I think you made a good point here: "With Redux we have to write actions, types and dispatch actions based on the response received from the side-effect and set the data in the store using reducers, which is done by Apollo Client automatically."
For side effects, Redux is imperative, and Apollo is declarative. Declarative code is usually shorter, since you're delegating logic to the library/framework.
Daniel Rearden made a good point that comparing Redux and the Apollo client cache is like apples and oranges. The apples and oranges here are the different types of state, specifically remote and local state. Unfortunately, Redux encourages us to treat all state the same.
I would leverage Apollo cache for state that needs to be retrieved, updated, and mutated on the server. I would reach for lighter tools like React's Context API for preventing prop drilling, global app state, and hooks for business logic (e.g. useReducer/useState).
The tricky part is when remote state and local/global app state mix. So I would be careful to define patterns around how they interact
You're comparing apples to oranges. Yes, at a high level both redux and apollo-client provide a way for you to manage global application state. However, redux allows you to create a predictable state container that changes in response to the actions you define. That means redux offers:
- Predictability. Reducers are pure functions -- given the same state and actions, a reducer will always produce the same result.
- Testability. Again, because reducers are just functions, it's simple to unit test them.
- Scalability. Because redux forces you to organize your code in a specific way, it makes your code more maintainable. Even your as your code base grows, your code is still debuggable and understandable by other developers.
Dan Abromov points out several other benefits:
- Serialize user actions and attach them, together with a state snapshot, to automated bug reports, so that the product developers can replay them to reproduce the errors.
- Pass action objects over the network to implement collaborative environments without dramatic changes to how the code is written.
- Maintain an undo history or implement optimistic mutations without dramatic changes to how the code is written.
- Travel between the state history in development, and re-evaluate the current state from the action history when the code changes, a la TDD.
- Provide full inspection and control capabilities to the development tooling so that product developers can build custom tools for their apps.
- Provide alternative UIs while reusing most of the business logic.
Yes, redux comes with a lot of boilerplate. However, both you, your application and your team can potentially reap a lot of benefits from using it beyond just having a way to manage global state. On the other hand, if you don't see value in the features provided by redux, or don't think they're worth the indirection and complexity redux adds to your code, then don't use it. If all you need is a way to manage global application state, then you can utilize apollo-client or some other library or just utilize the Context API and the useReducer hook to roll your own solution.
Apollo Client's use of the @client directive to manage local state is very convenient, especially if you'r already using the library for querying a GraphQL API. Being able to easily decorate query results with derived fields is neat. Being able to utilize the same API for querying your server and querying local state makes for good DX. But apollo-client cannot replace redux because at the end of the day the two libraries do very different things for very different reasons.
migrating to apollo makes sense only if your backend allows to make graphql call, we have migrated our project from redux to apollo and it has come out very good.
Read this blog too, it was from this blog we decided for the migration