
Extensibility through HTTP with webtasks - janczukt
https://tomasz.janczuk.org/2015/07/extensibility-through-http-with-webtasks.html
======
Rygu
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
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):

[https://github.com/snowplow/snowplow/wiki/Setting-up-a-
Webho...](https://github.com/snowplow/snowplow/wiki/Setting-up-a-Webhook)

------
nlawalker
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...](https://tomasz.janczuk.org/2015/04/rethinking-backend-with-
webtasks.html)

~~~
janczukt
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.

------
Juliate
* 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?

~~~
blaisio
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.

~~~
Juliate
1 & 2\. Got it. Thanks. It makes sense to extend a platform, from the user's
perspective, for her own usage, right.

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.

------
spdustin
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.

[0]: [https://github.com/cantino/huginn](https://github.com/cantino/huginn)

------
lowglow
"Webtasks do this by allowing secure, isolated, and fast execution of custom,
untrusted code directly over HTTP, with no prior provisioning."

> Isolated using containers

~~~
janczukt
Docker is indeed a big part of the story, but security measures do not end
there.

~~~
lossolo
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.

------
funshed
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

------
fiatjaf
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/](https://requesthub.xyz/), which translates webhooks
from one service into calls to other service, all controlled by a jq filter.

------
endergen
This is basically serverless programming as per Parse, Amazon Lambda, Google
Cloud Code, and etc.

------
falcolas
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.

------
sigill
> Customization is what distinguishes platforms from applications.

What does this even mean?

~~~
bulatb
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.

