Category: MVC

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

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:

Showing messages to users with Toastr and SignalR, the perfect match.

Toastr
Sending updates/messages to users can sometimes be a pain in the butt, but using signalR can provide an enormous relief to exactly this matter.
Often times one would have a controller method which would return some sort of JsonResult (or View) containing whether or not the transaction went well. Using SignalR in conjunction with Toasts, we can write an a single implementation that will work for all of your future actions as well.
No more coding ajax success/failure for every single action.

Prerequisites:

  1. An MVC Project
  2. A BaseController
  3. SignalR package from nuget
    • Install-Package Microsoft.AspNet.SignalR
  4. A Toast implementation
    • //cdnjs.cloudflare.com/ajax/libs/toastr.js/latest/js/toastr.min.js
      //cdnjs.cloudflare.com/ajax/libs/toastr.js/latest/css/toastr.min.css
  5. A razor _layout

Once you have everything installed and up and running you are ready to implement SignalR

SignalR Backend implementation

Once the package is installed it should create a startup.cs file – if it doesn’t go create one.
It should look like this

Now we are ready to create the Hub. In SignalR the hub is what ties together connections and messages sent.

Once done, create a MessageEmitter – this will send Toasts through SignalR

Notice I’m using an enum for ToastType

Now we are about ready to send Toasts to our users.

SignalR Frontend implementation

Now for the razor layout page.
Standard SignalR connection and then showing the toast when it is received.

Using this whole ordeal

To actually send a toast message to the user.
simply call the BaseController method from earlier ShowToastMessage()

What now?

You could implement a GlobalErrorHandler attribute and a custom ToastException to throw on controller errors.
it could look something like this


it would then be used by throwing a new ErrorToast, which in turn would send an error HTTP status code (500) to the client AND show an error Toast.
You can now handle ajax errors, along with successes.