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?

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.