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?
[1] https://tomasz.janczuk.org/2015/04/rethinking-backend-with-w...
* how is this different than deploying your own (micro)services on different hosts where you control the code?
* 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?
I've linked it before, and I'll link it again.
Huginn [0] is an amazing self-hosted dev-friendly Zapier/IFTTT/MS Flow that, more relevant to this topic, supports acting arbitrarily on webhooks.
"Webtasks do this by allowing secure, isolated, and fast execution of custom, untrusted code directly over HTTP, with no prior provisioning."
> Isolated using containers
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.
This is basically serverless programming as per Parse, Amazon Lambda, Google Cloud Code, and etc.
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.
> Customization is what distinguishes platforms from applications.
What does this even mean?
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.