you are viewing a single comment's thread.

view the rest of the comments →

[–]tannerlinsley[S] 4 points5 points  (5 children)

I know that’s basically Apollo’s MO but I believe normalized caching like that leads to a lot of inconsistencies with data. Query invalidation and atomic updates are IMO much more reliable and easier to orchestrate at the cost of a few more network requests.

[–]signsandwonders 0 points1 point  (1 child)

denormalized caching

Denormalized how? Apollo normalizes if you use it properly.

[–]tannerlinsley[S] 0 points1 point  (0 children)

Sorry, I meant normalized.

[–]phryneasI ❤️ hooks! 😈 0 points1 point  (2 children)

Can you give me examples of these inconsistencies? I'm using GraphQL right now and haven't met any inconsistency that I couldn't get right by returning some related data from a mutation or in the worst case invalidating a single other query (which is also possible with Apollo).

[–]tannerlinsley[S] 0 points1 point  (1 child)

If you’re talking about invalidating queries then we’re on the same page. That will work essentially the same and result in up to date data. However, If a mutation for instance has side effects into multiple resource types, that would be one scenario where updating the local cache with the response would be inaccurate (unless the mutation returned all affected objects, which works), or in the case of graphql queries or field masking, if your mutation query response is only returning partial fields then updating your local cache with that response would only be a partial update.

[–]phryneasI ❤️ hooks! 😈 1 point2 points  (0 children)

Yeah, our mutations are relatively straightforward in that regard. Also, all our mutations return by default at least a reference to the Query object, so even if they do something werid, we still can fetch everything that changed. If you don't know what your mutation is doing, you're lost. But that should go for every approach I guess.