Optimistic Updates With GraphQL

[Undistraction]

I'm implementing optimistic updates for an app that is using a GraphQL API and I'm finding it to be much more involved than I was expecting which is making me think there has to be a better approach. The main problem is that in order to optimistically update the cache, I need to know not only each query that the update needs to patch, but also all the arguments for those queries.

For example, imagine I have a getUser query and that returns a user with some posts (used to render a list of posts). I then have a separate query for getPost (used to render an individual post). If I want to use optimistic updating for my updatePost mutation, I need to patch both the getUser query and the getPost query, and to do that I need the id of the user, plus any other params that were passed in to that query. So now I also need to pass the userId into updatePost so that it is available inside onQueryStarted. This means that a component deep in the hierarchy that should only need to care about an individual post now also needs to know about the user.

Additionally, having to 'know' about which queries to patch seems like something that is duplicating the use of tags to provide and invalidate data.

What am I missing here?

[markerikson]

RTKQ works by serializing the arguments so it can generate the cache key, like getPokemon('pikachu').

Hypothetically, how would you expect to be able to update individual cache entries without knowing the way to look them up?

[EskiMojo14]

@EskiMojo14 thanks. That's definitely interesting. Would be nice to have a selectArgsForQuery utility.

Sure, it's something that comes up every once in a while - I've opened a PR with it #3547 and will see how the other maintainers feel.

[phryneas]

I'd say you are getting to the point where you might want to take a normalized GraphQL client like Apollo Client into account.
RTK Query is okay if you have very light usage of GraphQL and treat your API more like a Rest API - but if you really want to go into the benefits of GraphQL, you might be better off with a specialized client.

[Undistraction]

Yeah. I'm starting to come to that conclusion. It really doesn't feel like RTKQuery is suited for GraphQL at all.

[phryneas]

It can cache GraphQL requests, but we are very upfront that it is a document cache, not a normalized cache.
At this rate, RTK Query is about the level of urql without their optional Graphcache - no normalization, the only good way of updating data is automatic invalidation. That's okay for smaller apps, but not for advanced use of GraphQL.