00:00 So let's open up our server. And we're going to take this config and make a variable called our rate limit default. Stick that right there. And then we're going to create three different rate limit middlewares. So these are the three. And it's going to be rate limit.

00:19 We'll pass our config. And each one of them will have basically the same thing. So we'll have the rate limit default. But then for the strongest rate limit, we're going to say you only get 10 of these kinds of requests. And then for our strong, or just a relatively strong, a little less strong, but still strong,

00:38 we're going to give them 100 per minute, per client, per IP address. And then for our general one, we'll actually just do the rate limit default. So that's everything else that's our current behavior now.

00:53 So with that then, we can make our own middleware here with a rec, res, and next. And with that now, we can add a little bit of our own logic. So we'll return a call to general rate limit.

01:12 That is our general middleware with rec, res, and next. So that's kind of our fallback, if nothing else applies. And then we need to determine, is this a non-get and non-head request? Because head requests are get requests as well.

01:27 So we can say, if the rec.method is not equal to get, and rec.method is not equal to head, then that applies to our strong rate limit. So these are basically the POST requests. Anything that's going to do a mutation. It's something that users probably wouldn't do more than 100 times a minute.

01:46 And so then we're going to return the strong rate limit there. But on top of that, we have the strongest rate limit, which will apply to our especially vulnerable URLs like slash signup. And eventually, we can add more of those. So we're going to make a strong paths. And this is going to be signup.

02:04 And again, you could add more there later. And so if it's a non-get, non-head, then we can check if it's a strong paths.sum. And so if the path not just starts with, it would say if it includes that path. So if the request that's being made

02:24 includes one of our strong paths, then we're going to return the strongest rate limit with the rec.res.next. And there we go. Now, to test this out, we are currently running in a testing environment because we are running with development mode turned on.

02:41 So I'm going to turn off the max multiple here. And we will change this to a max of two. So if you make two requests within one minute, our window MS, then we're going to say that's too many. So just to test it out.

02:58 So we say here, a at b.com. Back it up, a at b.com. That's two. That was fine. And now here's our third, a at b.com. And kablooey, too many requests. Please try again later. Again, you can customize that error message and all of that. So we've got our expected behavior.

03:17 The other cool thing is you notice I refresh. That's a get request to sign up. So we don't want to just protect sign up completely from all requests. That's why we have this special check here. But if I try again, it's not been a minute yet. So I'm going to get too many requests again. So I will have to wait. Eventually, I will be able to get through, but I will have to wait.

03:36 So that is what that experience is like for a user who is trying to sign up for too many accounts. And this is definitely a good idea to apply to any of your public endpoints, but also even your authenticated endpoints, because a user could get an account, like a nefarious user could get an account and then start hitting your APIs a bunch and costing you a bunch of money and whatever.

03:56 So you want to add rate limiting regardless of whether it's authenticated or not. And you want to especially add extra strong rate limiting to those that are especially problematic for you. Like if you're going to send an email, don't let people just send a gajillion emails out. That'll really hurt your deliverability, just for example.

04:14 So in review, we have this basic rate limit default. And then we have three tiers. And of course, you can have more, and you can have all sorts of different logic around this. But we've got three tiers of these rate limits. And then we have our own little middle bear that adds a little bit of logic around which

04:32 one of these tiers these requests should apply to. And with that, we are pretty well protected. So that's adding rate limiting to your web app.