CD
Cloudflare Developers•7d ago
Marcel Overdijk

Rate Limiting API open beta feedback

The new Rate Limiting API for workers (https://developers.cloudflare.com/workers/runtime-apis/bindings/rate-limit/) is quite interesting to e.g. API a rate limiting mechanism to a API hosted on Cloudflare Workers. However, I think there is a room for improvement to even offer more opportunities leveraging this API. 1) More Rate Limit result details like remaining and reset window
The const result = await c.env.API_RATE_LIMITER.limit({ key: 'some-key' }); now only returns whether there is success or not: { success: true } as defined in the outcome interface: 
 
interface RateLimitOutcome {
    success: boolean;
}
 
interface RateLimitOutcome {
    success: boolean;
}
It would be very nice to return as well how many tries are remaining and what the reset time from now will be. This would give API implementor the option to give feedback to the consumer, e.g. using the RateLimit header fields spec (https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-ratelimit-headers-06) like: 
 
HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Date: Mon, 05 Aug 2019 09:27:00 GMT
Retry-After: Mon, 05 Aug 2019 09:27:05 GMT
RateLimit-Reset: 5
RateLimit-Limit: 100
Ratelimit-Remaining: 0

{
"title": "Too Many Requests",
"status": 429,
"detail": "You have exceeded your quota"
}
 
HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Date: Mon, 05 Aug 2019 09:27:00 GMT
Retry-After: Mon, 05 Aug 2019 09:27:05 GMT
RateLimit-Reset: 5
RateLimit-Limit: 100
Ratelimit-Remaining: 0

{
"title": "Too Many Requests",
"status": 429,
"detail": "You have exceeded your quota"
}
2) Possibility to provide a cost option to the limit call. Currently the limit method only allow to provide a key in the options: 
interface RateLimitOptions {
    key: string;
}
interface RateLimitOptions {
    key: string;
}
It would be very useful to provide a cost option (default 1 if not provided) so based on request or request params the count can be dynamically. This would be very useful for a GraphQL API, but also for a REST API with e.g. some expand request param to include nested resources, which could be counted as more expensive then. And as last, I'm wondering if there are more pricing details available for the Rate Limiting API when it gets out of beta? How will this be calculated?
Cloudflare Docs
Rate Limiting · Cloudflare Workers docs
Define rate limits and interact with them directly from your Cloudflare Worker
IETF Datatracker
RateLimit header fields for HTTP
This document defines the RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset and RateLimit-Policy HTTP header fields for servers to advertise their current service rate limits, thereby allowing clients to avoid being throttled.
3 Replies
zidokobik
zidokobik•6d ago
As I understand this only a binding for workers, it is not a hard rate limit on the client. The client can just send an HTTP to the worker again which could lead to exploding invocations of the workers, and still be billed. Am I right ?
Marcel Overdijk
Marcel OverdijkOP•6d ago
Correct, this is a binding the workers can use, and won't avoiding that the worker will get the request itself. But if early used in the worked you can prevent calling D1, KV etc. and of course sending an rate limited error to the client. cc @Matt Silverlock
Marcel Overdijk
Marcel OverdijkOP•5d ago
or would it make more sense to use https://www.npmjs.com/package/@hono-rate-limiter/cloudflare using a Durable Object?
npm
@hono-rate-limiter/cloudflare
Cloudflare stores and helper functions for hono-rate-limiter.. Latest version: 0.2.2, last published: 4 months ago. Start using @hono-rate-limiter/cloudflare in your project by running npm i @hono-rate-limiter/cloudflare. There is 1 other project in the npm registry using @hono-rate-limiter/cloudflare.

Did you find this page helpful?