[API Proposal]: HybridCache - should a HC-backed IDistributedCache be offered? #5539
Labels
api-suggestion
Early API idea and discussion, it is NOT ready for implementation
area-caching-hybrid
untriaged
Background and motivation
Currently,
HybridCache
optionally consumesIDistributedCache
(andIBufferDistributedCache
via type-testing) as the L2 backend, typically for out-of-process/off-box storage (Redis etc).A lot of existing code consumes
IDistributedCache
, and while in a perfect world they would migrate toHybridCache
, we do not live in a perfect world, so there is a question as to whether it may be useful to optionally offer anIDistributedCache
that is, effectively, a L1+L2 wrapper.Considerations
IDistributedCache
backend); if you only want L1, there is alreadyAddDistributedMemoryCache
which does exactly thatIDistributedCache
backend from the exposed backend - this could be either via keyed-DI, or via explicit configuration against theHybridCacheOptions
AddStackExchangeRedisCache
only works on the default DI; maybe one option there is for the new exposed DI to be keyed?IDistributedCache
has separate get/put APIs - this is manageable, howeverbyte[]
copies when usingIDistributedCache
, but that doesn't present a significant change - that is already expectedIBufferDistributedCache
(and we should do so), although should not expect massive usage; the entire point of things likeHybridCache
is to make that a non-concern for application codeUsage example
(entirely speculative and open to discussion)
with the change to existing usage consisting of:
The downside of this is that it still requires per-usage changes, but that may be desirable anyway, to ensure the usage is fully considered.
Questions
IDistributedCache
uses, that works better?typeof(HybridCache)
if not specified, or is that silly?The text was updated successfully, but these errors were encountered: