using fusion cache inside of a lib - custom configuration possibilities with default fallback

[kimpenhaus]

hi all,

I would like to use FusionCache inside a lib/sdk and wonder if it is a good idea to expose the usage of FusionCache.

What I would like to achieve is to give the developer/consumer of that lib/sdk the possibility to benefit from the full featureset of FusionCache but if he is not in need of a complex featureset (like distributed cache) have him no need to do anything and create a fallback configuration which has a memory cache (which acts more like a concurrent dictionary).

reading the docs I see that there are DI extensions following TryWith - stating TRY TO USE the one registered in the DI container. If not there, no problem but what is no problem? is there any fallback I can apply if the TryWith is kind of not successful?

or is a better approach to expose the IFusionCacheBuilder within a action - if that is nullable - provide the fallback?

what would your recommendations be?

thank you 🙏🏼

once for your input/help - which I really appreciate and of course for maintaining the mighty cache lib!

[jodydonetti]

Hi @kimpenhaus !

I would like to use FusionCache inside a lib/sdk and wonder if it is a good idea to expose the usage of FusionCache.

It depends on if you are ok in creating an explicit dependency or not.
The other way would be to create your own abstraction, but of course if the features you'd like to support are quite a bit and FusionCache is the only library that supports them, you would be creating an abstraction which is not, in fact, an abstraction at all but strictly tied to FusionCache.

What I would like to achieve is to give the developer/consumer of that lib/sdk the possibility to benefit from the full featureset of FusionCache but if he is not in need of a complex featureset (like distributed cache) have him no need to do anything and create a fallback configuration which has a memory cache (which acts more like a concurrent dictionary).

That is exactly how FusionCache works if you don't setup a distributed cache + backplane, so I would say you are on the right track there.

reading the docs I see that there are DI extensions following TryWith - stating TRY TO USE the one registered in the DI container. If not there, no problem but what is no problem? is there any fallback I can apply if the TryWith is kind of not successful?

I don't know if the phrasing can be better, but basically: if you call, for example, WithRegisteredDistributedCache(), your intent is that it MUST have the distributed cache registered in the DI container. If one is not registered, it will throw an exception.
Instead if you call TryWithRegisteredDistributedCache() your intent is to try and look in the DI container, and IF there is a distributed cache registered, it will use it.

One idea (but think about your scenario and validate it yourself, since I don't know all the details/constraints) may be for your users to be able to specify a name for a named cache. The default value for that, if not specified, can be the name of the default cache itself (FusionCacheOptions.DefaultCacheName).

In this way they can configure the cache however they want, and you can just use the name they specified and use that cache (via IFusionCacheProvider.GetCache(name)).

An additional approach may be for them to be able to directly pass an IFusionCache instance, basically not forcing them to go through DI and allowing them to just create one as they please (via new FusionCache(...)).

In this way if they don't do anything, you will use the default cache, with the default configuration, and the default experience would be an "it just works" kind of thing.

Again, these are some ideas, I would need to have more info to be more precise.

or is a better approach to expose the IFusionCacheBuilder within a action - if that is nullable - provide the fallback?

what would your recommendations be?

I would anyway NOT do the setup in your lib/sdk, since the configuration is something that they need to do, not your thing (imho, of course).

thank you 🙏🏼

once for your input/help - which I really appreciate and of course for maintaining the mighty cache lib!

Happy you are liking FusionCache, and thanks to you for participating here 🙂