Apollo Client Cache vs. Redux

Question

I'm trying to migrate from Redux Store to use Apollo Client Cache that comes with Apollo Graphql Client.

One of the key features that sets Apollo Client apart from other data management solutions is its normalized cache. Just by setting up Apollo Client, you get an intelligent cache out of the box with no additional configuration required.

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.

Questions:

1) What are the advantages of moving from Redux to Apollo Client Cache?

2) Is there anything that I should be worrying about before migrating to Apollo Client Cache?

Geometric

you can use both in the same time, just move [incrementally] all data fetching/updating into apollo, move global app state management later/when ready – Monomerous

Answer 1

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.

Omnivorous

Thanks for thr insights. Very helpful – Geometric

The link you shared is from an article written in 2016. Just because it's old, doesn't mean it's not relevant advice. However, we've learned a lot about state management in the past 4 years. Specifically, the dangers of using one tool for every job. Redux was never designed to handle remote/async state. For side effects such as data fetching or web socket events, I think Apollo can help a lot with its cache. – Heaven

Check out ngxs.io for the successor to ngrx – Illyricum

Thanks for your good article. I got inspired a lot from this article regarding global state management in react. One thing I am a bit curious is at the last paragraph, you noted that apollo-client cannot replace redux. I thought we can migrate from redux based app to apollo-client based... so I am not sure about your opinion. – Cabriolet

"redux allows you to create a predictable state container that changes in response to the actions you define" Actually, Apollo's state container also changes automatically when mutations are made. Just my 2 cents. – Coextend

Apparently, apollo client is able to replace redux. Tools like react-query is also able to replace redux. But remember, apollo and react-query also come with server state management out of the box. redux is just a client side state management solution. – Avestan

I disagree in general. Too many devs use redux for server-side state. For those, the comparison is apples to apples. – Desecrate

Answer 2

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

Heaven

Answer 3

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

Giddens

NOT ONLY GRAPHQL backend - apollo client can use REST API, apollo server can do this, too – Monomerous

@Monomerous you got me wrong, I didn't say apollo client "CAN'T", if the backend uses REST apis, then in front end in order to use the apollo client we would have to write local resolvers which would be an overhead. In my opinion using redux in such scenarios would be more suitable. – Giddens

my comment was an addition ... you can go with apollo even if you can't quickly adapt/wrap REST api, it can be one of [many] migration steps ... not my downvote – Monomerous