[HN Gopher] Show HN: Diahook - Webhooks as a Service
___________________________________________________________________
Show HN: Diahook - Webhooks as a Service
Author : tasn
Score : 124 points
Date : 2021-03-09 15:28 UTC (7 hours ago)
(HTM) web link (www.diahook.com)
(TXT) w3m dump (www.diahook.com)
| lyonlim wrote:
| This is a great idea, congrats! We could definitely use this,
| although I'm cautious about passing our customer data through yet
| another data processor.
| tasn wrote:
| Your concern is fair, and I wish more companies were as
| responsible about their user data as you are!
|
| I'm actually very privacy conscious myself, which is why we
| plan on offering optional end-to-end encryption in the very
| near future. This way only you and your customers can access
| the data, not us. :)
|
| Our libraries will deal with the encryption/decryption for you.
| alexbouchard wrote:
| Nice work! I'm just glad to see more people in the space and
| there has been very little pressure on platforms to offer good
| webhooks, many integrations are pretty barebone and I hope you
| manage to help with that. We've also been building
| https://hookdeck.io which is tackling a related problem but for
| incoming webhooks instead of outgoing. Receiving webhooks at
| scale reliably requires a lot of work and well-thought-out
| infrastructure. I'm just about to do a Show HN of our own. I'll
| reach out to you!
| tasn wrote:
| Thanks! Happy to help if I can, feel free to reach out! Email:
| tom @ the domain.
| alexbouchard wrote:
| Saw that a second too late, sent to contact @
| tasn wrote:
| Got it!
| joantune wrote:
| I use Google Cloud Tasks for at least some of the same purpose(s)
|
| I wonder how this one stacks up given is centered for webhooks
| specifically
| tasn wrote:
| We take care of related webhooks channels. We touched on some
| of them on the landing page, but, in no particular order:
| Deliverability, monitoring, retries, security (signing), a nice
| UI for your users to debug, inspect and etc. :)
| progx wrote:
| This is great if it has a better uptime than the service that
| receive the message.
|
| On the other hand: now we have 2 Services that could crash and
| our app still need a retry logic.
|
| Or we could use it as a fallback, if our services is down, we
| sent to Diahook.
| tasn wrote:
| Our whole focus is uptime, and I think it's similar to how you
| use other APIs in your service, how do you deal when you can't
| reach them?
|
| With that being said, this is something we plan on helping with
| too. We will have retries to different endpoints (in different
| geographies), and ways to easily implement it locally. We
| already offer idempotentcy so that helps.
| macspoofing wrote:
| >Our whole focus is uptime
|
| At some point you're going to have to quantify that and
| provide enough evidence (of one sort or another) for this
| claim to be credible. After all, every service under the sun
| will claim things like 'scalability', 'performance',
| 'uptime', 'resiliency', whatever. Devil is in the details.
| tasn wrote:
| I completely agree. We are still new and we need to earn
| this over time. Our uptime so far is 100%, but that's easy
| to achieve as a new company... :)
|
| This is something we focus on though, and as part of this
| focus, we will focus on earning this trust and making it as
| transparent as we can.
| maratc wrote:
| GitHub sends webhooks to our Jenkins servers, but sometimes
| services on our side are down. Can we use your service as an
| intermediary to ensure delivery?
| tasn wrote:
| We don't do it at the moment, but reach out to me at tom @ the
| domain, I'd be happy to chat.
| alexbouchard wrote:
| I can't say for Diahook but https://hookdeck.io was built for
| this. (Disc: Co-Founder)
| dgudkov wrote:
| @tasn, do you have a client library?
|
| PS. On a side note, it would be very nice to have a standard for
| webhooks similarly to OAuth. We're designing a solution for
| accepting various webhooks and the variety of negotiation schemes
| required by various cloud services is absolutely counter-
| productive.
| tasn wrote:
| Yeah we do. Only for Python and JS (TypeScript) at the moment,
| but we will add more.
|
| Both for the sending part (it's really just a REST API under
| the hood for now), and the consuming (verifying signatures).
| ianstormtaylor wrote:
| Extremely good idea. I've had to implement webhooks in the past
| and it was a huge pain (and my implementation likely had tons of
| bugs anyways). Turning into a well architected service seems like
| a perfect fit.
|
| Congrats on the launch and good luck!
| tasn wrote:
| Thanks a lot!
| owaislone wrote:
| 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.
| tasn wrote:
| 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.
| vgel wrote:
| 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.
| owaislone wrote:
| > 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.
| owaislone wrote:
| > 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.
| oliverx0 wrote:
| There is something really cool about this. It is the kind of
| service I think I could implement if I invested enough time, but
| at the same time since you are taking care of all edge cases and
| just provide it as a service with such a simple interface, I'd
| rather just pay for it!
|
| Will definitely be using this on my projects.
|
| Congrats!
| tasn wrote:
| Thanks for the kind words! Yeah, there is no magic (well, there
| is some), it's just the product of experience and hard work. We
| make it so you don't have to earn this experience the hard way,
| and not have to waste your time on doing the grunt work. :)
| kevsim wrote:
| We connected with Tom just as we were getting ready to build
| webhooks into our product (Kitemaker W21). We had a few teams
| asking for webhooks but didn't have much time to dedicate to it
| right now so we were in the market for something like Diahook.
|
| It ended up taking us one afternoon (this afternoon in fact!) to
| integrate Diahook. Was super straightforward and Tom was highly
| responsive.
| tasn wrote:
| Haha, yeah, was lucky timing. :)
| jkarneges wrote:
| Good to see this being addressed! We used to offer webhooks-as-a-
| service at Fanout, but it wasn't very popular and last year we
| discontinued the feature.
|
| There are several reasons I believe we weren't successful with
| it:
|
| 1) There is a perception that webhooks are "easy", and so
| developers might not even think to look for a solution. After
| all, anyone can send an HTTP request. The devil is in the details
| of course, and a good webhooks system is actually a lot of work.
|
| 2) I believe most devs looking for a "push" solution are usually
| looking for something like WebSockets (which has a more common
| perception of being hard). And so the people finding us or
| landing on our page had a specific goal in mind, and our
| additional offering of webhooks wasn't enticing.
|
| 3) Our webhooks feature simply wasn't that good. It handled
| retries, fan-out, rate limiting, ordered delivery, and full
| payload customization. That's a start, but a complete solution
| also needs inspection, response feedback, test calls, and UI
| widget.
|
| With the right product and GTM, maybe it can work. Good luck!
| tasn wrote:
| Thank you, I'd love to chat if you are willing! My email is tom
| @ the domain. Is there a way I could reach you?
|
| Thanks!
| jkarneges wrote:
| Sent you a mail.
| tasn wrote:
| Cheers, thanks!
| mrkurt wrote:
| This is great. I've wanted a library for this, but a SaaS will
| do. :)
| tasn wrote:
| Half of the magic is in the infra (scalability, monitoring, and
| etc), so we can't deliver the same value with just a library.
| Though I would love to hear what you have in mind!
|
| P.S, what you are doing with Fly.io is super cool!
| mrkurt wrote:
| Hey thanks! If you want to run Diahook on it we can help.
|
| We happen to be pretty good at infra, so a library / self
| hosted setup is usually preferable. This is partially because
| we prefer to monitor things ourselves, and partially because
| we don't want to send things like auth tokens through a third
| party service. We might be unique, though.
| tasn wrote:
| Thanks, I'll keep it in mind when we are ready! I
| especially like the easy postgres replication. :)
|
| I'll reach out about Diahook, as we can also have a self-
| hosted offering, and I think it could still make sense for
| you. As you can still benefit from the rest of the
| offering, including client side libraries and management UI
| (will be fully customisable soon).
| stunt wrote:
| I've built a serverless webhook dispatcher at my previous job
| and you can actually cover most of the scalability and
| resiliency requirements with a few AWS services. I think what
| is hard to build and the core value that your service
| provides is the management, governance, and monitoring around
| it. I would focus there as the main selling point. Kudos for
| launching it and good luck.
| artembugara wrote:
| Hi Tom! It sounds great.
|
| At NewsCatcher [1] we've been asked for webhooks to our data a
| few times. We still did not start the implementation. Do you
| think Diahook would be a good solution to consider?
|
| Also, 1$ per 1,000 hooks. What exactly does it mean? Like any
| push through your hook?
|
| [1] newscatcherapi.com
| tasn wrote:
| Yeah, I know the feeling, haha.
|
| It's $1 per 1,000 messages. Retries, or if there's no one to
| send to are free. So it's just for actual webhooks sent. I'll
| clarify it now.
|
| Anyhow, I'd love to chat and help you get started, please email
| me at tom @ the domain!
| artembugara wrote:
| That may be my bad. In my head "webhook" is a process. And
| you do all those pushes through this "webhook".
|
| Doesn't mean I'm right.
| tasn wrote:
| Yeah, you are probably right and the writing is sloppy. I
| was going to fix it, but I just saw we have an explanation
| under the pricing boxes. Does that clarify things?
| artembugara wrote:
| Yeah, I missed it. I'd prefer it to be under the Title of
| the section: "Diahook Pricing"
| tasn wrote:
| Will think about reorganising it, thanks!
| wyc wrote:
| I can't remember how many times I've written Redis-backed retry
| timers in Go to handle unreliable endpoints. It'd be great to not
| have to do that again. I like that you're focusing on such a
| concrete problem that I can see shaped functionality need into
| which it fits.
|
| What happens when the requests to your API fail? Do I need to
| retry? Will there be an SDK that can help with this?
| tasn wrote:
| Hahaha yeah, I hope no one ever needs to do it ever again!
|
| It's a good question, and I answered it in a sibling comment:
| https://news.ycombinator.com/item?id=26400510
|
| Essentially I think it's a risk with any external API you use.
| What happens when Stripe goes down? Twilio? Sendgrid (when you
| use magic links login)? Our whole focus is uptime, that's what
| we do. :)
| redisman wrote:
| Looks great! Sorry for the off-topic but what is the "2021
| bootstrap" that all startup landing pages are using? I like the
| look and keep seeing it everywhere
| dmlittle wrote:
| I think it's probably the unDraw[1] illustrations you're seeing
| and not the theme itself.
|
| [1] https://undraw.co/illustrations
| tasn wrote:
| Haha, it is self designed (but using bootstrap).
| GhvstCode wrote:
| Hey, This is an amazing product! Congratulations on the launch.
| At Hookdeck(hookdeck.io), we are solving a similar problem.
| Hookdeck sits between the API provider & your service, ensuring
| you never miss a webhook notification. We provide the queues for
| reliable webhook ingestion and the tooling for easy monitoring
| and troubleshooting, Automatic & manual retries, event filtering.
| You should check us out
| tasn wrote:
| Thanks a lot!
|
| And yeah, I'm familiar with hookdeck, your co-founder already
| commented in this thread. :)
| tasn wrote:
| Hey everyone, my name is Tom, and I'm excited to be launching
| Diahook on HN!
|
| Diahook makes it easy for developers to send webhooks. Developers
| make one API call and we take care of deliverability, retries,
| and offer a great developer experience for their users.
| Essentially, we make it possible for everyone to offer a Stripe-
| like webhooks experience.
|
| At my previous company, our users were constantly asking us for
| webhooks, both for consuming in their own services and for
| integrations with no-code solutions like Zapier. However, we kept
| on deferring building them because we weren't willing to commit
| the engineering time, resources and ongoing maintenance required
| of a webhook delivery system.
|
| There are a variety of challenges when it comes to sending
| webhooks. For example customer endpoints fail or hang much more
| often than you would think, so you need to implement retries, but
| also make sure that such failures don't slow down or block your
| send queue or the rest of your system. Additionally, because of
| how webhooks work, anyone can send fake webhooks to your
| customers, so you need to make sure to cryptographically sign the
| payload, and make it easy for your users to verify it. You also
| want to avoid overloading your users' endpoints, so you want to
| automatically rate-limit webhook sending, as well as disabling
| failing ones, and notifying your users when you do.
|
| I love webhooks, and I think everyone should be offering them!
| Our goal with Diahook is to make it faster for developers to add
| webhooks to their service, take care of the above challenges (and
| more), relieve them of having to worry about maintenance and
| scaling, and offer their users a UI for inspecting, debugging and
| replaying of past webhooks out of the box.
|
| I'd love to hear about your experience building (or using)
| webhooks systems. What's a must have? Any war stories to share?
| Got any questions? Suggestions? Please let me know!
|
| Docs: https://www.diahook.com/docs/
|
| API viewer (and OpenAPI specs): https://api.diahook.com/docs/
| mlader wrote:
| This is great =). I have owned a large webhook delivery system
| myself, and considered starting a SaaS around it. I'm also a
| big fan of webhooks and I think there is definitely a market
| for this out there. Kudos to you for taking the plunge and
| launching!
|
| Here's the only post I wrote for it that focuses on security,
| which is pretty critical for a webhook system
| https://www.easywebhooks.com/how-to-secure-a-webhooks-api. You
| might want to consider adding protection against Replay Attacks
| and support for Challenge-Response Checks if you do not
| already!
| tasn wrote:
| We already protect against reply attacks (we have a signed
| timestamp as part of the webhook), and I'm not sure what you
| mean by challenge-response checks. Do you mean things to
| protect against SSRF? If so, yeah, we also sign the webhooks
| in order to make sure they come from the right source.
|
| Thanks for the link, will read it tomorrow!
| mlader wrote:
| A challenge response check will help ensure that the
| webhook consumer is actually using the webhook signature,
| and improve the likelihood that you are sending data to the
| right target. I saw a number of times that systems weren't
| verifying the data we were sending them came from us even
| though we had gone to all of this effort to help them
| :facepalm:.
|
| Basically you periodically send a GET request to the target
| API with a token, and have them respond with the token
| encrypted with the same secret they'd use to decrpyt your
| webhook signature.
|
| You could also consider sending dummy ping messages that
| may or may not have a valid signature (of course make sure
| this behavior is documented) that you would expect the
| target API to return a 4xx error if the signature is
| incorrect.
|
| These extra steps are definitely not table stakes for a
| webhooks system, but could be enough to make sure the
| webhook event providers are being the best possible
| stewards of their user's data that they can =D. A lot of
| this complexity can also be wrapped by a client library you
| provide, which is a big win for everyone on its own.
|
| Twitter's webhook API has an example of CRC btw!
| https://developer.twitter.com/en/docs/twitter-
| api/enterprise....
| primitivesuave wrote:
| Congratulations on launching this much-needed product! I've
| rolled my own webhooks several times, so I personally know all
| the pain points you mentioned.
|
| I work in healthcare tech, and in the last couple years I've
| worked with legacy medical systems that use FTP to implement
| "pseudo-webhooks". For each integration with a third-party
| technology provider, there is a dedicated FTP server that
| reads/writes files to an FTP server owned by the third party.
| When this service is interrupted there is no retry logic -
| someone has to spend time manually checking if files made it
| across.
|
| If someone could make this legacy process easier on developers
| and HIPAA compliant they would be rewarded handsomely, as these
| organizations (hospitals, medical device makers, health-tech
| companies, etc) are comfortable paying enterprise-level prices
| for any technology they use.
| tasn wrote:
| We are going to start working towards HIPAA soon, and we also
| going to offer a way to end-to-end encrypt the payload in the
| very near future. The encryption doesn't help with HIPAA
| (does it?), but it definitely helps with peace of mind and
| reducing the attack surface.
| macspoofing wrote:
| >Developers make one API call and we take care of
| deliverability, retries
|
| Don't developers need to handle deliverability and retries to
| Diahook?
| dariusj18 wrote:
| Agree, I feel like anything like this as a service can be
| helpful, but misses the mark on use case.
| tasn wrote:
| I don't think they do, our whole job as an API company is to
| have uptime (and redundancy for uptime). I think it's the
| same with every other API company, such as Sendgrid, Twilio
| and etc.
|
| User endpoints on the other hand, fail all the time, and
| often require a few retries.
|
| With that being said, we plan on having client side (in our
| libraries) redundancy (try another endpoint if one fails),
| and ways for you to gracefully handle errors locally for
| users who need this.
|
| Edit: I realise this comment was a bit sloppy, added some
| context in another comment
| https://news.ycombinator.com/item?id=26400970
| toomuchtodo wrote:
| It's not just your infra though. Say I'm a client sending
| you webhooks. My internet connection (if not in cloud
| infra) could be down, or my cloud provider might not have a
| route to your delivery endpoint due to a routing or similar
| outage. If those requests block, the client's app is going
| to hang or back up. If they don't block, they have to go
| somewhere (perhaps journaled with a task that can be
| executed on demand or on a recurring schedule).
|
| My suggestion would be not only a library, but a local
| queue that can be managed with the library. Also, having
| some experience with working at a no code provider
| previously, ensure that it's trivial to query your service
| for what webhooks you can confirm were received by your
| infra and then delivered, perhaps by UUID.
|
| Last, make sure it's dreadfully difficult to make changes
| to your systems where data loss could occur (messages
| dropped while returning 200 to counterparty systems, for
| example).
| tasn wrote:
| It's a good point, and actually some of our users already
| have this local queue implementation anyway because they
| want to send webhooks asynchronously. So it's definitely
| something to keep in mind. We already make it easy to
| query the service for what webhooks were delivered, but
| we also let you use the API with idempotency keys to
| ensure messages are not accepted twice.
|
| I agree about all the issues you outlined though. One
| thing we plan on doing in terms of internet being down
| and cloud provider not having routes: have a lot of
| endpoints spread geographically in every region, and
| maybe in the same/nearby data centers.
|
| Thanks again for the feedback!
| mrkurt wrote:
| For what it's worth, Stripe's Idempotent Requests are a
| nice way to handle this:
| https://stripe.com/docs/api/idempotent_requests
|
| We just send the same requests over and over until
| they're successful. It's relatively simple to use.
| tasn wrote:
| Yeah, we also support idempotency (the event ID is used
| for that). I'll add it to that comment, I forgot to
| mention it. :P
|
| Edit: ahh, I already mentioned it, it's buried in my
| comment.
| [deleted]
| dgellow wrote:
| > I don't think they do, our whole job as an API company is
| to have uptime (and redundancy for uptime). I think it's
| the same with every other API company, such as Sendgrid,
| Twilio and etc.
|
| That doesn't sound realistic to me. Sendgrid, Twilio, and
| all other APIs have downtimes and other problems, just
| check their status page:
| https://status.sendgrid.com/history.
|
| I always had to implement some retry logic in API clients
| at some point or another. That doesn't mean your service
| doesn't bring value but it's not enough to just expect it
| to work because it is focused on uptime. When implementing
| a service that requires external dependencies I would
| always expect them to fail and try to design with that fact
| in mind.
| tasn wrote:
| I agree, and I think my original comment was a bit
| sloppy.
|
| We already have users that have their own queue system
| for sending us messages because that's how they deal with
| similar APIs too.
|
| So I definitely see the problem, what I meant in my
| comment is that it's similar to other API companies, and
| it's not unique to us!
| sundbry wrote:
| It's not always your service crashing you need to worry
| about; reliability also includes the network (and all of
| the routers) between you and your customers.
| tasn wrote:
| Yeah, I replied to a sibling comment. You are right, I
| was a bit sloppy with my message. I was just trying to
| make the point that it was similar to other APIs, and
| that we take uptime seriously.
| ucarion wrote:
| This is a neat idea! Harder than it sounds, but y'all seem to
| have most of the aspects of the problem in mind already.
|
| My employer (Segment) has something similar to Diahook (as I
| understand it) at its core:
| https://segment.com/blog/introducing-centrifuge/
| tasn wrote:
| I just skimmed through the post (it's late here, haha). It
| looks like Centrifuge is cool and is a part of what a webhook
| systems needs, but not all of it. Check out the landing page
| for some of the other things we provide.
|
| Thanks for sharing this though, a cool read for tomorrow!
| lyime wrote:
| The real value creation here would be turning a GET API endpoint
| into a webhook service. So your service would monitor the service
| and push updates on changes / diffs based on certain time
| interval.
|
| Build that and people will flock to you.
| tasn wrote:
| Zapier does it to an extent, but yeah, it's something to keep
| in mind. You got my creative juices flowing a bit with this
| comment, thanks a lot!
| lyime wrote:
| Awesome! Congrats on shipping. We launched Terminal49 APIs
| with webhooks as first class citizen. So this is top of mind.
|
| There are many industries where push APIs haven't caught up
| and are much needed.
|
| Let me know if I can help akshay@terminal49.com
| dwwoelfel wrote:
| You can do this with OneGraph (https://www.onegraph.com) via
| our `poll` subscription.
|
| Here's an example query that will poll an npm package and send
| a payload whenever the latest version changes.
|
| https://www.onegraph.com/graphiql?shortenedId=FYH1SY
| subscription PollNpmPackage { poll(
| webhookUrl: "https://example.com"
| onlyTriggerWhenPayloadChanged: true schedule: {
| every: { minutes: 60 } } ) { query {
| npm { package(name: "graphql") {
| distTags { latest {
| versionString } }
| } } } } }
|
| This is just an illustrative example. I used NPM because it
| doesn't require any authorization. We also support proper
| subscriptions for NPM that listen to their couchdb change feed.
| tasn wrote:
| This is very cool! I'll take a better look at what you do
| tomorrow!
| fasteo wrote:
| If I am understanding you well, fanout[1] will serve this
| purpose
|
| [1] https://fanout.io/
| jkarneges wrote:
| Fanout founder here! I appreciate the mention, although we
| don't actually support sending webhooks. Well, awhile back we
| did, but lately we only support pushing to client-initiated
| connections.
| jackconsidine wrote:
| Spent so much time rolling my own webhook system for my eSign
| side project [0]- there are so many edge cases and thorny
| behaviors. This is a rare perfect fit of a SaaS offering. I can't
| wait to integrate with some of my other projects! The pricing
| model is generous as well.
|
| [0] https://waiverstevie.com
| tasn wrote:
| Thanks a lot for your kind words! Please feel free to reach out
| at tom @ the domain. Happy to help you get started, and I'm
| super interested in hearing about your other projects!
| kenrose wrote:
| Similar questions from last time there was a Webhooks as a
| Service on HN [1]
|
| 1. How do you deal with endpoints that are down or 500'ing? What
| kind of retry policy or backoff occurs? Related, how do you
| notify clients when their endpoints are having trouble? (I ask
| because that's PII that I then have to share with you).
|
| 2. Is there support for message signing (e.g., HMAC) to let
| clients verify that the webhook really came from us? How does it
| work?
|
| 3. Any kind of deduplication support? One use case we had was
| that certain webhooks only required the latest delivery. e.g.,
| product inventory. If we previously failed to deliver a webhook,
| but have a newer version pending, our next attempt should try to
| send the newest version.
|
| 4. Is it possible to delay hydrating data in the payload? It
| seems the expected usage is that I send a blob of data and you
| take care of the last mile and send it. Is it possible to send
| you an id and then you call back to my service and fetch the
| latest version of that object just before delivery?
|
| 5. How are webhook subscriptions actually managed? e.g., my app
| lets users register webhook URLs? How do I get those URLs to your
| service?
|
| 6. The big question: What do I do if your service is down?
|
| [1] - https://news.ycombinator.com/item?id=25992800
| tasn wrote:
| Thanks for asking:
|
| 1. Exponential backoff. We don't notify clients, but we notify
| you with a webhook. We actually don't have it implemented yet,
| but will have in the next week or two.
|
| 2. Yes, and libraries for some languages (more coming) to
| easily verify it. See the docs for how it works, but standard
| stuff. We also plan on offering end-to-end encryption in the
| very near future so that we can't even access your payloads.
|
| 3. No, and no plans for supporting it for now. Does anyone do
| it? I think sending all of them is actually a feature.
|
| 4. Could you elaborate? You mean changing the webhook content
| in each attempt? No plan at the moment. Similar to the previous
| point. We consider webhook payloads as immutable messages.
|
| 5. You can either use our API to add them, or redirect users to
| a management UI we built with a one-time password. We will also
| offer JS libraries to make it easy to build your own UI.
|
| 6. I answered it a few times in this thread. Here's my original
| sloppy comment (with a link to a comment with more context):
| https://news.ycombinator.com/item?id=26400510
| jabo wrote:
| A go-to architecture topic of mine for backend engineer
| interviews is to design a webhook system (the push side). I've
| gotten a lot of mileage out of it because depending on the
| person's experience dealing with a running production system, I'd
| get varying level of detail unprompted and that usually is a nice
| proxy for depth of experience.
|
| It turns out my interview question is now a SaaS!
|
| Kudos on the launch OP. This is a much needed service and it's
| one of those things that once you see exist you go d'oh, why
| didn't we have something like this all this while.
| tasn wrote:
| I'm stealing this interview question, haha. :P
|
| Thanks a lot, yeah, there are so many moving parts and
| pitfalls. I think that what makes it a good question, also
| makes it a good service (I hope).
| spullara wrote:
| Square had a similar interview question but it was more along
| the lines of how to keep a socket open to a financial services
| company. Lots of the same issues.
| matdehaast wrote:
| This is great! Pinged my team and they like it.
|
| Some notes: 1) I think you are to cheap. 2) signatures of sent
| webhooks is pretty important for the receiving party.
| tasn wrote:
| Thanks for the feedback! Happy to chat with them directly
| (email: tom @ the domain).
|
| 1. Ah, maybe. We are still new and trying to figure it out.
| Thanks for the feedback.
|
| 2. We already offer them, including libraries for some
| languages to easily verify them!
___________________________________________________________________
(page generated 2021-03-09 23:01 UTC)