honzabit / durable-limiter Goto Github PK

View Code? Open in Web Editor NEW

46.0 3.0 5.0 964 KB

A rate-limiter using Durable Objects on CF Workers that actually doesn't rate limit anything.

License: MIT License

JavaScript 6.44% TypeScript 93.56%

cloudflare cloudflare-workers durable-objects rate-limiting

durable-limiter's Introduction

Rate Limiter - built for Cloudflare Workers, using Durable Objects

Features

Supports fixed or sliding window algorithms
Scoped rate-limiting
Caching
Cleanup of stale DO data using alarm
Responses provide all information needed to take actions (or not)
Tested in production (well, not actually)

FAQ

How to use

You can use it as a subworker as described here.

But it doesn't rate limit anything

Yeah, that's the sad truth. The code is there to decide whether or not a request should be rate-limited, but currently, it just outputs the results in a JSON response. The reason is that this is how it's being used as part of another project I'm working on. That said, I think it's a good starting point as it would require minimal changes from you to send the right responses back.

What about pricing? How does it compare with CF's own rate-limiter?

Well, it all depends on the use case. You can check out the cost calculator.

Description of JSON Body (usage)

type: type can be one of sliding or fixed and describes the algorithm that will be used.
scope: the value of this header is used as the rate-limit scope.
key: the key is the client information, which can be an IP (most of the time), a network, a username, or even a user-agent. In general, feel free to use whatever you like.
limit: the value of this header provides the request limit (e.g. 10).
interval: the interval (in seconds) upon which all calculations are based.

Responses

Response status will be one of:

200, meaning that the request was processed without problems
400, JSON input error
500, any other error, info can be found in the response body

Response body on successful requests depends on the type of algorithm used and the outcome.

If the request should be rate-limited, you would find an error property, with a value of rate-limited, if not, depending on the algorithm used, you will find quota information:

The sliding type might return one of the two following bodies:

{
    "rate": "number, rate of the incoming requests"
}

{
    "rate": "number, rate of the incoming requests",
    "error": "rate-limited"
}

The fixed type might return one of the following bodies:

{ 
    "resets": "number, seconds since epoch",
    "remaining": "number, remaining requests until rate-limiting"
}

{
    "resets": "number, seconds since epoch",
    "error": "rate-limited"
}

durable-limiter's People

Contributors

Stargazers

Watchers

Forkers

sathoro thatlukinhasguy1 ngdbao gummicube pay-platform

durable-limiter's Issues

For your durable object alarm are you calculating ts_less_than correctly?

I maybe completely misunderstanding this so forgive me if this is the case, but say we take:

ts_less_than: Math.floor(now / 1000 / parseInt(interval)) - parseInt(interval) * 2

This is number of intervals - the interval seconds * 2.

Shouldn't you be doing number of intervals -2 intervals aka:

Math.floor(now / 1000 / parseInt(interval)) - 2

cost effectiveness

There are scenarios where this code is more cost-effective than CF's rate limiter and other scenarios where it could kill your budget.

Maybe using some on-the-fly calculations (like the cost calculator) on the traffic patterns, we could identify these scenarios effectively and integrate with the CF API to push the rate-limit rule closer to the edge. An alarm also could be used to trigger the rule's deletion every 1h, as if needed it would be automatically re-provisioned.