Invalidate Query

[oscartbeaumont]

Add the option to invalidate queries by key on the frontend when a mutation is submitted (like trpc does).

For now, you could use a subscription to work around the lack of this although that's not gonna be the best DX.

Also, add typesafe invalidate hook to the frontend.

[oscartbeaumont]

Maybe something like

<Router>::new()
    .query("version", |ctx, arg: ()| {
        ctx.invalidate_key(..); // This would return a result and would fail if the key or arguments are invalid.
        invalidate_key!(ctx, ..); // Similar to Spacedrive's `invalidate_query!` this would be able to check the argument/key is valid on startup using ctor.
    })

[oscartbeaumont]

#113 just linking this because it discusses this issue.

[oscartbeaumont]

One huge concern here is that we need to be able to only invalidate queries that are actively rendered on the frontend.

For future me's reference: keep it scoped to a single procedure and return the keys to invalidate in the response for it. This way this isn't a concern. DON'T COPY SPACEDRIVE AND END UP IN A POSITION WHERE THIS IS HARD TO FIX.

[emi2k01]

Why is the backend concerned with query invalidation, shouldn't that be client-only?

Sorry if there's something obvious I'm missing. I was just checking out the library so I'm not familiar with it.

[oscartbeaumont]

For many applications, all of the changes to data are coming from the active user and in this case, you only need to deal with invalidation on the frontend because it's fine to assume the active user is only going to have a single instance of your app open at a time.

In a practical example: The user makes a change to some data, then the frontend updates its own cache and shows the user the updated data. If the user jumps to another device we assume they will open/reload the page to get the most up-to-date data.

For Spacedrive we have a whole job system that runs in the background and can scan & organise your files. We also sync data over a peer-to-peer system so all of your devices have their own local copy of your data. The challenge here is that many of the data changes come from the backend instead of the user/frontend. A backend invalidation system allows the backend to ask the frontend to update a piece of data because it knows it has changed.

In a practical example: A job in Spacedrive scans a new file and the "total storage used" for a library is updated. The invalidation system then tells the frontend to refetch the value from the backend so it is showing the most accurate value. Without a backend invalidation system the frontend wouldn't know the data had changed and it would require the user to refresh the page for an updated value which isn't a great UX for an application as interactive as Spacedrive.

Many applications poll for new data every x seconds/minutes. This is super easy to implement but it is either slow to receive updates or has a large network and server overhead. Backend-powered invalidation is hard but it is much more efficient and can lead to near-instant updates for new data.

Hopefully that all makes sense, let me know if you need any clarification.

[emi2k01]

That was very clear! Thanks for the detailed response :)

[oscartbeaumont]

For my personal reference this is an idea Brendan came up with for Spacedrive.

[tomheaton]

just a quick solution for @rspc/react / @rspc/client / @tanstack/react-query users

export function invalidateQuery(queryKey: Procedures["queries"]["key"]) {
  queryClient.invalidateQueries({ queryKey: [queryKey] });
};