Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Jiter – Just in Time Webhooks

jiter.dev

Post reply on HN
Print view View original

31–40 of 47 posts

Re: Show HN: Jiter – Just in Time Webhooks

#31

Post by tasn »

josevalerio wrote: post #29
tasn wrote: post #20

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…

Wow svix looks great and pretty awesome that it's open source thanks for sharing!

With pleasure, I thought you may find it useful!

Re: Show HN: Jiter – Just in Time Webhooks

#32

Post by sneak »

skaiser wrote: post #19
zomglings wrote: post #18

Earlier quoted context omitted.

Actually, I hadn't considered that signup use case at all. Good point. It could be a useful way of offloading heavy data processing to Jiter. It would be useful to see on your website what the webhook request from Jiter.dev would look like. How does the receiver know that the webhook came from Jiter with no tampering by a middleman? Is there a signature that the user could verify? (Slack does this well on their webho…

Yea we think it's a solid use case (mostly because we had that problem ourselves with a previous product haha) And another great question! We use signing secrets to create a signature so you can validate that the request from us is authentic. And thanks! This is just the beginning for us, so hopefully you give us a chance and sign up so we can notify you as we release new features!

If you are using signing secrets, consider having the client keep a secret and simply encrypt and sign the payload before handing it off to you.

When it comes back in, they can decrypt and authenticate it. You could hide all this in your api client.

Then you don’t end up with a big centralized database full of the PII of millions of your customers’ customers.

Re: Show HN: Jiter – Just in Time Webhooks

#33

Post by skaiser »

sneak wrote: post #32
skaiser wrote: post #19

Earlier quoted context omitted.

Yea we think it's a solid use case (mostly because we had that problem ourselves with a previous product haha) And another great question! We use signing secrets to create a signature so you can validate that the request from us is authentic. And thanks! This is just the beginning for us, so hopefully you give us a chance and sign up so we can notify you as we release new features!

If you are using signing secrets, consider having the client keep a secret and simply encrypt and sign the payload before handing it off to you. When it comes back in, they can decrypt and authenticate it. You could hide all this in your api client. Then you don’t end up with a big centralized database full of the PII of millions of your customers’ customers.

So are you suggesting that we update docs to encourage users to do that? We use signing secrets to sign the payload so users know the request from us is authentic, but other than that I can't think of how we'd control what users send us aside from just rejecting anything that "looks" like an object ;)

I do like the idea of including a little chunk in our SDK (Coming soon!) to allow them to easily encrypt/decrypt their payload, but that'd be entirely on them to follow that practice.

Re: Show HN: Jiter – Just in Time Webhooks

#34

Post by hbrn »

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?

Re: Show HN: Jiter – Just in Time Webhooks

#35

Post by sneak »

skaiser wrote: post #33
sneak wrote: post #32

Earlier quoted context omitted.

If you are using signing secrets, consider having the client keep a secret and simply encrypt and sign the payload before handing it off to you. When it comes back in, they can decrypt and authenticate it. You could hide all this in your api client. Then you don’t end up with a big centralized database full of the PII of millions of your customers’ customers.

So are you suggesting that we update docs to encourage users to do that? We use signing secrets to sign the payload so users know the request from us is authentic, but other than that I can't think of how we'd control what users send us aside from just rejecting anything that "looks" like an object ;) I do like the idea of including a little chunk in our SDK (Coming soon!) to allow them to easily encrypt/decrypt thei…

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

Re: Show HN: Jiter – Just in Time Webhooks

#37

Post by srnvsg »

skaiser wrote: post #30
srnvsg wrote: post #28

Earlier quoted context omitted.

The signup page goes to https://app.jiter.dev which shows the above error message Is that the expected URL?

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

Yep, I'd love to try it out, will join the discord!

Re: Show HN: Jiter – Just in Time Webhooks

#38

Post by josevalerio »

hbrn wrote: post #34

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?

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!

Re: Show HN: Jiter – Just in Time Webhooks

#39

Post by josevalerio »

taldo wrote: post #36

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

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.

Re: Show HN: Jiter – Just in Time Webhooks

#40

Post by skaiser »

sneak wrote: post #35
skaiser wrote: post #33

Earlier quoted context omitted.

So are you suggesting that we update docs to encourage users to do that? We use signing secrets to sign the payload so users know the request from us is authentic, but other than that I can't think of how we'd control what users send us aside from just rejecting anything that "looks" like an object ;) I do like the idea of including a little chunk in our SDK (Coming soon!) to allow them to easily encrypt/decrypt thei…

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!

Post reply on HN