5 ms·

Show HN: Jiter – Just in Time Webhooks

59 points by josevalerio 4y ago

josevalerio 4y ago
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!
- hkdobrev 4y ago
  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?
  - josevalerio 4y ago
    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 :)
  - skaiser 4y ago
    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!!!
    - cuu508 4y ago
      > 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>".
      - skaiser 4y ago
        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.
- sjinta 4y ago
  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?
  - josevalerio 4y ago
    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 :)
  - skaiser 4y ago
    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 https://discord.gg/NPC6GBDBXp
onassar 4y ago
Congrats @josevalerio So rad! I built an experiment a while back to do exactly this (https://onassar.github.io/experiments/boomerang-webhooks https://onassar.github.io/experiments/boomerang-webhooks) It's awesome to see this productized. I had the same annoyance: setting up and managing cron jobs. Good luck with the launch :)
leetrout 4y ago
Pretty cool! Some other similar tech for those interested in tools like this: Zeplo https://www.zeplo.io/ https://www.zeplo.io/ Boomerang https://onassar.github.io/experiments/boomerang-webhooks https://onassar.github.io/experiments/boomerang-webhooks
- josevalerio 4y ago
  Thanks for sharing! Onassar is also in this thread :D
zomglings 4y ago
Please do not interpret this comment as negative in any way - I am sincerely trying to understand what this does. Instead of setting up cronjobs on a machine I own, this allows me to set up a cronjob on jiter servers to make a callback to my server? Who is your target user? I am happy to run cronjobs or systemd timers on servers that I or my team control. And for execution in environments like GitHub Actions or AWS Lambda, they all have functionality to trigger execution with a timer. This introduces added complexity of maintaining a webhook receiver and having to deal with the rather complex failure modes of webhooks.
- rockostrich 4y ago
  FWIW my engineering org built a service that pretty much does what Jiter offers because we need to do things like schedule messages to be sent in the future. > 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.
- skaiser 4y ago
  Hey there! I'm another dev from the Jiter team. 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.
batuhandirek 4y ago
Love the irony that while the product is trying to "Make cron jobs a thing of the past", it probably runs with one polling the scheduled messages every second to send them JIT
- skaiser 4y ago
  Hey, we're trying to make them a thing of the past for *YOU* XD Hopefully you won't ever have to write them again because we're falling on the sword for you.
tasn 4y ago
Congratulations on the launch, it's something I've been meaning to build for a while, and was actually chatting with @onassar about it (also on this thread) when he built his. It's very much useful, don't let people discourage you just because it's not useful for them. :P Btw, if you are ever tired with managing your own webhook infra, we[1] do webhook sending as a service, and we have also open-sourced the core tech[2] in case you find it useful. [1] https://www.svix.com https://www.svix.com [2] https://github.com/svix/svix-webhooks https://github.com/svix/svix-webhooks
- josevalerio 4y ago
  Wow svix looks great and pretty awesome that it's open source thanks for sharing!
  - tasn 4y ago
    With pleasure, I thought you may find it useful!
srnvsg 4y ago
Looks like the sign up is down?
- skaiser 4y ago
  We're seeing a handful of errors, but they're from GitHub saying the user denied us access??? What did you experience?
  - srnvsg 4y ago
    I just see a screen with this message: We'll be right back... We're hard at work making some great changes.
    - skaiser 4y ago
      Ahhh dang DNS stuff... can you try this url instead: https://jiter.dev https://jiter.dev Thanks for the heads up, we'll get that fixed up asap!
      - srnvsg 4y ago
        The signup page goes to https://app.jiter.dev https://app.jiter.dev which shows the above error message Is that the expected URL?
        skaiser 4y ago
        We just made some changes to our DNS which SHOULD have fixed the original issue. Can you try again? Worst case scenario (if you're still willing to give us a shot), join our Discord and we can work with you to figure out what's going on: https://discord.gg/NPC6GBDBXp https://discord.gg/NPC6GBDBXp
        srnvsg 4y ago
        Yep, I'd love to try it out, will join the discord!
derekzhouzhen 4y ago
Nice. A few questions: * Is the future webhook calling cancel-able? * If I send multiple event with the same payload and same triggering time, will jiter coalesce them into one webhook calling? * if my service is temporarily offline, will jiter retry the webhook?
- skaiser 4y ago
  * Yes (as of later today ;) - we're working on that now and hope to have it up by EOD) * 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!
awill88 4y ago
Mm, so definitely temporary storage and I’m sure some steps were taken to encrypt that temp storage? What is the impact of scope for those secrets ya know? Seems like a honeypot for good stuff lurking in their cloud account.. not going to knock the idea though, pretty clever
hbrn 4y ago
Nice! I always wanted to build the same thing. A system like that is also my favorite question for systems design interview. Care to share some of the technical details? How far does it scale, what are the delivery guarantees, recovery strategy for missed webhooks, time accuracy?
- josevalerio 4y ago
  Sure! 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!
taldo 4y ago
So... kind of Google Cloud Tasks, but webhook only? Or EventBridge/CloudWatch Events in AWS-land...
- josevalerio 4y ago
  Similar, but think more for "one off" events for now, we plan to add more "cron" like functionality in the future. 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.
IncRnd 4y ago
It is a sign of the times devs would consider writing code that depends on random websites in order to get cron-type callbacks instead of using the timer of the actual local system.

59 points by josevalerio 4y ago

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!

hkdobrev 4y ago
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?
- josevalerio 4y ago
  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 :)
- skaiser 4y ago
  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!!!
  - cuu508 4y ago
    > 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>".
    - skaiser 4y ago
      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.
sjinta 4y ago
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?
- josevalerio 4y ago
  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 :)
