3 ms·
It's always great to explore application connectivity for the next generation. Webhooks have done a lot for the web, but the lack of standardization is starting
by Rygu 10y ago
It's always great to explore application connectivity for the next generation. Webhooks have done a lot for the web, but the lack of standardization is starting to show.
However external deployment of code somehow doesn't feel like an improvement to me. From a DevOps perspective having webtask code run on a closed third party environment is a big risk. It makes continuous integration, testing and error reporting more difficult or even impossible if the webtask service isn't well thought-out.
The way forward for webhooks in my opinion should be standardization of push and pull protocols, with concerns like cryptographic signatures, metadata headers, and failure recovery through event sourcing.
- alexatkeplar 10y agoI came here to say the same thing. The article has things the wrong way round: rather than moving the computation on individual webhook event streams into the SaaS provider of that webhook, I want to consolidate all the processing of all my disparate webhooks into my company's own unified event log. Shifting the computation to the SaaS provider is wrong for all the reasons you mention, and others too - for example, if I want to sink my webhooks into a database, I'm not going to want to share those database credentials with the SaaS provider. At Snowplow we support ingest of various webhooks (yes, standardization is a total pain), and then you can write your own "webtasks" on them in whatever tech you like (Lambda/Spark/Hadoop/SQL): https://github.com/snowplow/snowplow/wiki/Setting-up-a-Webhook https://github.com/snowplow/snowplow/wiki/Setting-up-a-Webho...