Show HN: RateLimitAPI – API for rate limiting in distributed environments

Show HN: RateLimitAPI – API for rate limiting in distributed environments(ratelimitapi.com)

5 points by flurly 2 years ago | 5 comments

flurly 2 years ago |

Hey HN community! I've been working on something I think you'll find pretty neat: a Rate Limit API. It's a tool I built with the goal of tackling the challenges of API rate limiting, especially in distributed systems.

One of the core ideas behind this project was to make it dead simple to use, kind of like what Stripe did for payments. I wanted developers to be able to integrate rate limiting into their systems without the usual complexity. You'll find examples in JavaScript, Python, and Ruby to get you started in no time.

Let's talk about distributed counting – it's a tough nut to crack. In a distributed system, maintaining a consistent rate limit across multiple servers is tricky. There's a lot of coordination and data syncing involved, which can be a real headache. This API abstracts all that complexity away. It provides a centralized, consistent approach to rate limiting, so you don't have to worry about the underlying challenges.

On the pricing front, it's free for up to 1 million requests per month. We've got more flexible plans for higher volumes, all aiming to keep your costs reasonable.

I'd really appreciate your thoughts on this, especially around the ease of use and the distributed counting solution. If you've ever felt the strain of managing API traffic, especially in a distributed environment, I'm keen to hear how this might fit into your workflow.

Can't wait to hear what you guys think!

anze3db 2 years ago | |

I like the simplicity of the landing page! For me personally, the tool would be more useful if I could adjust the duration and the rate limit count without redeploying my code, but I'd also sooner spin up my own Redis instance than use a 3rd party service - so I'm not sure if my feedback is useful :)

PS: You can simplify and make the Python example a bit more secure by using the params parameter[0] instead of building the query string manually:

``` requests.get(base_url, params=params) ```

[0] https://requests.readthedocs.io/en/latest/user/quickstart/#p...

flurly 2 years ago | | |

Thank you! I just pushed an update to the website to use the params parameter.

I'd love to make this more ergonomic for you. I'm used to using configuration propagation mechanisms where you can change configs without redeploying code (basically the webserver subscribes to some central pubsub config store). That paradigm works with this since you could parameterize the duration using the config value. What would work better for you?