How would one go about invalidating queries based on a partial argument set ?

[strblr]

Hello,

Thank you for your awesome work on live queries. I'm strongly considering using it in a large production app.
However, reading the doc, I found myself with the same question I had when I first read about cache invalidation on the client side (for example with urql) : How do you invalidate queries without specifying every argument ?

For urql's graphcache, I found a solution inspired by this.

Because not every argument is always relevant. For example if I want to invalidate a paginated todos query identified by a categoryId (let's say), I wanna target my invalidation only based on categoryId, regardless of cursor, limit, offset, etc.

Thank you in advance and keep up the good work.

[n1ru4l]

If you have a Query.todos field you can invalidate all queries that select the data via the schema coordinate Query.todos. Is that what you mean, if not, could you provide a better description and example of what kind of operations you have and how you would like to invalidate them?

[n1ru4l]

@ostrebler I kicked things off with a small refactor: #619 - it should make implementing custom indices quicker. If you need closer contact I am also on the GraphQL Discord, so you can reach me there as well :)

[strblr]

@n1ru4l Nice ! I'll start working on my part by the end of the week.

[strblr]

Hi @n1ru4l,

My absolute apologies, I got distracted by other tasks.

So here is my situation : I manage a very large Node / GraphQL / React app used by multiple manufacturers and there is now a real call on their part for live updates. So I'm back on where I left in July, but I'm starting to wonder is manual lookup is really that necessary. I think it will depend on what I encounter as I migrate the project to your library.

Did you implement the coordinate index system? Is it available?

Last question: some queries produce different output depending on the context and not on the arguments (for example, a todo's "isEditable" field would depend on the privileges of the user making the request). Can that be an issue with your library?

Thank you very much.

[n1ru4l]

@ostrebler I have not implemented this yet. All the live queries are tracked individually, thus properties that differ between users will not make a difference! A invalidation will re-execute the whole query operation for each user individually. Of course this might become a bottle neck when having a lot of users. So far I have tested this engine with around 20 users (and very frequent updates) successfully. Potential scaling solutions could be to use more instances so each instances has less operations to re-execute once an invalidation happens. That is something yet to explore and I did not have the right project for that yet.

Please keep in mind that for some application types such as collaborative text editing CRDT might be the better solution.

If you need some reference project you can have a look at https://github.com/dungeon-revealer/dungeon-revealer

[strblr]

Hi @n1ru4l, the production app I want to adapt to live queries often has more than 20 users at the same time. I can definitely give you feedback on how it goes.

Using an ugly hack to solve the mjs / webpack problem, I was able to kick things off a bit. So far, I tested it with basic queries that have an id field, it works like a charm. To go further and since a lot of queries are not indexable by id, I actually need the custom coordinate indexing system you talked about here. When may you be able to do it ? Thanks!

I'm starting to work on custom lookups right now. Edit: #759