Live data from Hacker News

Show HN: Jiter – Just in Time Webhooks

jiter.dev

41–47 of 47 posts

Re: Show HN: Jiter – Just in Time Webhooks

#41
post #40
post #35

Earlier quoted context omitted.

Defaults matter. Make the api client encrypt everything it sends to you, so you never handle unencrypted customer data.

Oh for sure, I just haven't thought of a way to enforce that the payload be encrypted because there are so many different methods to do that and most of them still result in a string... Do you have any advice or suggestions for how to enforce that? I'll definitely add some docs to encourage it though; thanks for the suggestion!

When I say “make”, I mean in your own api client library. It should happen automatically so the user doesn’t have to think about it.

You can provide some functions for the webhooks so targeted to authenticate and decrypt the stuff posted to them.

Re: Show HN: Jiter – Just in Time Webhooks

#42
post #16
post #5

Earlier quoted context omitted.

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'…

> 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 ".

Re: Show HN: Jiter – Just in Time Webhooks

#43

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 L…

to my understanding, it's for those who can imagine (and predict time) how to write simple additional httprequest to external URI and create simple `route` in their NodeJS app [for getting callbacks], but who's not confident on wtf is `man systemd.timer` (smells like all dead sysadmins' zombie magic) which `service unit` it should trigger and what actually to run under that service unit. How to deploy all that after all.

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.

Re: Show HN: Jiter – Just in Time Webhooks

#45
post #41
post #40

Earlier quoted context omitted.

Oh for sure, I just haven't thought of a way to enforce that the payload be encrypted because there are so many different methods to do that and most of them still result in a string... Do you have any advice or suggestions for how to enforce that? I'll definitely add some docs to encourage it though; thanks for the suggestion!

When I say “make”, I mean in your own api client library. It should happen automatically so the user doesn’t have to think about it. You can provide some functions for the webhooks so targeted to authenticate and decrypt the stuff posted to them.

Ah gotcha. Yea we'll 100% include that as part of our SDK. Thanks for clarifying!

Re: Show HN: Jiter – Just in Time Webhooks

#46
post #42
post #16

Earlier quoted context omitted.

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'…

> 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…

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.

Re: Show HN: Jiter – Just in Time Webhooks

#47
post #13

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 L…

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 t…

What happens if the webhook fails, does it requeue?
Post reply on HN