Throttling actions in .Net Core 2.1 using AttributeFilter

I have previously written about Throttling in the pre-core times, and this is sort of the update to that post – with a bit of fixes and tweaks.

Lets get to it;

A few changes:

In my last post I did things a bit differently, for instance; I used to throw a custom exception type and handle that as a response, I have learned that this is an anti-pattern and is strongly discouraged (at least by David Fowler).
Anyway now we return a class, which is basically just my old ApiException type, just without the inherited bits of Exception. – this is both cheaper and cleaner.
Also since we are using .NET Core, we are using IMemoryCache instead of HttpRuntime.Cache – which is also nice.

services.AddMemoryCache();

On to the attribute:

There isn’t a lot to it to be honest.

  1. Check for existence of cache entry
  2. If none, create one and set allowExecute = true
  3. If allowExecute != true, return throttle response and short-circuit the pipeline.

Do note that this throttle uses IP as it’s target, but could easily be username or similar.

Usage:

[IPThrottling("GetItems", 300)]
[HttpGet]
public ActionResult<IEnumerable<string>> Get()
{
    return new string[] { "value1", "value2" };
}

The above throttles for 300 seconds for the GetItems key, so you can group together functionality as well, if you really need to.

Ill talk about the custom response in a different blogpost

async await “explained” by examples

What does async and await really do?

Using the await keyword is basically just waiting for whatever function that comes after that keyword to create a thread, do work and return to the calling thread once it is done.
Everything that comes after is a “continuation”
The following 2 functions do pretty much the same thing

The above should also indicate something else, namely continuation.
In the first method everything after the “Task” calls would probably run before the tasks would finish.
In the latter, everything after the await call IS the continuation.
So doing something like the following;


Would result in the function taking around 6 seconds to do its “work”, since everything is a continuation of the former.
– this is probably not what you would want.
Instead you can do something like this;

Which would take around 2 seconds.

Exceptions:

Using async and await there is something to note in regards to exceptions:
I found this in an MSDN article and I think it explains it pretty well.

Async void methods have different error-handling semantics. When an exception is thrown out of an async Task or async Task method, that exception is captured and placed on the Task object. With async void methods, there is no Task object, so any exceptions thrown out of an async void method will be raised directly on the SynchronizationContext that was active when the async void method started. Exceptions thrown from async void methods can’t be caught naturally.

 https://msdn.microsoft.com/en-us/magazine/jj991977.aspx


The following code should explain:

So never ever use async void – it will take days to figure out what is actually going on.
If you have any questions please comment below and I will try to update the article with an answer 🙂

Easy, simple HttpRuntime.Cache

A simple to use caching function that both gets and/or sets the key depending on results.

This is a post for my future self. – Hi future self! (wave).
The following is an easy to use caching function.

The function gets or updates based on results.
The wrapper helps create different cacheExpirations based on needs.
Usage: