Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v2 Migration Docs: InMemory vs v1 Redux Cache performance benchmarks? #2873

Closed
kevinzwhuang opened this issue Jan 16, 2018 · 2 comments
Closed

Comments

@kevinzwhuang
Copy link
Contributor

My team has been using Apollo since [email protected] and one of the biggest draws to Apollo vs Relay was Apollo's use of Redux as a cache, instead of a custom cache.
For us, being able to use the dev tooling around redux we had already been using for redux to support graphql development was a huge boon to our adoption of graphql.

We're still on v1.x and looking over the v2 migration docs to figure out an upgrade strategy. Now that V2 has moved away from using redux as its default cache, I'm trying to learn about the performance improvements the InMemory cache has over the old redux cache implementation.

I think that if we provided Apollo users with more performance metrics on how the InMemory cache has improved vs the old Redux cache - this would help users understand more thoroughly why the switch was made.

@fc
Copy link

fc commented Jan 16, 2018

Redux is not gone as a store option, check here:

https://github.com/rportugal/apollo-cache-redux

Check the issue regarding performance here:
rportugal/apollo-cache-redux#14

It sounds like there is some room for optimization for certain cases.. but other than that, check it out.

If you depend on apollo redux actions, then look into apollo-link-redux:
https://github.com/AdamYee/apollo-link-redux/

on my team we decided to rewrite the parts that depended on the apollo actions so we can use the InMemoryCache. The Chrome plugin for Apollo allows for introspection although it's not quite as easy to see the differences and changes in state.

Also watch out that apparently IE11 does not work unless you use a polyfill for fetch (#2780 (comment)).

Refetch is also broken in certain cases but there is currently a PR out there for it (fixed in react-apollo 2.1.x) (apollographql/react-apollo#1531).

It also appears a query with a pollInterval can stop issuing the query when there is an error (fixed in react-apollo 2.1.x):
apollographql/react-apollo#1229

The refetch and pollInterval issue are blockers for us but did not discover all of this until 50%+ of the way through the upgrade. Our apollo-client 2.0 upgrade branch will be collecting dust until they address those things.

Edit: The blockers mentioned above are fixed in [email protected] (in beta at the time of this edit).

@Poincare
Copy link
Contributor

Thank you for the very thorough answer, @fc. I'll go ahead and close this, but if any other questions persist on this, please reopen.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 17, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants