Response Caching in .NET World
Definition
This middleware — “Enables caching server responses based on HTTP cache headers” (definition taken from Microsoft doc).
If you didn’t understand a thing, and you think the MS doc is too long, TLDR: this thing is responsible for caching responses to reduce the load on the server so, you get an improved performance.
Benefits?
As already said, improved performance. Why? Simple! The identical requests get directly served from the cache, without using any “computation power” (speed speed speed)!
About reducing the load on a service again we already mentioned, but what is the next best thing, is that, if you are using serverless, or paying per time usage, or for CPU, well, you’ll need to pay way less, especially if your app is used mostly for reading.
From the security point of view, even if it’s a long shot, we can say we make DDoS harder since we respond so fast, and our server is not usually working (no heavy load).
Another long shot would be SEO. Since your pages will load much faster, users will be more happy and the search engines will place your app higher on their pages. You’ll get a bigger score for free
Cons?
- Cache invalidation. This is an all-known problem for any caching, and here is nothing different. If your application frequently updates data or if the data is time-sensitive, you need a robust strategy for cache invalidation.
- Increased Memory Usage. The cache is in memory at the end. If you want to increase performance and reduce costs, take care of this because if you don't pay attention you’ll end up with scaling problems due to memory usage and get even higher costs than you had before.
- Cache Coherency. If you are living in a distributed systems world, and use something like Redis, you’ll need to ensure that cached responses remain consistent across all instances of your application.
- Potential Security Risks. If you cache sensitive data, it’s pretty clear that they need to be secured. If you don’t do it and your data gets exposed…
- Complexity and Overhead. Being another layer of complexity it will add some overhead to your app. You might encounter even some bugs and debugging might not be so nice. In the end, it’s normal, more code, more potential problems.
Where to use it?
In my mind, since it’s something that is used for GET and HEAD, any website/app that has more reads than writes fits very well on the example list of this middleware. If you want a real-world example, let’s think about a news website or a blog.
Conclusion
I won’t create a git example, since there are already a lot of them on this vast internet. I already gave you the URL for MS documentation in which you have everything you need anyway.
My opinion is that this is a “need to have” thing in your “toolbox”, but as with any other middleware, add them only if you need it.
