Hacker News new | past | comments | ask | show | jobs | submit login

This looks nice but don't I still have to invest all the engineering to make sure my calls reach Diahook service in the first place? The argument from diahook seems to be "we'll never go down". That's covered by SLAs by all companies that Diahook would be forwarding my calls to. Does Diahook claim 100% uptime? That's impossible. Even if it were possible, there are many other points of failure between my service and Diahook and I need to take all of them into account. Once I do that, I don't see much point in using Diahook. This would've been better off as a library I think.

There are other features/reason that would make me use a "webhook service" and I've contemplated building one before but mainly for async message passing between systems. Anything sync and you almost always need to take care of all the failure states.

This could be useful as a library or side-car. I can't help but think of this as a plugin for something like Envoy even though Envoy probably does a lot of this already.




Hey, thanks for the feedback! We don't claim 100% SLA, as you said, it's impossible. I already replied to this a few times in this thread.

I think the same can be said on every other API company, including Stripe, Sendgrid, Twilio and etc. If this is a concern for you, you need to take care of that, if it's not a concern for you, then Diahook is not any different.

Anyhow, we take of other things other than just deliverability. We sign the webhooks for you to prevent SSRF, we implemented a retry logic, we have monitoring on all of these, and all of the other things I mentioned elsewhere.

I mentioned it elsewhere in this thread, I don't see how this can be a library. It's a standalone service that needs to be run and monitored, needs to scale with your usage, and you need to make sure it doesn't hang, the queue doesn't get too long, and etc. I actually say it in the post, webhooks aren't as simple as they seem.


> We sign the webhooks for you to prevent SSRF, we implemented a retry logic, we have monitoring on all of these, and all of the other things I mentioned elsewhere.

Nice. These are very useful feature and I can see myself subscribing for these. May I suggest you highlight these as the main features and demote, remove or re-word "not having to invest significant engineering resources in making a reliable webhook calling system" bit (not exact words). Just a suggestion, don't claim to know more about your business than you but as a possible customer, this claim being at the top would throw me off TBH.

> I mentioned it elsewhere in this thread, I don't see how this can be a library. It's a standalone service that needs to be run and monitored, needs to scale with your usage, and you need to make sure it doesn't hang, the queue doesn't get too long, and etc. I actually say it in the post, webhooks aren't as simple as they seem.

They definitely aren't and I know that from building some quite non-trivial ones and I did build some of those as libraries used across projects in the same company. Also, wouldn't my scale be the same irrespective of whether I call Diahook or anything else directly? I still need to make same amount of calls, have same queue, same retries etc.

> I think the same can be said on every other API company, including Stripe, Sendgrid, Twilio and etc. If this is a concern for you, you need to take care of that, if it's not a concern for you, then Diahook is not any different.

This should definitely be a concern for everyone unless missing outgoing webhooks is fine for a service and I agree Diahook wouldn't be any different which was my original comment. Sorry if I came across as dismissive. I was just pointing out how using something like this cannot be a reason to eschew fault tolerance in outgoing webhook code.


Thanks for all of the feedback, definitely a lot of gems I plan to act on!

> Nice. These are very useful feature and I can see myself subscribing for these. May I suggest you highlight these as the main features and demote, remove or re-word "not having to invest significant engineering resources in making a reliable webhook calling system" bit (not exact words). Just a suggestion, don't claim to know more about your business than you but as a possible customer, this claim being at the top would throw me off TBH.

The landing page needs improvements. I agree that this can come across a bit wrong.

> They definitely aren't and I know that from building some quite non-trivial ones and I did build some of those as libraries used across projects in the same company. Also, wouldn't my scale be the same irrespective of whether I call Diahook or anything else directly? I still need to make same amount of calls, have same queue, same retries etc.

The webhook system is another system you need to scale (including monitoring), it's not the same as your main system. You need to make sure that your queue and workers can handle the load, monitor backlog, and etc. I don't think it's quite the same.

> This should definitely be a concern for everyone unless missing outgoing webhooks is fine for a service and I agree Diahook wouldn't be any different which was my original comment. Sorry if I came across as dismissive. I was just pointing out how using something like this cannot be a reason to eschew fault tolerance in outgoing webhook code.

I was definitely too sloppy in my original comment, I didn't try to eschew fault tolerance, I know how important it is! What I was trying to say is that for people who care about this high level of fault tolerance already have systems in place for the rest of the APIs they use, and the people who don't, don't. I don't think it's substantially different to other critical APIs in that sense.


It seems to me that people saying your service is also potentially unreliable are missing the point a bit. By paying you money, there's a customer relationship, an SLA, etc. As a (hypothetical) SAAS company, I don't get an SLA from my customers that their webhook consumer endpoints won't go down, but I do get an SLA from Diahook.


> As a (hypothetical) SAAS company, I don't get an SLA from my customers that their webhook consumer endpoints won't go down

Really? I thought this would be covered under most SLAs.

> It seems to me that people saying your service is also potentially unreliable are missing the point a bit.

The reason I (and _I guess_ other people) are thinking of this is that I read not having to invest significant engineering resources into building a robust failure resistant system as one of the main, if not the main selling point and I don't see how that is possible if I have to build it for Diahook in the first place. I understand Diahook has a great SLA and promises to be up as much as possible but things will always go wrong and there are so many points of failure outside of Diahooks control. So as a service maintainer, I still need to invest the same amount of engineering in the component that calls the webhooks.

SLA is a business thing, not a technical one. When I evaluate multiple services and compare their SLAs, I see the probability of one service causing less disruptions to my business than the other. I don't see that as a reason to not write fault tolerant code. Engineers cannot rely on a higher SLA as a reason to throw fault tolerance out of the window. That's my main issue with using a service like this. However, there can be other features that could still make me sign up. Not having to write fault tolerant code just isn't one and anyone buying into that is shooting themselves in the foot.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: