Thank you! With respect to datadog the elephant in the room is cardinality and pricing. We charge $20/mo and based on usage of data storage and query execution time. DD is notorious for charging for metric cardinality, which can very easily blow up. Coinbase famously racked up a $50m bill from this!
With respect to the product, we believe there's a segment of the market that likes to know what they are measuring. Datadog and other "telemetry" tools often times install an agent and collect metrics automatically. While this is a great UX onboarding, it does make it harder to know what data you have and how to query it. Whereas with telemetry we believe having that "manual shift" mode where you log your own data and write your own queries is useful in many scenarios.
I'd love to chat more if you're up for it! Shoot me an email at [email protected] if you're open to the idea.
Generally a big fan of Zed. Super fast and quite innovative in their grep UI. My biggest current gripe is Zed's filesystem watchers are either broken or misconfigured on Mac. If I do a `git rest --hard` via terminal or github desktop UI, zed doesn't detect it and I'm forced to do a hard reset of the app to get back to a synced state.
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.
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?
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.
Yep that's right! I did implement IP rate limiting, so eventually power users will either have to sign up or stop using the service. I figured this way was less friction for new users to see the value the product provides.
Just wrapped up the first version of my newest project: LLM Templates. It's all about making your daily grind with Large Language Models (like GPT-3.5 and GPT-4) a bit easier.
So what's the deal with LLM Templates? It lets you create and use quick templates for those repetitive tasks you do with AI. eg.
Deciphering code: “What does this code do? {{ code }}”
Email makeovers: “Make this email sound cooler {{ email }}”
Quick info grabs: “Need the email of {{ person }}”
Right now, it only supports GPT 3.5 and GPT-4, but I'm planning to add more models soon.
I hope it could be a real time-saver for many of you. Give it a whirl and let me know what you think!
With respect to the product, we believe there's a segment of the market that likes to know what they are measuring. Datadog and other "telemetry" tools often times install an agent and collect metrics automatically. While this is a great UX onboarding, it does make it harder to know what data you have and how to query it. Whereas with telemetry we believe having that "manual shift" mode where you log your own data and write your own queries is useful in many scenarios.
I'd love to chat more if you're up for it! Shoot me an email at [email protected] if you're open to the idea.