Can the standard QueryPersister be combined with the experimental_createQueryPersister

[sgcullen]

Can these two persisters be combined?

The standard one being used to restore the query cache on app load and the experimental_createQueryPersister to store and refetch through the life of the application should the cache items become stale?

Hope that makes sense and thank you!

[DamianOsipiuk]

These two persisters work in a different way. While both might be used at the same time, they will not work on the same cache, rather create two separate caches in your persistence layer.

• experimental_createQueryPersister - per-query storing each query cache as a separate entry in persistent store
• QueryPersister - stores all of the queryClient cache as one entry in the persistent store

It seems that you might want to use restoreQueries from experimental_createQueryPersister on app start.

[sgcullen]

@DamianOsipiuk Really appreciate your response Damian - thank you.

I appreciate and note that the persisters work differently.

I have a slightly strange use case (in a chrome extension context) whereby I have an Index DB persister using the experimental_createQueryPersister which is in general working really well and allows a lot of control but, when pages change it would help me to not have to fetch all recent queries which could be 10,000 or so individually. In this case, using the two persisters together seemed like it might offer the best of both worlds!

I think you're right though - it looks like restoreQueries would achieve a similar things - the entries function would just return the entirety of the IDB table when the persister is attached to the query client.

The other option is for me to move to use the standard persister and just rely on the cache for fetching. Out of interest - how large/scalable is the cache. Is 10,000 entries in the standard cache a problem?

Thanks so much!

[DamianOsipiuk]

QueryCache should be good as it's a Map under the hood.

QueryPersister might start being a bottleneck after some threshold (depending on single query size and number of queries). This is due to a fact that after any change whole cache state needs to be serialized and stored as a single entry. So the more cache grows, the more blocking time you will see.
Same thing goes for initial loading as we need to read and deserialize whole cache at once.

experimental_createQueryPersister was designed to overcome that limitation, make things more performant and scale with your app, no matter how many queries you will have.
Persistence layer will be checked whenever query mounts for the first time and resolve immediately if cached data is there.
You can control whether you want to refetch after restoring a query via refetchOnRestore or as mentioned call restoreQueries when starting the app.

I would not recommend mixing both persisters as it's kind of redundant.

You can use QueryPersister which might be a little easier to use, up to the point where you will see performance problems.
Using experimental_createQueryPersister should scale virtually infinitely, but requires more from developer. Like calling persisterGc or restoreQueries is that is required in your use-case.

[sgcullen]

@DamianOsipiuk A huge thank you again for taking the time to go into detail on this. The information you have provided is extremely helpful.

I like the experimental_createQueryPersister a lot. It has worked really really well for my needs so far so I'm minded to continue using it with the suggestion of calling restoreQueries when the content script first loads (chrome extension) to recover the cache. I'll have to test how performant this can be.

As an aside, the previous incarnation - experimental_createPersister allowed passing the persister at query level rather than QueryClient level. This seems to have changed with the experimental_createQueryPersister which for the most part is fine. I did have an instance however where passing the persister in at the query level allowed me also to pass a buster in on a per query basis (rather than busting all queries en-masse). Is there a chance that this could return?

Thanks again @DamianOsipiuk!

[DamianOsipiuk]

This should still work as before. If it's not it's most likely a bug on the type level.

Please open an issue with sample repro or a PR with the fix.