HybridCache API

[sbwalker]

Description

In the description for HybridCache it says that it "bridges some gaps in the existing IDistributedCache and IMemoryCache APIs". However it also seems to create some new gaps - especially for existing applications which want to use the new HybridCache capability.

What I am referring is that both IDistributedCache and IMemoryCache APIs provided synchronous methods for interacting with the cache:

https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.caching.distributed.idistributedcache?view=net-9.0-pp
https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.caching.memory.imemorycache?view=net-9.0-pp

Based on the public messaging, HybridCache is being positioned as a "drop-in replacement" for IDistributedCache and IMemoryCache. However if an application is utilizing the synchronous methods of either of these APIs, then it is not a "drop-in replacement" to use HybridCache in its current form - it may actually require significant refactoring of your application to conform to the asynchronous approach (which may not even be feasible if you have downstream consumers depending on your synchronous APIs). This could severely limit adoption for the new HybridCache... as faced with a large-scale refactoring effort, developers may decide to stay on the older IDistributedCache or IMemoryCache options.

I have reviewed the design discussions on GitHub related to HybridCache and I am surprised that this "gap" in functionality was not raised previously. Perhaps the problem was that the community was only thinking about HybridCache in a theoretical sense and not considering how they would integrate it into their existing applications. Regardless, there are a few comments about the current API approach on GitHub:

“The fact that we're caching means we can reasonably assume this operation will be non-trivial, and possibly one or both of an an out-of-process backend store call (with non-trivial payload) and an underlying data fetch (with non-trivial total time); async is strongly desirable.”

“Intentionally not providing sync API because why are you caching if it's fast enough to do inline?”

These are both valid comments. And if someone was building a new green-field application then absolutely it makes sense that they should use an asynchronous approach. But for existing .NET Core applications, many are still using synchronous patterns.

For example if we consider this very simple caching pattern wrapping an EF Core repository method using IMemoryCache:

        public IEnumerable<Alias> GetAliases()
        {
            return _cache.GetOrCreate("aliases", entry =>
            {
                entry.SlidingExpiration = TimeSpan.FromMinutes(30);
                return _db.Alias.ToList();
            });
        }

HybridCache does not provide a GetOrCreate() synchronous method... which means that the GetAlias() method would need to be refactored to be async... and any consumers of this method would also need to become async... which produces a very disruptive ripple effect when the original goal was simply to use HybridCache.

I do understand that one of Microsoft's goals is to prevent developers from "shooting themselves in the foot". And allowing a developer to use a synchronous cache method to wrap a call to an out-of-process backend store could definitely lead to scalability or performance problems in some scenarios. However, completely removing this capability has other ramifications - especially for migrating existing applications.

@mgravell Since HybridCache is currently still in preview and is expected to be officially released in a future minor release of .NET Extensions, would it be possible to consider expanding the API to include some synchronous methods to fill these gaps and allow it to truly be a "drop in replacement" for IDistributedCache and IMemoryCache?

Reproduction Steps

Attempt to integrate HybridCache into an existing application where synchronous cache methods are being used from IDistributedCache or IMemoryCache

Expected behavior

HybridCache API should have synchronous methods equivalent to IDistributedCache and IMemoryCache

Actual behavior

Requires significant refactoring of existing code in order to integrate HybridCache - which is not even feasible in some cases

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

[jodydonetti]

I think the implementation is in preview (part of Microsoft.Extensions), while the abstraction is already final (part of .NET 9), but maybe I'm wrong.

Meanwhile you can take a look at FusionCache which supports sync+async (shameless plug).

Hope this helps.