[anze3db]

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]

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?

[anze3db]

That makes sense if you already have a pub/sub service running. But if you have a pub/sub service running, you probably also have a service that can count events so you won't need ratelimitapi.com.

In this case, I'm guessing the ability to configure the rate limits on your end would be useful. But again, I'm not your potential customer, so don't take this as customer feedback/feature request. I'm just thinking out loud :)

[flurly]

Touche! I guess we'll see if it's an issue in practice. My intuition is people won't change durations that frequently in practice. eg. OpenAI has a limit of 40 messages per 3 hours and hasn't changed that for months.