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

The Valley of Webhooks

weli.dev

Post reply on HN
Print view View original

21–30 of 108 posts

Re: The Valley of Webhooks

#21

Post by jallmann »

qlkzy wrote: post #9

This topic always surprises me. I do not understand the sequence of logic that leads people to build synchronisation mechanisms based only on webhooks. Webhooks aren't at-least-once, nor at-most-once, nor are they guaranteed in-order. Some people build systems to make them more reliable, but if you really care about the data you need to think of a webhook delivery as best-effort, a bit like UDP. That's before you get…

> I find that if you put a decent bit of engineering effort into that "disaster recovery" synchronisation, it can often act as the main or only synchronisation process for quite a lot of systems.

Another benefit is that you get to exercise those disaster recovery mechanisms regularly as part of the normal functioning of the system, rather than a specialized path that is only rarely exercised (and thus may be broken when you need it the most).

Re: The Valley of Webhooks

#22

Post by SpaceNugget »

qlkzy wrote: post #9

This topic always surprises me. I do not understand the sequence of logic that leads people to build synchronisation mechanisms based only on webhooks. Webhooks aren't at-least-once, nor at-most-once, nor are they guaranteed in-order. Some people build systems to make them more reliable, but if you really care about the data you need to think of a webhook delivery as best-effort, a bit like UDP. That's before you get…

I have seen it expressed here a few times, but these LLM blog post tech proposal things really give off the vibe (pun intended) of someone being gaslit by claude into thinking they are onto something really important or innovative. It feels really weird reading it. A bit like reading someone's somewhat self aggrandizing journal entries, or walking in on someone... Doin' stuff. I don't hate LLMs, they have made some aspects of my job easier for sure, but I think some people are still pretty off base on where and how it's acceptable to offload to an LLM.

Re: The Valley of Webhooks

#23

Post by __MatrixMan__ »

If you have two or more services that need to agree about state, and you have some set of rules that govern what state changes are valid, and you don't want to mess around with any of this "what do we do when we miss and update vs when we get two of the same update" nonsense, and the services aren't in a position to query the same database, then you should really consider a permissioned blockchain. Consensus hard, but it's harder if you're not using tools that understand that what they're going for is consensus.

Re: The Valley of Webhooks

#24

Post by Xirdus »

__MatrixMan__ wrote: post #23

If you have two or more services that need to agree about state, and you have some set of rules that govern what state changes are valid, and you don't want to mess around with any of this "what do we do when we miss and update vs when we get two of the same update" nonsense, and the services aren't in a position to query the same database, then you should really consider a permissioned blockchain. Consensus hard, bu…

99% of the time (and all 3 times in the blog post), there is only one source of truth for any piece of data, and state transitions are completely arbitrary. Blockchain is almost always the wrong solution.

Re: The Valley of Webhooks

#25

Post by [deleted] »

qlkzy wrote: post #9

This topic always surprises me. I do not understand the sequence of logic that leads people to build synchronisation mechanisms based only on webhooks. Webhooks aren't at-least-once, nor at-most-once, nor are they guaranteed in-order. Some people build systems to make them more reliable, but if you really care about the data you need to think of a webhook delivery as best-effort, a bit like UDP. That's before you get…

[deleted]

Re: The Valley of Webhooks

#26

Post by hyperhello »

alt227 wrote: post #12

I had the exact same thing with the Quickbooks api recently. You cannot trust the responses or webhooks at all. On create a user or invoice for example sometimes it will return an error, yet it actually created the entity. This means you have to check manually after creating everything to know if its created properly. Then you have the issue that sometimes quickbooks takes a while to update, and locks the company fil…

That is the way enterprise software works as a system. It demands to be the central focus of everything. Workers want to route around these turbo productivity theater nonsense that could be replaced by a few K script that gates access to a text file and checks validity of appends. That can’t be allowed, so you need what is essentially whole poorly documented OSs to enable an economy of brokers to it, or the whole con would collapse.

Re: The Valley of Webhooks

#27

Post by thingification »

MGriisser wrote: post #18
weli wrote: post #13

Earlier quoted context omitted.

Maybe the LLM has written maximum 50 words of the article by just being directed to switch things around and improve grammar and or internal consistency

"And here’s the absurd part: that history exists." "It’s a jigsaw puzzle where the manufacturer had the original picture, cut it up, mailed me the pieces one at a time, lost a few in the post, mailed some twice, and printed nothing on the box." "and that’s the entire problem: nothing announces a gap." "None of this is any provider’s bug. Their webhooks work exactly as documented. The problem is what a webhook is: a n…

I think my is-this-LLM alert is triggered not by mere use of phrases / constructions beloved of popular LLMs, but by things like unmotivated magpie-ish use of those phrases.

I didn't get that reading this (I didn't read the whole piece but I had read the parts you quote before reading your comment).

Often the LLM-beloved constructions are good usage in the right contexts.

Re: The Valley of Webhooks

#29

Post by cadamsdotcom »

cobbzilla wrote: post #8

The proposed “feed” solution is functionally indistinguishable from incremental reconciliation. The article presents a good framing and is well-written, but doesn’t really propose anything new.

Yes, and I think that's good news. If what you need is log replication, having a standard means it's more likely providers offer an endpoint that conforms - and covers the common pitfalls (tombstones, what to do if cursors can't be sequential, etc) - because at scale any missed requirement can be a showstopper and send you back to emulating log replication by listening to out-of-order events.
Post reply on HN