- skaiser 4y ago
  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 https://discord.gg/NPC6GBDBXp

onassar 4y ago

Congrats @josevalerio So rad! I built an experiment a while back to do exactly this (https://onassar.github.io/experiments/boomerang-webhooks https://onassar.github.io/experiments/boomerang-webhooks) It's awesome to see this productized. I had the same annoyance: setting up and managing cron jobs. Good luck with the launch :)

leetrout 4y ago

Pretty cool! Some other similar tech for those interested in tools like this: Zeplo https://www.zeplo.io/ https://www.zeplo.io/ Boomerang https://onassar.github.io/experiments/boomerang-webhooks https://onassar.github.io/experiments/boomerang-webhooks

josevalerio 4y ago
Thanks for sharing! Onassar is also in this thread :D

zomglings 4y ago

Please do not interpret this comment as negative in any way - I am sincerely trying to understand what this does. Instead of setting up cronjobs on a machine I own, this allows me to set up a cronjob on jiter servers to make a callback to my server? Who is your target user? I am happy to run cronjobs or systemd timers on servers that I or my team control. And for execution in environments like GitHub Actions or AWS Lambda, they all have functionality to trigger execution with a timer. This introduces added complexity of maintaining a webhook receiver and having to deal with the rather complex failure modes of webhooks.

rockostrich 4y ago
FWIW my engineering org built a service that pretty much does what Jiter offers because we need to do things like schedule messages to be sent in the future. > 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.
skaiser 4y ago
Hey there! I'm another dev from the Jiter team. 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.

batuhandirek 4y ago

Love the irony that while the product is trying to "Make cron jobs a thing of the past", it probably runs with one polling the scheduled messages every second to send them JIT

skaiser 4y ago
Hey, we're trying to make them a thing of the past for *YOU* XD Hopefully you won't ever have to write them again because we're falling on the sword for you.

tasn 4y ago

Congratulations on the launch, it's something I've been meaning to build for a while, and was actually chatting with @onassar about it (also on this thread) when he built his. It's very much useful, don't let people discourage you just because it's not useful for them. :P Btw, if you are ever tired with managing your own webhook infra, we[1] do webhook sending as a service, and we have also open-sourced the core tech[2] in case you find it useful. [1] https://www.svix.com https://www.svix.com [2] https://github.com/svix/svix-webhooks https://github.com/svix/svix-webhooks

josevalerio 4y ago
Wow svix looks great and pretty awesome that it's open source thanks for sharing!
- tasn 4y ago
  With pleasure, I thought you may find it useful!

srnvsg 4y ago

Looks like the sign up is down?

skaiser 4y ago
We're seeing a handful of errors, but they're from GitHub saying the user denied us access??? What did you experience?
- srnvsg 4y ago
  I just see a screen with this message: We'll be right back... We're hard at work making some great changes.
  - skaiser 4y ago
    Ahhh dang DNS stuff... can you try this url instead: https://jiter.dev https://jiter.dev Thanks for the heads up, we'll get that fixed up asap!
    - srnvsg 4y ago
      The signup page goes to https://app.jiter.dev https://app.jiter.dev which shows the above error message Is that the expected URL?
      - skaiser 4y ago
        We just made some changes to our DNS which SHOULD have fixed the original issue. Can you try again? Worst case scenario (if you're still willing to give us a shot), join our Discord and we can work with you to figure out what's going on: https://discord.gg/NPC6GBDBXp https://discord.gg/NPC6GBDBXp
        srnvsg 4y ago
        Yep, I'd love to try it out, will join the discord!

derekzhouzhen 4y ago

Nice. A few questions: * Is the future webhook calling cancel-able? * If I send multiple event with the same payload and same triggering time, will jiter coalesce them into one webhook calling? * if my service is temporarily offline, will jiter retry the webhook?

skaiser 4y ago
* Yes (as of later today ;) - we're working on that now and hope to have it up by EOD) * 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!

awill88 4y ago

Mm, so definitely temporary storage and I’m sure some steps were taken to encrypt that temp storage? What is the impact of scope for those secrets ya know? Seems like a honeypot for good stuff lurking in their cloud account.. not going to knock the idea though, pretty clever

hbrn 4y ago

Nice! I always wanted to build the same thing. A system like that is also my favorite question for systems design interview. Care to share some of the technical details? How far does it scale, what are the delivery guarantees, recovery strategy for missed webhooks, time accuracy?

josevalerio 4y ago
Sure! 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!

taldo 4y ago

So... kind of Google Cloud Tasks, but webhook only? Or EventBridge/CloudWatch Events in AWS-land...

josevalerio 4y ago
Similar, but think more for "one off" events for now, we plan to add more "cron" like functionality in the future. 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.

IncRnd 4y ago

It is a sign of the times devs would consider writing code that depends on random websites in order to get cron-type callbacks instead of using the timer of the actual local system.