express-rate
express-rate copied to clipboard
Integration with expressling
@segmentio would you be interested in integrating this into expressling?
https://github.com/niftylettuce/expressling/issues/14
:+1:
I'll take a look at it this week. Thanks for the interest!
Hey did you have a chance to follow up with this? Let me know, else I might give it a whirl. Thanks @ivolo :+1:
Hey, are you okay with adding a dependency to redis? or do you want to use the in-memory rate store?
I don't see a problem using something :zap: fast like redis
for rate limiting, I'll leave it to your discretion -- we really want to optimize this for perf and speed though!
Let me know if you have other questions, thanks @ivolo
Hey, I don't think I am going to have much time for integration in the next few weeks. Why don't you try it and let me know of any issues? The documentation is on the readme.
On Wed, Feb 22, 2012 at 10:07 PM, Nick Baugh < [email protected]
wrote:
Let me know if you have other questions, thanks @ivolo
Reply to this email directly or view it on GitHub: https://github.com/segmentio/express-rate/issues/1#issuecomment-4129928
@ivolo what basic routes do you think we should limit, and by how much? are there standards/statistics on this stuff anywhere that we can reference for integration? (e.g. /login
route for example, what should our limit be, and how many seconds?). I'd like to use best-practice, so if there is material on this that'd rock. Otherwise I'd still like to hear your opinion.
I don't know of any standards per say, I think most companies do it custom. Usually, popular APIs are rate-limited, and is the dominant use case for why I built this module. I personally like when the API responds with the rate limit information in the headers (how much remaining, how much total, next reset date), and Twitter is a good example of someone who does this.
Also, I may not be the best person to ask about this, but I don't believe that most companies rate limit their main product pages. It doesn't make sense most of the time, since people are hitting it from their web browser and not programmatically. The exception to this is DOS attacks, but you won't even want that traffic to hit your web-servers so app level rate limiting is not at the right level to prevent those.
I would not rate-limit the /login route, but give people the option to simply add rate-limiting to their API controllers.