I like it when they add things to .Net that ARE actually useful instead of just pretty.

we've spent quite some time to kind of build those features on top of IDistributedCache so I am glad it is now a built in feature. no idea why it is a class tough...

Looks great, but I _really_ dislike the magic registration, when HybridCache detects automatically what type of distributed cache is registered. If you know, sure, easy, however if you find yourself in a project without that knowledge, there is "no breadcrumb" to lead you on to what is really happening. Feels like unnecessary bar rising for less experienced developers or less lucky to be around when this feature is being advertised... Still, looking forward to take it for a spin :)

This is the best ever thing Microsoft has released in the past 2 years. Only if this was released like 6 months ago when I needed something similar. Was a pain in the ... to build this kind functionality

This is amazing, just what I needed!

It's cloudy, what a surprise

They should just bring over fusion cache. Tagging is a nice feature.

Awesome video! Thanks for that!

FYI, the library LazyCache does the same as HybridCache. Better to use HybridCache going forward but wanted to set the record straight that this functionality has been available for years.

That's actually quite nice. I think that's going to be a very useful tool in the future to consider.

Nice feature! I am currently using the NuGet package LazyCache instead of the plain memory cache, primarily for the Stampede-protection but also for a feature that immediatly evicts items from the cache on expiration. Is that something HybridCache supports?

Awesome feature and video, thank you! The only downside that it's in .NET 9 and not earlier :)

thanks

love it!

Very nice!

Does the HybridCache support just returning the last cached value while the cache is being updated? That behavior is really handy for performance critical services like whisperers where you don't want to unnecessarily block multiple clients when the cache is stale.

@james-not-jim

28 күн бұрын

That behaviour is called "stale-while-revalidate". I wish it were the default (or at least a built-in option) for more caching frameworks.

@MarcGravell

27 күн бұрын

Hi; this is on the roadmap, but is unlikely to ship in time for .NET 9; since HybridCache ships OOB, we have some options to expand this between releases source: me (I'm the lead for Hybrid Cache)

@Paul-uo9sv

5 күн бұрын

​​@@MarcGravell let's get a move on it, chop chop... Jp

I think that's an awesome one! Looking into the docs/options, it's not clear to me whether it behaves in a multi-layer manner, or whether it is an option that you can switch on. I.e., if I want the cache to first try to grab a value from the local (IMemoryCache) cache, and then if not found - go to the shared (IDistributed) one, and once found or refreshed - update the local cache entry back. I used to build something like this to reduce some redis calls. Of course this comes with a cost of extra delay for the updated value to get it to the consumers, however, if configured the TTL properly for both shared and local caches, might be worth it for some scenarios. So, is this now achievable out-of-the-box with the new HybridCache thing?

Very interesting

IMHO: HybridCache looks like the way moving forward, but please also mark IMemoryCache and IDistributedCache [Obsolete] and whatever jargon made into BCL with .NET 9 Release and completely remove both of these APIs in .NET 10. The BCL Team may consider using the [Obsolete] attribute more aggressively between alternating .NET Releases - keep the BCL clean and tidy. PLEASE!!!

@joost00719

27 күн бұрын

Well, is it actually obsolete? Perhaps the HybridCache uses both those interfaces behind the scenes.

@MarcGravell

27 күн бұрын

@@joost00719 It literally does; IDistributedCache is the out-of-process L2 backend for HybridCache, and IMemoryCache is the in-process L1 endpoint; source: me

@ahmedabuelnour1648

27 күн бұрын

@@joost00719 It is actually using them

Ok, HybridCache seems like a good addition to the collection of cache implementations. But one thing that I don't like about it is that it don't have a factory solution where I can specify a cache create / refresh method centrally. Much like the IConfiguration provider solution. The problem arises when I want to reuse the same cached value in multiple places. I then have to specify the factory in multiple places...

making it thread safe is really nice, one thing I'm concerned about here is bugs introduced by the duality usage option. for example if somehow you didn't register the redis cache you won't know about it until the memory leak start to happen or cache miss in case of multiple instances. it would be nice if there is a way to make it a requirement for redis cache to be registered in some cases. I know you can do this manually but it would be nice if it can be implemented in the options setup in AddHybridCache directly.

@gileee

27 күн бұрын

Implicitly autowiring objects like these is the reason I dislike working with SpringBoot. Although it's worse there because everyone fully leans into it and you have something 20 layers of nested beans all automatically checking if others have been registered and changing their behavior based on that. It's a nightmare to know exactly what's going on in your application. Also god forbid you wanna change something, because you'll be overriding 5 different abstract classes.

I think Microsoft has a long way to go with Hybrid caches. But yet, its a very nice start. Basically, what hybrid cache is, it will leverage both in-memory and distributed cache at the same time but in a way that the request does not have to travel to the distributed cache in order to reduce latency. The idea is, at the time of storing a record, it will store the data into the in-memory cache and send a message asynchronously to any kind of bus (i.e. redis bus) indicating that a WeatherCached event has occurred. And on the other side, the same instance will subscribe to that event and store that data into the distributed cache. if other instances of the same app/different microservice/a different module that is consuming that same event from the same channel will store it in their own in-memory cache. this way Hybrid Caching helps us leveraging both in-memory cache and distributed cache at the same time and the incoming requests to web/api server do not need to travel over the network to get the data because its already available in-memory.

As I understand it doesn't lock across multiple instances. In case of multiple instances making the same call all of the instances will make the same call to the weather API. So if you have 10 instances of the same service and a very loaded environment there still might be several simultaneous calls.

@davidmartensson273

25 күн бұрын

Was going to ask the same but I understand why, we did implement something with distributed locking also and it was quite complex and requires a real distributed locking solution, which redis does not really have out of the box and then you have to make a lot of more decisions on exactly where your prepared to take a penalty, redundant external calls or slower updates due to failed calls and retries. And in most cases you only have a few instances and 3-4 extra calls once every 5 minutes or so is not going to be a big problem. If it is, then you have to bite the bullet and roll your own. And if you have som many instances that that becomes a problem, then you most likely already have some distributed locking :)

