Migrate cache to Apollo v3

[eric-burel]

Is your feature request related to a problem? Please describe.
We need to update Apollo client cache system to v3. The problem is that there is a breaking change, there is no fragment matcher anymore: https://www.apollographql.com/docs/react/migrating/apollo-client-3-migration/#breaking-cache-changes

End user must be able to provide "possibleTypes" instead.

Also, updating the cache directly lead to writeData is not defined for hooks optimistic update.

Describe the solution you'd like

• should we compute possible types automatically? As long as we don't generate unions I think not
• however we certainly need the user to be able to setup the possibleTypes for their app

So:

1. Adding a new method to register some possible types? Pass them at client creation?
   (note that in Next we avoid such issues by letting the user create its own client ; creating it in Vulcan core is convenient but makes tweaking diffficult).
2. remove apollo-cache-* deps when done
3. replace cache "writeData" by writeQuery (as it is already done in Vulcan NPM: https://github.com/VulcanJS/vulcan-npm/blob/devel/packages/react-hooks/multiQueryUpdater.ts), this part will be easy

Additional context
https://www.apollographql.com/docs/react/migrating/apollo-client-3-migration/#breaking-cache-changes

[ErikDakoda]

I am seeing a lot of "Invariant Violation" errors from Apollo 3 in the browser console. They are not causing breaking errors, but they are an indication that the Apollo client cache is probably not operating efficiently.

So the point is that we need to move on this sooner rather than later.

In addition, there are other vestiges of Apollo 2 like apollo-link-state that we should probably deprecate from the Vulcan code (see apollographql/apollo-client#5982). In this case it's possible that nobody in Vulcan land is using link state - but how do we find that out? Is it safe to just remove this feature?

I could probably make these changes, but I can't commit to starting right away because of other deadlines I have. But if I do start on this, how do I make sure that no-one else is doing the same work? To discuss that question further, I will open another issue.

[eric-burel]

Contribution on Apollo v3 would be muuuch appreciated. If you start something, I would simply suggest releasing a patch version of Vulcan current code before we merge the work, and then release a minor.

It's ok to have breaking change, as long as we rely on semantic versioning. There is also a MIGRATING.md where you can explain breaking changes manually + the automated changelog.