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.
I 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):
I read this blog post, as well as "Rethinking backend with webtasks" [1], and I'm still not 100% I understand the motivation behind this - I'm not a frontend developer so I probably don't have the right perspective to understand. Here's what I can gather:
The service that this fellow works on, Auth0, wanted to offer very flexible ("write your own plugin code") customization to their users, beyond what webhooks can offer, and didn't want to require their users to host that code themselves. So he/they built a flexible, scalable execution runtime (the webtask runtime) that can sandbox and execute the arbitrary code provided by their users. Basically, Auth0 is hosting its own Lambda as a service for its users, specifically for running code in response to events/requests that occur within Auth0.
Is that right?
If I work on a simple application, not a service that needs to offer this kind of extensibility to its users, does this concept have any benefit to me?
This concept is relevant to multi-tenant platforms/apps that want to allow their users to extend their functionality by writing custom code. The litmus test is this: if you expose webhooks today, you can improve the experience of your users with webtasks.
1. Well obviously it's different in many ways. For example, it's easier to setup integrations, especially for non-developers. Even if everything is self hosted and internal it's nice to not need to modify a services code for every single use case.
2. I mean you can't I guess? But I'm not sure why that's a concern since it'd be part of a contract/SLA. If you don't trust them to follow the contract, then why are you even talking to them? Just host your own service that you do trust.
Tomku, please add (2015) in topic to your both additions. Anything older than current year (2016) needs to have information when the article was created.
Interesting and very useful, until it isn't. The idea of outsourcing business logic to a 3rd party hosted platform is one id consider high risk at the point it can be easily exported and hosted elsewhere. WebTask provides no independent backup - be for an outage or company failure.
It's a shame, as ideally I'm looking for business logic system (mind with database access) that would allow development with Vue.JS
Many times you just want to get the data sent in a webhook posted to elsewhere (not something that is crucial to your app behavior, but something that would be good if worked). It isn't worth maintaining a server just for that.
For these cases I've just finished implementing https://requesthub.xyz/, which translates webhooks from one service into calls to other service, all controlled by a jq filter.
So, XMLRPC, recast in new clothing? The concept is quite sound, imo, which is why it's been done before. Fear of the wire protocol should not be cause to avoid mature technologies and protocols.
An application has specific features. A platform gives you the ability to build new features by connecting or extending a set of primitives. When an application can be customized in many different ways, especially with hooks for custom code, it starts to look like a platform.
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.