Can you clarify? If a different request for weather comes in... does it still block? Or is the blocking purely based upon the cache key?

Can you do a video about how to debug applications that run on docker/kubernetis?

One more solution with implicit dependency. There is no declaration that says - HybridCache functionality depends on Redis. MS need to change this as it done in many cases already.

@gt10i

28 күн бұрын

I agree. Avoiding lots of setup code is nice, but it should not be abstracted to the point where things become magic, and you just have to "know" about it. Would have preferred if there was an explicit statement "use Redis" while setting up HybridCache.

@MarcGravell

27 күн бұрын

because HybridCache *does not* depend on Redis - it optionally uses IDistributedCache as an L2 backend; HybridCache will work with any implementation - Redis, SQL Server, NCache, CosmosDB, etc source: me

1) Synchronization of requests for any memory cache can be handled easily by inserting a Lazy. The Lazy minimizes (or even eliminates) the chance of opportunistic concurrency, and the Task is the actual request that gets made and shared. Sure, you have to do some smart eviction if either of those fail, but IMO, I think this kind of operation should have be built in to (or provided as an extension) any memory cache. 2) I would always have a short term expiry in memory cache for anything that is cache-able. Ideally tuned with a short term sliding expiry that still honors an absolute. Then of course, the distributed cache API would be the next layer that the in memory cache calls to. 3) Either way, each cache layer should have an option to use pessimistic concurrency. AKA "stampede protection" should be an option for both, and IMO, its should be the default.

@gunnarliljas8459

28 күн бұрын

1) Sure, could work, but only in a GetOrAdd scenario, where immediate invocation of the Lazy is guaranteed. 2) Yes, we have that, with an option to have in memory cache invalidation using Redis PubSub.

its a christmas miracle!

🎯 Key Takeaways for quick navigation: 00:00 *🌐 Introduction to Caching in .NET 9* - Explanation of the need to replace the ID distributed cache interface - Introduction to the new caching mechanism in .NET 9 - Comparison between the in-memory cache and the new caching mechanism 05:15 *🔍 Issues with Existing Caching Methods* - Challenges with stampedes in caching operations - Limitations of the ID distributed cache interface - Lack of features like tag-based eviction and instrumentation in current caching methods 08:27 *💡 Introduction to Hybrid Cache in .NET 9* - Overview of the new Hybrid Cache introduced in .NET 9 - Benefits of using the Hybrid Cache over the ID distributed cache and in-memory cache - Simplification of caching operations with the Hybrid Cache solution Made with HARPA AI

