rlimit.com – rate-limiting made easy

As someone who cares about latency, why would I add an additional HTTP request to the request my users are making? I can just use an in-memory store to achieve the same thing under 1ms.<p>10ms is an eternity, and 100ms added on to every request is insane.

I can do this with two lines in my nginx config. I have no idea why I would ever consider using another service for this if all it does is rate limiting.<p>Also, 100ms is not fast.

I read the mostly negative comments but actually rate limiting is a vast subject. It can be hacked in less than half an hour or it can take days. It depends on the degree of sophistication that an app needs.<p>Sometimes we want to rate limit ourselves not to be temporarily banned from another service with a rate limit on its API. This SaaS can be used for that too. I built a system like that for a customer of mine and it didn&#x27;t take half an hour. The free tier or the $5 per month would have cost my customer less. Furthermore it would work globally on all our machines on different networks. I remember that I told my customer that we would need a rate limiting server to keep track of the global limits, but the answer was to keep working on features and keep using our imperfect solution until we don&#x27;t run into troubles.

Adam here, the author of rlimit, great to see some discussion and pointers on what I need to work on when it comes to pitching the project.<p>rlimit is a distributed counter, keeping counters in sync in several regions, allowing you to have consistent rate limiting, everywhere.<p>If you run on a single machine, there are low to no benefits for you in using rlimit. If you use multiple machines (or serverless runtime), you will likely need something to sync counters - this can be Redis, or you could just sign up for rlimit, and have the counter replicated globally out of the box.

This is not for you in particular, but as a community, we need to stop adding pricing pages to interview projects one can do in an afternoon. We are better than this. Yesterday, it was a compressor that was a wrapper on ffpmg. Now, a literal wrapper of a library.<p>Everyone wants to get rich, and I understand that, but seeing these projects have a pricing page is pretty annoying. Of course, I&#x27;ll move ahead and not buy it, and I get it, but as developers, we need to see this era as an era to build better stuff, not just play these finite games.

I wonder how much SaaS will cost when every small, FOSS library is replaced by another $5&#x2F;mo service.

&gt; Privacy Policy of rlimit.com<p>&gt; This Application collects some Personal Data from its Users.<p>&gt; Personal Data processed for the following purposes and using the following services:<p>&gt; Advertising<p>&gt; Clerk.io<p>&gt; Personal Data: email address; first name; last name<p>Why advertising? And where in a service like this? Maybe it slipped a checkbox in the Iubenda template.

I can see why this makes sense in serverless environments, in some cases — particularly where you already have an API proxy and coordinated state is overly expensive to think about or accomplish.<p>Good job posting and getting it done. That takes guts. Don’t listen to the comments; if you find a market, that’s all you need. I can definitely see Node people using this kind of thing happily.<p>I’m curious, why Google Cloud? What’s it written in?

Is this an early April fools? I don&#x27;t understand.

To the people saying this model is silly or inside out: perhaps. But a determined founder finds and solves a problem.<p>Where they start often isn’t where they end up. Maybe he’ll add a proxy option which rate limits the request and then it is useful in two circumstances.<p>If you are going to be mean to this person I better see you shitting on LaunchDarkly et al, too.

I’m so confused. So I ping rlimit, then if I’m limited I don’t proceed with a request I’d normally make next to my real API? Do “while” or “for” loops not exist? Sleep (5)?

This has no way of enforcing the rate limit, right? Wouldn’t it be far better to actually enforce the rate limit at the request instead of having to make an extra request for each actual request? Is this even serious?

That must be the laziest thing i&#x27;ve ever seen :facepalm: