Giters

logaretm / villus

🏎 A tiny and fast GraphQL client for Vue.js

Home Page:https://villus.dev

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Add cache eviction with tags

dcarniel opened this issue · comments

commented

The cache feature is nice but lack a major element: an eviction mecanism.

There isn't much that can be done to link mutation and impacted queries in graphQL (I mean generic, without knowledge of the API).

Though I thought there might be a simple solution to cover most case: passing tags to queries and mutation, the cache would store the tags to which a query is linked and when a mutation is executed, the cache entries for the corresponding tags would be deleted.

What do you think ? Does it sound applicable ? I'd be happy to contribute if you think this is sensible.

Regards,
Denis

commented

Thanks for the suggestion. I realize having no way to clear the cache isn't really useful.

I think villus should be kept simple, so having tags could complicate things but feel free to post how the API would look like here in this issue (as an RFC) and I will be happy to check it and bounce a few ideas.

Mainly I'm interested in:

  • How would you tag a query
  • How would you tell a mutation to clear those tags

I also imagine having a manual clearing mechanism is also useful.

commented

Hi,

My current idea is fairly simple:

  • Add a cache_tags attribute to a query options which would link the result of this query to those tags, is the query succeeds and cache entry is created, it should be "linked" which each provided tag.
  • Add an evict_cache_tags attribute to a mutation options, if the mutation is successful all the cache entries that are related with the provided tags are deleted (forcing a network access next time). That process could even be asynchronous.

As I see it, a map structure linking tags with relevant cache entries should do the trick and might not be overkill.

As an example, you could execute a query that requests a list of items with a items_all tag, it could be pulled from the cache as usual. Then you tag all mutations related to items with the same, effectively forcing the list to be reloaded if any mutation is made.

Does it sound like a reasonable idea to you ? Of course the granularity of tags and their use would really depend on the application and that still is limited to a single-client scenario as it is today.

Denis

NB: Thinking about it it would be possible to leverage existing caching libs (which might bring TTL too), though it would still be relevant to have some kind of cache_option placeholder for the application to provide directives to the cache implementation.

commented

This took longer than it should, your suggestion is implemented in #184. Just finalizing some last API naming and docs. Many thanks.

commented

Great to see the idea was deemed useful. Looking forward to play with it.