You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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).
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.
The text was updated successfully, but these errors were encountered: