Approaches to additionalTypenames in projects

[MH4GF]

Hello, and thank you for the fantastic library!
In our project, we are using urql with document caching. Our product does not have strict performance requirements, and we prioritize minimizing the risk of bugs due to cache operations over cache efficiency. Therefore, we believe urql and document caching are the optimal choices for us.

I would like to seek advice on the basic policy we are forming for using additionalTypenames in our project, to ensure there are no concerns.

In operating document caching, we need to consider which types to add to additionalTypenames. As mentioned in Document Cache Gotchas, if there are patterns where list field response data becomes empty, those should be added. However, trying to do this rigorously can be challenging, as it's often only apparent at runtime, making it difficult to enumerate types accurately. Therefore, our project's basic policy is to "add all list fields in an operation to additionalTypenames". This approach may reduce cache efficiency, but since our product prioritizes minimizing the risk of bugs, we don't see this as a problem.

Additionally, we are creating a custom plugin for graphql-code-generator to automatically generate code for additionalTypenames that enumerates list types included in operations. (We are currently testing this as a Proof of Concept in our product and plan to publish it as OSS on npm later.)

Regarding this, I would like to ask the following:

• Is there any concern, from the perspective of urql's mechanisms, about our basic policy of "adding all list fields in an operation to additionalTypenames"?
• We are currently prototyping a custom plugin for graphql-codegen. What are your thoughts on the alternative of enumerating additionalTypenames at runtime, perhaps as an exchange?

I would appreciate your insights on these two points. Thank you!

[kitten]

There's no concerns there, in my opinion. The mechanism is explicitly for mutations, so even if every mutation invalidates all or almost all queries, that should still function as intended, and if correctness and fresh data are the priority, I think ensuring that you have enough additionalTypenames tags in your mutations and queries, then that's the way to go.

We are currently prototyping a custom plugin for graphql-codegen. What are your thoughts on the alternative of enumerating additionalTypenames at runtime, perhaps as an exchange?

In theory, that's not a bad shout either. A simple mapExchange could take each operation, before it reaches the cache and identify the lists that are relevant, adding “tags” for them to mutations and queries, to match up.
If you have a limited set of fields that are relevant, traversing the AST and updating additionalTypenames in the runtime could be a good approach if GCG is proving to be unreliable for the purpose. Ultimately, the approach should be quite similar either way, and it may be easier to write an AST traverser than it is to update the GCG code output 🤔

[MH4GF]

@kitten
Thank you for your prompt reply, hearing your response is reassuring. We'll proceed with this approach!

The mechanism is explicitly for mutations, so even if every mutation invalidates all or almost all queries, that should still function as intended,

Also, thanks for your opinion on the extension. Indeed, it seems like a good idea to base it on mapExchange. I've managed to get to a point where traversing the AST with the GCG plugin is working well, so I'll try porting that! The challenge will be needing schema information at runtime, but Schema Awareness looks like a good reference, so I'll check that out.

I'll share more updates as they come! Have a great weekend! 😄

[MH4GF]

@kitten
It has been some time since then, but I have reworked it with the approach to implement it in exchange. I have just released it to npm with a testing period in between in my project!

• https://www.npmjs.com/package/urql-exhaustive-additional-typenames-exchange
• https://github.com/route06/urql-exhaustive-additional-typenames-exchange

I have also written an article about document caching(in Japanese): urqlのDocument Cachingを安全に運用する - ROUTE06 Tech Blog

Thank you for your advice! We will continue to use urql!