I was dealing with this problem last week. Excited for .net 10 when I can use it lol

FINALLY THEY ADDED A TAG TO CACHE ITEMS, GOD BLESS YOU MICROSOFT

@MarcGravell

27 күн бұрын

caveat: tag-based eviction didn't make it into preview 4 (or 5); we have the design etc, and are working on it

How is this multi-call protection works? So if I call for weather of London twice, the second call is waiting. But if I call with othe city, do both calls go through to the openweather server?

My issue here is that we are cache:ing null for N minutes if we get a bad-request... but assuming you handle that, I think this new cache could be very helpful - especially with db-lookups or external API-calls

Since IMemoryCache came out I've been wishing they just had an ICache type with MemoryCache and DistributedCache implementations (and now HybridCache). Would have been a lot cleaner and simpler that way.

I noticed with Azure things (ServiceBusClient, BlobContainerClient, etc) that they greatly prefer abstract classes or even just plain classes with virtual methods to interfaces. Seems like they want to do unit testing in a more Java like manner where you just mock classes directly.

@powerclan1910

28 күн бұрын

there is also a big difference in how method resolution works for interfaces vs abstract classes. with interfaces you use the general purpose methods, whereas with abstract classes, method resolution happens (which takes time!) to be able to run the more specific optimized method. In this case the methods aren't just optimized, but they are just completely different implementations. (example of the interface behavior is LINQ using slower methods on IEnumerable vs IList even though the instance is the same List)

@Robert-yw5ms

28 күн бұрын

@@powerclan1910 I suppose if you're doing IO then the extra execution time is unlikely to really matter

Does in have "automatic" population after some time like old .NET frameworks MemoryCache had with its callbacks?

I hate to use the C word, caching has usually just caused me pain but maybe I will finally have to concede now that I am building something with genuine millisecond speed implications. BTW this works especially well with multiple pods where you don't want to worry about each pod having totally different speeds! Great video as I am getting into k8s ❤

@alexandermackintosh1755

27 күн бұрын

especially now when I need to constantly take static bond/futures data from other parts of the company where it barely changes!!

Syntactic sugar for ConcurrentDictionary. Nice!

Will it use in-memory if the distributed cache fails?

Did they just embrace, extend and extinguish FusionCache? 😂

@HHJ79

28 күн бұрын

The maintainer of FusionCache is actively participating in the design discussions regarding HybridCache.

@allinvanguard

28 күн бұрын

@@HHJ79 That's great to know - This hasn't always happened with previous things embedded in the Framework. But in that case I'm very happy to see it embraced.

@jodydonetti

28 күн бұрын

FusionCache creator here: eh, I hear you, you’re not the first one to tell me that 😅 I’m sharing my experiences and design ideas with the team, and they are listening! I even suggested the name HybridCache, the previous name was not that clear imho (naming is hard). I hope the two will be able to work together in the end, with HybridCache as a potential shared abstraction.

@Sam-ey1nn

27 күн бұрын

@@jodydonetti Awesome to hear you are working with MS on this. The work you've done on FusionCache is incredible!

@jodydonetti

26 күн бұрын

@@Sam-ey1nnto be fair I’m not actively “working” on it, the team is doing the work and I’m having some conversations, throw ideas, playing with the first bits, giving design suggestions and so on. And they are listening, so kudos to them!

I manually implemented something similar to HybridCache, but it was impossible to do proper Cache Invalidation. You can clear the distributed cache, you can clear the current instance's local cache, but you can't clear a different instance's local cache. This meant we had to use a plain distributed cache if the use case required cache invalidation. Fortunately most use cases don't need it.

@Albi91vl

28 күн бұрын

But this doesn't cache locally (if distributed is used) from what I understood. The name comes from the fact that uses local cache or distributed cache with the same interface. I think it just uses distributed locks for a specific resource (key) and interacts with the distributed cache back and forth multiple times for acquiring the lock for the specific resource and then changing the resource and then releasing the lock. The lock itself is an entry in Redis with the resource id as key and the unique instance id as value.

@KerchumA222

28 күн бұрын

