Extensibility through HTTP with webtasks | Hacker News Reader

Extensibility through HTTP with webtasks

tomasz.janczuk.org

86 pointsjanczukt17 comments

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):

https://github.com/snowplow/snowplow/wiki/Setting-up-a-Webho...

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

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.

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

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.

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.

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

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

> Isolated using containers

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

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.

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?

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.

Reply on news.ycombinator.com