Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configurable Cache Options and Cache Keys on a per Request Basis #25

Open
veeshi opened this issue Jun 28, 2023 · 8 comments
Open

Configurable Cache Options and Cache Keys on a per Request Basis #25

veeshi opened this issue Jun 28, 2023 · 8 comments

Comments

@veeshi
Copy link
Contributor

veeshi commented Jun 28, 2023

For my current usage of this library it would be great if we could:

  • configure the cache keys when initialising
  • override the cache options on a per request basis
  • override the cache keys on a per request basis

Happy to propose a PR and thank you for this amazing crate!

@06chaynes
Copy link
Owner

Thanks! Glad you found it useful. I'm not against adding something like this, do you have something in mind as far as what the implementation might look like?

@veeshi
Copy link
Contributor Author

veeshi commented Jun 28, 2023

For the customisable cache key I'm thinking of adding another field to CacheOptions called cache_key and it is a closure that takes the request and returns the cache key as a String.

With regards to overriding the cache options on a per request basis, I haven't dug much in to it, but the only way I can think of doing this is with a trait implemented for ClientWithMiddleware with a function which takes CacheOptions and creates a task_local_extensions::Extensions with the CacheOptions and then calls ClientWithMiddleware::execute_with_extensions with them.

@06chaynes
Copy link
Owner

Think I generally understand what this might look like, would you care to provide a high level overview of the use case for this just so I understand better?

CacheOptions belongs to the http_cache_semantics crate, so we would need to add a new field HttpCache struct or maybe create a new options struct that can contain this CacheOptions, cache_key, and any possible future options.

@veeshi
Copy link
Contributor Author

veeshi commented Jun 29, 2023

It's essentially a HTTP proxy which allows configuration for different routes.

Ah I didn't realise it was a re-export, just seen the note in the main http-cache crate!

I think an addition of another struct to the HttpCache struct wrapping the CacheOptions and cache_key seems ideal and future proof but it is a breaking change. I'll try to draft something up this weekend on the customisable cache_key first.

@06chaynes
Copy link
Owner

Sounds good!

@06chaynes
Copy link
Owner

Published new versions of the crates today with the custom cache key changes, thanks for your patience on this!

@veeshi
Copy link
Contributor Author

veeshi commented Oct 21, 2023

I've seen the cache modes added and it would be nice if that could be modified on a per request basis. The use case is we only want to cache certain content types. The idea is to to add a closure in an option which if it exists it can be used to check the request and return an updated cache mode for instances where we want to either bypass the cache or use the cache with the default rules. I'll try knocking up a PR with this.

@06chaynes
Copy link
Owner

Looks great, just merged into develop. Thanks again for your contributions!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants