Webhooks, the way they're thought about by, e.g., GitHub, are not a good design pattern. What I want instead is an ordered event sequence I can (long) poll, or watch via Server Sent Events. If you want to sleep until activity, a hook-like POST with no content could tell you to resume polling.
=> More informations about this toot | More toots from jmc@unix.house
@jmc is that mostly because the place you receive the callback is not the place where you have the state and context to use it?
There's always the solution using another layer of abstraction; basically all those ways of receiving events are pushed into a message queue locally, that you pull events from. The rest is mostly just details of transport and who is responsible for queue state. The pain comes when your client isn't an entire platform with queues and capable of hosting hooks.
=> More informations about this toot | More toots from uep@octodon.social
@uep No, it's mostly because classic webhooks are essentially an attempt at replicating state from one system to another, but without handling any of the complexity of doing that correctly. You really need to do something at least as complex as two-phase commit in order to replicate events without dropping or duplicating them, in the face of network weather and the inevitable unavailability of the receiver some of the time.
=> More informations about this toot | More toots from jmc@unix.house
@jmc ah, right.. "who is responsible for queue state": nobody
=> More informations about this toot | More toots from uep@octodon.social
@uep Right. All network communication is asynchronous and lossy, as dictated by physics. There's always a queue, you just get to decide if it's a shit queue or not haha
=> More informations about this toot | More toots from jmc@unix.house
@jmc Much agreed! I'm a big fan of long polls / slow rpcs. Easy to understand and the semantics are clear when described in API:s.
Also, state management is well bounded within the lifetime of the rpc, and it starts with the client (initiating), i.e "the user".
It also fits well with abstractions like "Long Running Job" such as https://google.aip.dev/152
IMHO this so much more ergonomic than hooks, callbacks or any fragile messaging (such as grpc streams) that pile on accidental complexity.
=> More informations about this toot | More toots from dln@mastodon.social This content has been proxied by September (ba2dc).Proxy Information
text/gemini