Questions to implement a rate limiter guard

[kolbma]

Is there any existing fairing or guard implementation of an API rate limiter for Rocket (0.5) like actix-governor?

[kolbma]

Ok, I couldn't find anything, so I've started to work on this.
It works with a macro and I've just to see how I will provide a way to return additional header fields on Status::TooManyRequests to give the hint when a retry makes sense.

As far as I know I can't modify the response headers from a guard, can I?

[kolbma]

Maybe the most idiomatic way would be to provide a catcher which needs to be registered to the path scope?

[kolbma]

I've just published the crates for it...

• https://crates.io/crates/rocket-governor
• https://crates.io/crates/rocket-governor-derive

Have a look at it and tell me about your first impressions.

[SergioBenitez]

I haven't taken a close look, but my high-level impressions are:

1. The derive seems unnecessary. I think you can get away with a simple generic type Governed<T> which is impl<T: Governable> FromRequest for Governed<T>.
2. I'd want to be able to configure rate limiting via the usual configuration facilities. This seems to only allow doing so programmatically.
3. I'd want some way to configure rate limiting globally. A fairing seems like the right choice here. I'd be nice to do things like rate-limit all POST requests one way and GET requests another way, etc, in addition to doing so per-route.

[kolbma]

Hi Sergio,

thanks for your words...

1. The derive seems unnecessary. I _think_ you can get away with a simple generic type `Governed<T>` 
which is `impl<T: Governable> FromRequest for Governed<T>`.

You might be right, I'll try it. Might be some kind of life-cycle change during development, that the derive macro is left and have not thought of removing it. I'll see.

2. I'd want to be able to configure rate limiting via the usual configuration facilities. This seems 
to only allow doing so programmatically.

You have the flexibility to program everything. ;-) The quota() can collect its values wherever you want, I think, and you can use as many Governors as you'd like.
The problem is, what are the usual configuration facilities...
Would you be happy with using Figment and Providers if you'd setup an Admin (Web) UI to configure your services?

3. I'd want some way to configure rate limiting globally. A fairing seems like the right choice here. 
I'd be nice to do things like rate-limit all POST requests one way and GET requests another way, 
etc, in addition to doing so per-route.

Well, you'd use a "PostGetGovernor" as guard with setting different values for method GET and POST and ignoring route_name.

But for fairings...

In the guide "you" have written:

Request (on_request)

A request callback is called just after a request is received. A request callback can modify the  
request at will and peek into the incoming data. It may not, however, abort or respond directly  
to the request; these issues are better handled via request guards or via response callbacks.

Abort and respond are the requirements to limit the rate. And I don't see a possibility with the on_request() API to do it in an acceptable way.
You could set some TooManyRequests-status (e.g. modify the request header) and have to check it all the way down the route-handlers up to the response. Which would be a job for a guard again. Or also changing the request to a not existing path, feels like a ugly hack.
In on_response() you could then modify the response to return TooManyRequests-Result when the TooManyRequests-status is set or the magical not existing path is detected. But in the meantime a lof of work is done, it is not fail-fast and the responsibility is also not clear and linked to the endpoint.
Or do I disregard anything?