Hey HN!
Today we are launching Jiter, a service that lets you schedule callbacks and receive webhook events when you are ready for them. We got really annoyed by having to manage cron jobs in our application when the vast majority of the functionality that we needed was to be reminded that an event was supposed to happen in the future. Jiter makes this simple since all you need to provide is an ISO timestamp, a stringified payload, and your endpoint destination - we'll handle all of the queuing and do our best to send you that event at your desired time.
Please let us know if you have any questions or feedback! We will have an SDK up soon!
It looks interesting but even after signing up I cannot find any documentation aside from the basic code snippets. An example of what I would like to know is: what if things go wrong, will there be retries?
If an error occurs on our end while processing it, we will keep retrying for a while. If an event fails to POST to your endpoint it'll have a failedAt time for when it failed. We are adding customizable retries soon, as well as docs and an SDK, thanks for your concern we know that's a big feature :)
From the homepage and the examples after signing up, I don't get if you are able to create one event which would be recurring and trigger a webhook every week/month/year etc. or is that not possible yet?
In addition to what Jose posted above, we also want to encourage users to use the existing functionality as a trigger for setting up recurring handlers.
For example, if you receive an event to your webhook and you want that webhook to fire again at the same time tomorrow, make a new call to Jiter and create a new event when you receive the first event and you can chain them together. Hopefully by end of day today we'll be able to include the original scheduledTime in the webhook body so you can use that as the base for the new event (e.g., createNewEvent(body.scheduledTime + twentyFourHours)
And as Jose said, we definitely plan to make recurring events possible in the immediate future too!
For example, if you receive an event to your webhook and you want that webhook to fire again at the same time tomorrow, make a new call to Jiter and create a new event when you receive the first event and you can chain them together.
Hmm, that feels like a brittle solution. As soon as one webhook delivery fails, or the webhook receiver has a temporary problem and throws an error, the chain of callbacks is cut. And so the user has to monitor that. It also gets messy if the user needs a more complex schedule than "every x <time units>".
Agreed on it being brittle. However, that's hopefully where retries come into play. And if the original request is handled but an error is thrown before the new event could be created, I'd hope there would be some form of logging in place to report that and hopefully it'd be a simple API call to restore the flow. But I definitely agree that it's messy...
All that being said, we definitely want to support true cron expressions at some point in the near future, I was mostly just throwing that out there as an option that would work today.
Comments
Hey HN! Today we are launching Jiter, a service that lets you schedule callbacks and receive webhook events when you are ready for them. We got really annoyed by having to manage cron jobs in our application when the vast majority of the functionality that we needed was to be reminded that an event was supposed to happen in the future. Jiter makes this simple since all you need to provide is an ISO timestamp, a stringified payload, and your endpoint destination - we'll handle all of the queuing and do our best to send you that event at your desired time.
Please let us know if you have any questions or feedback! We will have an SDK up soon!
It looks interesting but even after signing up I cannot find any documentation aside from the basic code snippets. An example of what I would like to know is: what if things go wrong, will there be retries?
If an error occurs on our end while processing it, we will keep retrying for a while. If an event fails to POST to your endpoint it'll have a failedAt time for when it failed. We are adding customizable retries soon, as well as docs and an SDK, thanks for your concern we know that's a big feature :)
Our team is definitely working on better docs, this is purely an MVP.
If you're interested in using it, join our Discord and we'll do everything we can to make the platform work for your use case!
https://discord.gg/NPC6GBDBXp
From the homepage and the examples after signing up, I don't get if you are able to create one event which would be recurring and trigger a webhook every week/month/year etc. or is that not possible yet?
In addition to what Jose posted above, we also want to encourage users to use the existing functionality as a trigger for setting up recurring handlers.
For example, if you receive an event to your webhook and you want that webhook to fire again at the same time tomorrow, make a new call to Jiter and create a new event when you receive the first event and you can chain them together. Hopefully by end of day today we'll be able to include the original scheduledTime in the webhook body so you can use that as the base for the new event (e.g., createNewEvent(body.scheduledTime + twentyFourHours)
And as Jose said, we definitely plan to make recurring events possible in the immediate future too!
Thanks for the feedback/interest!!!
Hmm, that feels like a brittle solution. As soon as one webhook delivery fails, or the webhook receiver has a temporary problem and throws an error, the chain of callbacks is cut. And so the user has to monitor that. It also gets messy if the user needs a more complex schedule than "every x <time units>".
Agreed on it being brittle. However, that's hopefully where retries come into play. And if the original request is handled but an error is thrown before the new event could be created, I'd hope there would be some form of logging in place to report that and hopefully it'd be a simple API call to restore the flow. But I definitely agree that it's messy...
All that being said, we definitely want to support true cron expressions at some point in the near future, I was mostly just throwing that out there as an option that would work today.
Recurring events will be supported in the future for full CRON like functionality, we wanted to start off with the simple one off events first :)