Dapper, FusionCache, and Redis - The ULTIMATE CACHE Solution for ASP NET Core

One of the most popular setups that we get with ASP.NET Core when it comes to OMS in caching is going to be Entity Framework Core and Hybrid Cache. But what if you wanted to try something else? Hi, my name is Nick Cantino and I'm a principal software engineering manager at Microsoft. In this video, we're going to be looking at using Fusion Cache with Dapper instead of the alternatives. And if you haven't seen the other videos in this playlist so far, I'd recommend checking them out up here. And that way you can see how we're building and progressing and switching over between these different technologies. There's some extra context from those earlier videos that will help a lot when you're watching this one. If that sounds interesting, just a reminder, subscribe to the channel and check out that pin comment for my courses on domain. Let's jump over to Visual Studio and see how we can hook these things up. All right, in Visual Studio, I have the example application that we've been working with throughout this playlist. In the previous video, what I've done is walked through how we set up Fusion Cache, and I'll just do a quick walkthrough in this video as well. We're just going to add Fusion Cache onto the services. We have to pick a serializer that we want to work with. And that's going to be so that we can have our distributed cache, have our records being written out and read back in because we can't store them like we do in memory. We need to be able to serialize them. The next part is actually setting up Reddus. So that's why we have Reddis cache and then the options that we're using. We're just going to configure Reddus to be able to have a connection string from our app settings. So if you're not familiar with that kind of pattern, if I jump over to app settings JSON, you can see that I have a connection strings section with a Reddus connection string. So I'll jump back to program.cs. But this block here is what allows Fusion cache to leverage Reddus as well. And then I just have some default options. There are plenty of other options that you can work with, but I'm setting the cache duration to be infinite by default. Probably not recommended for most people in most situations, but that's just for this video to be able to call out that you can have some configuration changes. If you're curious for how to get all of these things, we go over to the project file. And I'll just call out what I'm going to be using for this video. Right. So, Ziggy Creatures Fusion Cache is going to be fusion cache itself. And then to be able to leverage Reddus as the back plane, we have this other package that we can leverage. So, that hooks up fusion cache to Reddus itself. And then we have to pick a serializer. Yes, there are other options like if you want to use Newtonoft or Protobuff, but I'm just using system text JSON. These three things together give us fusion cache, a reddis backplane, and a serializer of our choice. Just a quick note, you'll see some other things in here like some other Reddus dependencies. You'll see that I'm using SQLite for my database. There's some entity framework core stuff in here. Please don't worry about that. That's just from the other videos. And the other quick note is that I am using Dapper for this video. At the time of recording, I'm just using 2.1.35. It shouldn't really be a big detail for this video because the earlier videos we look at the details of Dapper. In this video, I'm just showing how we can go port over to using that repository that we've already built and leverage Fusion Cache. Before jumping into more code, I still want to give Jody Denetti a shout out for his documentation for Fusion Cache. Because if you're watching this and you're thinking about how you want to go build stuff leveraging Fusion Cache, I highly recommend you check out the docs. I'm going to jump over to the GitHub page and show you this. So, we have this awesome cute little sloth here, but the docs are written in a way that are friendly in my opinion. So, I am the kind of developer that I don't like reading documentation. And I feel like most people are probably like this, right? We just want to sit in our IDE. We want to try out the API surface that we can play with and figure things out. I don't like reading docs because it often feels like a lawyer or something wrote them and they're crappy. They're not fun to read. They're not obvious. And I still feel like I'm trying to decipher what's going on. Maybe that's just my experience, maybe not yours, but that's why I generally don't go to the docs until I've already been debugging for way too long. Probably a good indicator I shouldn't do that in the first place. But Fusion Cache, when I first started using it and I was getting stuck on some stuff, I'm like, "Okay, I'm going to try the docs out." And they're enjoyable to read. I don't think this has ever happened for me as a developer, so I can't give enough praise to Jod for this. But you can see that there's pictures for a lot of different things that he has in his documentation. Not only examples of walking through how to use the APIs, but concepts as well. So for example, cash stampede protection failsafe mechanisms. I'm just going to click on this one. You can see that he has more pictures explains the concepts and how they apply into the code as well. And I think that from my perspective like all of this is done in such a good way. And I think that if you're getting stuck on stuff, you feel like concepts aren't explained well or some of the API might be confusing how it's documented. I am sure that if you reach out to the maintainer, he would be happy to improve it because he does take a lot of pride in how this is done. Okay, enough of that. You want to see how we can go wire up Dapper with all of this stuff? And I think that's totally fair. So we have from line 10 to 20, that's how we're hooking up the fusion cache setup here with Reddus. This line here on line 9 is left over from where we were at in the previous videos. That one is setting up entity framework core with fusion cache, but instead we're going to be working with Dapper. So, if I type Dapper in here, you can see that I already made an extension method for getting us set up. Let me F12 into this and we can go see the code. And what I wanted to do is walk through why we see a little bit of a difference between this fusion cache decorator and the hybrid cache decorator. The two biggest differences you'll notice between these two are that I have on line 26 we are using a hybrid cache and on line 35 we're using fusion cache. What these two methods do, just for a little bit more context, is that we are setting up a decorator around the repository that we're working with. What that means is that we're using a Dapper repository, but when we go to ask for an I repository, we're saying, wait a second, don't just give me the base Dapper one. We want to have a caching repository that's wrapping it. It's a decorator pattern. That's what it does. But the other big difference between these two, you can see on line 23 and 24, it says hybrid caching repository. But if we go to the other method on 32 and 33, we see fusion cache repository. So why do we have another whole repository? Well, this was called out in the previous video when we did this exact same thing for entity framework core. The reason why is fusion cache and hybrid cache do have slightly different APIs in terms of their naming convention. The fusion cache code does not implement hybrid cache. So, it's not a direct dropin. But I will make a follow-up video where I can explain how we can actually leverage hybrid cache and having fusion cache as a direct implementation of it. And that means that we don't need to go make a whole new fusion cache repository. We can just use the hybrid caching one. A quick note, I've already explained this in the previous video. If I jump into fusion cache repository, I just want to explain this very briefly. We can see that the decorator takes in the base repository. We can see that the fusion cache repository is going to be the caching implementation. But when we go to look at some of these other methods, if you compare the two decorators that we have, the one for hybrid, the one for fusion, they're almost identical. Slight differences on get or set async in terms of naming and some of the other small details are that we have some other parameters that are optional for things like set async and the cancellation token as a named parameter is not called cancellation token. So I actually have to go in and provide token as the name. But honestly that's the biggest difference between the two. If I jump between them and compare them like I did in the previous video, you'll see that they look almost identical, just different API surfaces. With that said though, if we look at our program.cs, we have all the pieces we need. We set up Dapper in terms of our repository and then that's decorated with a caching repository that's going to be using Fusion cache. And then this code here sets up Fusion Cache with the serializer and Reddus as the back plane. So let's go ahead and run this and see what we get. The application is running and the next thing we have to do is set up Reddus as well. So I'm just going to go start a new container here on the optional settings. I'm just going to use the default port for Reddus as well. So you need to have your host port mapped to what's in the container for Reddus. And just like that, we have Reddus up and running. If you're not sure how to do this, you can check out this video up here. And that way you can see how you can get a Docker instance set up and running. It's only a few minutes to get everything you need. Now we have that. We have the application running. Let's go hit the APIs. Okay, our API is kind of silly. I'm just going to be saying I want to do a get and provide the ID for a record. This is from a previous run. So dev leader should come back. But let's pay special attention to what's happening in the console. If I press enter, you can see that fusion cache had a couple of log lines here and then we had the entry come back. So, it is working as expected because it's fetching this every time. Very interesting. If you've watched the other video with Entity Framework Core, we can see that it's going to the database because Entity Framework Core is actually logging that information out. Dapper is not logging that information. It's why I wanted to start with Entity Framework Core in the previous video so you can see when it's actually doing the database activity. I could go put some log lines in as well, but I just wanted to show you how we can wire this kind of stuff up. So, the other thing that we can do now is because you might be saying, "Well, Nick, you can do this already with a memory cache. What did Reddus have to do with any of this?" We saw in the previous video the same thing when we're using Entity Framework Core. Let me kill this off because if we only had a memory cache, it would mean that we are not able to go launch a new instance of this and have things read from cache. We would have to go to the database. So let's actually prove if we're doing that. I'm going to go into our code. I'm going to go into Dapper. I'm going to go into the Dapper repository. I'm going to put a breakpoint on line 22 to be able to get something. Okay, I'm going to put that there. We're not doing get all. We're not doing create, update, or delete. Just on the get line. If I go run this now and we go to ask for a record, what we would expect is that if we only had a memory cache, we would have to go fetch this from the database again. But because we have Reddus up and running and that was our back plane, we should be able to go fetch this information from Reddus and that way we don't have to go to the database. That's the entire point of the L2 cache. But one more thing is I'll put a break point here on line 15. I'm going to go ahead and run this. We should see that we have the Dapper repository get created. That way you know I'm at least using it. Not trying to fool anyone. So the application's up and running. Let's go ahead and ask for this record. Just to prove it as well, I have not stopped Reddus. It is still going. Let's go ahead and get this record. We go and create the Dapper repository. But notice we didn't hit line 22 to go get it. And we had this information in the browser. And we can see that Fusion Cache was doing all of its verbose logging, which you can dial down. In production, it's a lot of logging. Don't recommend it. This all worked as expected. If I keep trying to get it, it is never going to the database. So, in this video, we got to see how we can change our extension methods to be able to set up a new decorator repository for Dapper. All that we had to do was go to line 9 here and swap out which OM we're using. So we switched over from Entity Framework Core to Dapper. We kept all of this the same to be able to set up Fusion Cache with Reddus. That way we had all of this code which is our actual API surface for the web API that remained untouched. That's one of the benefits you can get when you're using decorators with repositories. We can just swap out all of this stuff. So, kind of interesting. But like I said earlier in the video, if you're like, I want to know how I can use hybrid cache with fusion cache and not have to go make a whole new decorator, well, you can check out this video next when it's uploaded. Thanks, and I'll see you next time.