Closed Philip-NLnetLabs closed 5 months ago
A thought:
Would it be worth making the cache get and insert interface a trait taken by the cache client, and making the current in memory moka cache one impl of it?
Then the same client could be used with an alternate backing cache impl.
This occurred to me because of a similar discussion about zone storage.
To fully support less local stores the interface would need to support async function calls I expect, but IIRC the moka cache is also used via an async interface.
That would also be a way to enable users to wrap the cache calls to gather usage metrics/statistics if that's what they need, without impacting performance when not wanting them.
One thing not provided by this PR at present is any notion of cache metrics/statistics. I also don't see any obvious support on the underlying moka crate for this, so presumably one would have to wrap internal calls in
cache.rs
to track the miss/hit ratio, for example. I don't see how the user of the cache in this crate could do this themselves without forking the code as thecache.get()
call is deep inside library code, so users of this library would have to wait for us to add such support later or PR it themselves.