* if you don't control the service running the web task, how do you trust the returned result to be the actual execution of the code you submitted?
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.
That's what was not obvious to me, at all (speaking from a platform developer POV).
Seen as that, yes, that looks like a very nice thing to have.
> Isolated using containers
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.
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-Webho...
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?
[1] https://tomasz.janczuk.org/2015/04/rethinking-backend-with-w...
What does this even mean?
Huginn [0] is an amazing self-hosted dev-friendly Zapier/IFTTT/MS Flow that, more relevant to this topic, supports acting arbitrarily on webhooks.
It's a shame, as ideally I'm looking for business logic system (mind with database access) that would allow development with Vue.JS
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.