you can implement distributed invalidation using pub/sub or similar. I like the idea of tiered caching as long as there are sane defaults and plenty of options to customize when needed.

@jodydonetti

28 күн бұрын

Take a look at FusionCache, it does that already (shameless plug)

@MarcGravell

27 күн бұрын

The roadmap for HybridCache includes active cache invalidation, for example use redis notifications; it didn't make it into preview 4, but I hope to ship it in time for .NET 9; with that, you get indirect cache invalidation of other nodes via the shared L2 source: me

Have redis changed their license and no longer open source? If so what are some good alternatives?

Is this code avaiable on github?

That's weird, I don't see any course abut Azure stuff like cosmos db or azure function or blob storage or azure DevOps in dometrain , I will be happy if you add them , thanks

Btw, could you make a video on Garnet?

@Kingside88

28 күн бұрын

Never heard of. But looks great. Thank you

@nickchapsas

28 күн бұрын

It's coming

@MarcGravell

27 күн бұрын

@@nickchapsas fun observations: 1) preview 4 *also* includes the code-changes to make IDistributedCache work with Garnet, and 2) I have an experimental hack which implements IDistributedCache on the Garnet storage core *without* actually going through any of the redis layer, intended for in-process disk-based local node caching (for cold-start or larger-than-RAM scenarios)

What happen if, during the GetCreate cache, the API request fails? Will it caches the bad response or will it ignores it? I think this is quite common case, where normally you would end up with all incoming requests receive cached bad response

@MarcGravell

27 күн бұрын

at the moment: all in-flight shared calls (from the stampede protection) will get the failure; new calls will retry; if you want a cached failure, my suggestion is for the thing you cache to be a "result or failure" object, i.e. you have a "catch" in your fetch code that returns a similar API signifying failure

Yay I can get ride of all the semaphoreslims

Confused .NET 9 preview 4 is available at the moment, how can you be using .NET 9 preview 5?

Does this work if you hit multiple instances of the application? or would each of them run the request to the weather api?

@nickchapsas

28 күн бұрын

If you add the distributed cache it will use that for every app

@Petoj87

28 күн бұрын

@@nickchapsas that I understand, but my question was more about if the flood protection would synchronize between multiple instances of the application or if there is a small window where multiple requests could go off (one per instance)

@MarcGravell

27 күн бұрын

@@Petoj87 at the moment the stampede protection is per-node; centralized stamped (distributed locking) is a future possibility, but is unlikely to make it into .NET 9 (because: timing)

@Petoj87

27 күн бұрын

@@MarcGravell thanks!

I wonder if they made the HybridCache an abstract class for the same reasons they're recommending you use collection classes for performance. You see that more and more. If that is the case I would agree with it being an abstract class. Too bad indeed they made another package. I hope they remove IMemoryCache to prevent any confusion. Seems like a simple upgrade tool could fix this easily when going from .NET 8 to 9. They should promote the tool for that more.

@jodydonetti

28 күн бұрын

Nope, they are doing it because the idea is that it can become a shared abstraction that other libs can implement (like FusionCache), like a lingua franca: because of that, evolving the design with an interface would lead to breaking changes, whereas with an abstract class you don’t have this problem.

Anyone knows what is the Nick's preferred Redis interface over IDistributedCache?

@nickchapsas

25 күн бұрын

IConnectionMultiplexer

12:00 Distributed cache*

Why did they choose to make it an abstract class instead of interface?

@rafamodd

28 күн бұрын

Is almost the same, the benefitial is that in an abstract class you can opt to override implementations instead of extending an "option or builder" class that you then have to override implementation

@jodydonetti

28 күн бұрын

To ease evolvability in the future: with interfaces they can’t add new stuff without breaking existing implementations, whereas with an abstract class they can provide a default implementation.

@iamprovidence-xj5wf

27 күн бұрын

@@jodydonetti You can also have default implementation in the interfaces though

@jodydonetti

27 күн бұрын

@@iamprovidence-xj5wf yes, kinda, but less powerful and more fragile. They touched on this in the gh issue, maybe there are more details there about the full rationale, I don’t remember right now. To me personally, as an implementer (the only one for now?) of the abstract class it does not make much difference honestly.

@iamprovidence-xj5wf

27 күн бұрын

