Idea validation - API for Rate Limiting
Hi Hackers,
I would like to ask you guys and girls about a simple SaaS idea that I have. Would it be interesting for you to use.
It is a Rate limiting API for protecting your web application's critical calls from abuse. Typical example is the brute-force attack on the sign-in page, but in general it is useful if you have a public functionality that can be used as an attack vector against your application. The idea is to provide an API to be used in your application to protect certain endpoints with rate limiting (number of http requests per time unit). There would be various options for client identification or the rate limiting can be global, burst limits, and so on...
I understand that this would present additional latency for your web application, but this can be optimized to the level to support multiple locations to lower network latencies.
This is technically interesting problem to solve, at least for me, as I need such functionality, but does it make sense to create a product for others, too?
Thank you,
Janos
A great idea!
Had the same one myself :P https://www.prefab.cloud/documentation/basic_rate_limits
A couple thoughts. I think RateLimits-aaS makes sense in a couple instances, but for protecting API calls from abuse I think it's more likely that you want something local.
The use case for my offering is for a few more... interesting cases.
The pricing of prefab tries to be low enough that we're even competitive if you do a lot of requests, but in the use case you mentioned I think a service & latency (even though we're really fast!) is probably not something you really want.
For your "from abuse" case you can actually usually get away without a coordinated central store of limits. ie if you have round robin load balancing and don't want any API to do 100/sec don't let any API hit any one node at > 10/sec. Not perfect, but bombproof and low latency.
Hi Jeff. I was not aware of prefab.cloud, I am glad that I was not alone with the idea. Your response is great, thank you. I appreciate the details! Good luck with https://www.prefab.cloud. You made very nice service!
It is worth a shot.
If I were you, I would not build a product from day 1. Even if you build something valuable, it is typically very difficult to get a software company to integrate a new library or system.
Instead, see if you can get someone to pay you to tinker with their Nginx (or Apache or whatever) configs to setup rate-limiting for them. Maybe IndieHackers itself might be interested? Post on freelancing websites. The key thing here is that you are doing a custom job just for them which works well in their environment; not a general solution like you suggested.
If you sense there is enough interest and money, you can figure out the best way to "service-ify" it.
Essentially, lower your barrier as much as possible so that you get paying customers. Then, do the "fun" part of writing code. Your testimonials will be ready, you will know what aspects to focus on, and you will write code with the excitement and assurance that there is money to be made, since you already have :)
Thank you very much! Your response gives much valuable view on the idea, positive focus and useful advices in general. 👍
I don't think it's a viable product but please prove me wrong if you think otherwise. The main problem is simply that most businesses do not have a problem with rate limiting, and the ones that do already have a solution. Unless you have an malicious attacker, most legitimate traffic is unlikely to bring a server down.
I think it can be a technically interesting problem but it is not a problem that is solved in a straightforward way by existing implementations, usually by a flat rate limit per time period, which isn't really technically challenging at all to implement.
I've worked on medium-sized applications that had hundreds of requests per minute and didn't really have to deal with denial of service. It sounds kind of crazy but I don't think people want to pay to solve a problem they don't have (yet).
Hi Dali. Thank you for your feedback, it is very valuable. This dilemmas are reason for posting the question. I wanted to see if offloading such problem would help someone. I am sure that most of the applications, especially mostly content-based, would not need such feature. For web applications, there can be a few http calls that do some of the heavy processing or can be identified as attack vector, that needs special protection, with flat rate limit or a bit more complex algorithm.
An interesting idea, but most frameworks I use come with out of the box support for rate limiting. If I was to use your service you'd need to sell me on why it's better than the built in solutions in my framework.
One point would be that it is a stateless solution for the user, as all throttling state would be managed by the service. Another point would be an arguably ease of use compared to a framework feature. I was also thinking about users that do not use frameworks (my case), or they need more control but do not have time to implement their solution.
Have you done any research on this yet? The following, for instance, is how you configure max of 60 requests per minute for API routes in Laravel. Other frameworks might have it with similar ease, which would be hard to beat.
I've just had a quick look on how some frameworks provide this issue in docs, but given that I do not like frameworks as they provide convenience at the cost of flexibility, I am mostly thinking of targeting developers what are passed the frameworks stage and develop more specialized web apps.
I think it would come down to your implementation of a solution. I can do this through AWS API Gateway (https://aws.amazon.com/api-gateway/), or in my case since I'm using Django Rest Framework (https://www.django-rest-framework.org/api-guide/throttling/).
With that being said, if you came up with a clever "plug-in-play" solution that was super simple to setup; it might have some merit.
CloudFlare also supports rate limiting. Looks very similar to the amazon gateway.
Thanks for good resources. Usage would have to be as simple as possible, but that benefit compared to using libraries is not to worry about the state or resource consumption by local throttling cache.
This is a good idea and a subject I am interested in.
How is it different from something like, say, https://tyk.io ? That has many service levels including free and open source.
Thanks Conor. The key difference is that tyk is a gateway. I would not like to proxy requests, just provide an API for rate limiting that can be used for any purpose including http API protection.
I've thought about doing something like this before, but I wouldn't ever want to use it myself :). I think API gateways are very important, but I would want it locally hosted or be part of the same setup (like AWS API gateway, etc).
On-premises setup is an interesting idea, thank you.
Not a bad idea, but there are already open source solutions for rate limiting. Have a look at https://github.com/openresty/lua-resty-limit-traffic I've used that library for few of my own projects, and it does the job.
As a potential customer, my worries would be around:
Great points. Scalability and latency would be prioritized from start, as reliability is crucial for this type of service. Encryption should not be a problem at all. As for CDN, that is a great observation, support for them have to be figured out.
I don't think you can sell it as a product. Companies who have enough traffic probably will have resources to also implement rate limiting themselves. Someone also mentioned that in most cases there's no traffic. You also have to understand that probably nobody will use your service on sensitive endpoints because data needs to pass your server. E.g. I would never put in external rate limiting service on signin endpoint because that could leak sensitive data.
I am afraid that I did not explain the service correctly. It would not proxy the traffic, just provide the api to use it inside another service to decide if the limit is reached and to provide required information via http status and headers. No data would have to be passed except an id that would identify a resource that needs to be rate limited.