2 ms·

Devs prefer webhooks because it's easier to write edge triggered logic than to fetch the full state and calculate the diffs. The webhook doesn't have to actual

Devs prefer webhooks because it's easier to write edge triggered logic than to fetch the full state and calculate the diffs. The webhook doesn't have to actually be edge triggered though, you just want it to look that way for the user. I would compare this to tcp/udp vs ip. When writing apps it's convenient to have lower level protocols do the transmission and error handling for you. I think about this a lot with robusta.dev where we run edge triggered webhooks and actions for Kubernetes. We're letting developers write edge triggered logic, but it's extremely desirable to provide higher level guarantees that triggers will run eventually even if the moment of transition was missed

wruza 5y ago
than to fetch the full state and calculate the diffs It's rarely a thing. Long polling request usually includes an increasing reference point like last-id or last-event-time, based on which the event source filters events or, if there is none, decides to block until they happen. It's still the same event stream, but with a little persistent counter on a client's side. The idea is that if a client encounters a data loss, it doesn't beg their server to reset some "delivered" flags from yesterday. Iow, webhooks are stateful, event streams are usually stateless.