@@jodydonetti I mean, it is Microsoft afterall. they have discussed and justified the design with all the experts they have😒. It's just that making this shift from interfaces to abstract classes is what mentally difficult for me😅

RemoveByTag distributed is killer, finally.

Don't like the abstract approach. The benefit of an interface is simply that you choose how to implement all methods; in an abstract class there might be additional methods you can't overwrite or there are constructors expecting something. So there is clear drawbacks but I can't imagine any real benefits (I think even the calling speed of interface methods and v-calls is the same). What I really never like about IMemoryCache is that there's basically no namespace. Tags are a nice workaround for cleanup but it doesn't solve the $"{namespace}:{id}" issue.

Why isn't there a Get method. What should I do to just check is something in cache?

@jodydonetti

28 күн бұрын

That has been left out from preview 4, will probably be in preview 5.

This is interesting. But can you make sure that all the code is shown on the screen. Some of it was cut off.

Where can I find the source code for this video DEMO? Thank you.

So this in NET9 is replacing the "Microsoft.Extensions.Caching.Memory" ?

Can we get this somehow in .net 8 too?

@MarcGravell

27 күн бұрын

yes, in fact it should work today with the binaries from .NET 9 Preview 4; Hybrid Cache includes down-level support for older TFMs

A lack of common interface seemed weird to me, having a fake distributed cache for testing was odd.

I use IOutputCache with an extensions to support redis, so in this scenario between hybrid and ioutputcache you can go either way, however i heavly tested the ioutputcatch and seems to be pretty fast too!

@MarcGravell

27 күн бұрын

something that occurred to me (I'm the lead for Hybrid Cache and did the redis-based IOutputCache implementation): once tag-based eviction and active invalidation is complete in Hybrid Cache, it would actually be possible to implement IOutputCache's backend *on top of* Hybrid Cache, giving output cache support for all IDistrubutedCache implementations

I don't know who has built this framework, congratulations and thanks 👍

This is why you shouldn't directly code to the M$ interfaces. You should always wrap them within your own interface and call the MS implementation from your own implementation so you can swap them out at will without changing your client code.

I like this video because it's flaming London

@I_am_who_I_am_who_I_am

28 күн бұрын

Ever since I started working with colleagues from UK the weather in my town is all the time cloudy and slightly raining throughout the year. I think I should quit the job to save others from this misery. 😂

I want to use Ai chatbots and see which ones are best for .Net? like problem solving, code analysis ect

I don't get how this is new tech, thats nothing new. I'm using 2 tiered cache including proper event driven cache invalidation for 10+ years in .NET. It is great they finally include something like this into their caching abstraction, but new tech? Bro, na, not even close :p Also, you suggest that everyone should replace the IDistributedCache interface with this feature? That's risky. Unless you know exactly what you are doing and why you need it, don't. Caching this way is more complex and has other challenges, so if you have to rely on cache validity and never expect stale data, don't use this ever. If you do not know what I'm talking about, don't use it either.

Cloudy in London... Who would have thought?

@B1aQQ

28 күн бұрын

London weather can be cached for 20 hours without a loss of accuracy.

Oh caching...

Microsoft named a built-in cache extension after a specific company, StackExchange? Very unusual.

@MarcGravell

27 күн бұрын

firstly: this is technically OOB, not built-in; but that is moot; the Microsoft.Extensions.Caching.StackExchangeRedis package is named for the library that it uses: "StackExchange.Redis"; could it / should it have been named M.E.C.Redis instead? maybe, but that ship has sailed ironically, StackExchange.Redis is now maintained not by Stack Exchange, but by 2 ex-Stack Exchange employees (me and Nick), and by someone from Azure Redis (Philo); so that's 3 Microsoft employees ;p But it is basically impossible to rename the library, because: breakage

@chris-pee

26 күн бұрын

They named it after an implementation of a redis client, the best one in the .NET world.

@CharlesBurnsPrime

17 күн бұрын

@@chris-pee That makes sense. Thank you.

I'm the one who always looks for js framework alternatives, basically i don't like blazor because it has over engineering and it's not compatible for MCV, MVC which is real flex of web development, really looking forward hydro

well then, how I do I know MS didn't steal my code from Github?

MS SHOULD SLOW DOWN WITH NEW .NET VERSIONS!! EVERY 2 WEEKS NEW VERSIO