Show HN: Jiter – Just in Time Webhooks (opens in new tab)

> And for execution in environments like GitHub Actions or AWS Lambda, they all have functionality to trigger execution with a timer.

We use it for triggering things dynamically within services. For example, when someone books a flight we need to send a follow-up email X amount of time later. Building a scheduler into the service that handles booking the flight might make sense, but what happens when we need to do the same thing for someone booking a hotel or car rental? Instead we just have a service that stores all of the messages it needs to send in the future and has a tight reconciliation loop to send out those webhooks.

> This introduces added complexity of maintaining a webhook receiver and having to deal with the rather complex failure modes of webhooks.

If you only need to do it once, sure. If you standardize the behavior/API then it reduces complexity a ton.

Awesome feedback and thanks for taking the time to challenge us! Sorry in advance for the wall of text, but you asked some great questions.

It sounds like you’re probably a bit outside our target market because you sound comfortable building a scalable solution of your own. However, our target user is either unwilling to build their own or they don’t have the skillset to efficiently build and maintain a separate cron app/server.

As for other execution environments, those definitely have options for scheduling things and setting up recurring events, but you have limited flexibility and things like Type Safety can be quite the burden because they're disparate from your core app. (And while I totally agree GitHub Actions is an option, that doesn't sound fun at all haha). However, what they don't have is flexibility around the "when"...

For example, let's say you want to check to see if a user has performed XYZ action within their first 72 hours after signup. You could setup a cron job to fire once daily to simply poll ALL new users, lock those rows, and join with other tables to see if they're relevant for a follow-up email OR you could setup a Jiter event to target that specific user at exactly 72 hours after their signup. The result is distributed, small queries delivered just in time. The payload contains exactly the information you need to handle that one action and you spread your DB queries out over time to minimize larger impact to a decent chunk of your table.

I agree about the complexity of maintaining the webhook, but hopefully that logic is super focused and ideally you'd use different routes/handlers for different events so each is small and maintainable.

Great feedback all around and I'm curious to see if you have a follow up on any of that!

TL;DR - We're not for everyone, but we think we offer a convenient solution for those looking for flexibility and for those without the skillset to roll their own.

Indie/solo devs, if that express state of things better, who are assured their product will be never run in internal/isolated networking, for example or never need to stop some specific cron but not all of them during migration, blah blah blah.

Hopefully you won't ever have to write them again because we're falling on the sword for you.

Regarding the backend we're essentially adding events into a queue and polling the queue for messages that are ready. Since this is an MVP we don't have any scaling or delivery guarantees but from our testing all of our events were delivered within 2 seconds of the desired time. We have many retries if something fails on our end while attempting to send the event to you, but if your server returns an error to us we will mark it as failed with a timestamp.

We are literally adding retries & some more customizability options right now, as well as better docs for usage and other endpoints!

* Not yet, but soon! We're planning to add functionality to allow you to specify whether

* Soon, yes. We're planning on adding functionality for retries soon!

Instead of having EventBridge trigger a lambda to poll your DB every hour for users that signed up 24 hours ago to send them a welcome email, when that user is created you can send us that event with that users info and the emailTemplateId so you can be reminded of it in 24 hours. Once you receive the event from us, you'd send the email like normal on your app server. You don't have to manage the polling infrastructure.