3 ms·
Sort of disagree with the send-everything-in-the-payload approach. It opens your system up to all sorts of weird edge case bugs like receiving hooks out of ord
by jarcoal 10y ago
Sort of disagree with the send-everything-in-the-payload approach. It opens your system up to all sorts of weird edge case bugs like receiving hooks out of order which could mean stale data is considered fresh. It also means you have to care a lot more about verifying the authenticity of the request.
- nimblegorilla 10y ago"trust but verify" Sometimes you want to ignore webhooks based on the payload (or put them into a different queue). It's faster to do that if you get the payload up front.
- abraae 10y agoAgree. Its better to use webhooks as a pure signal that something has changed, and then in the case of update or insert, have the client pull whatever they want using normal API. Otherwise, you end up in a descending vortex of madness trying to specify some protocol whereby the client can specify in advance which properties they care about.
- draaglom 10y agoThis is correct, and important. Webhook payloads need to be logically monotonic[0]; this probably means either: - having a lamport-clock timestamp for each payload so you can entirely discard older payloads in favour of new ones - a well defined / consistent "merge" function over the subset of the payload you care about (e.g. maybe you know a customer's state can never go back from "registered" to "guest") [0]: http://bloom-lang.net/calm/ http://bloom-lang.net/calm/