You might have seen Graphcool's launch yesterday where they announced 'inline functions'. Graphcool is running its users' code on their behalf right in the hot code path of their mutation pipeline. This means they're able to run untrusted code in an isolated and low-latency manner and at scale.
You may have seen something similar before in Auth0 Rules [1]. That the two share similarities is no coincidence! Auth0 Rules and Graphcool's 'inline functions' use the same Webtask technology behind the scenes.
We packaged up this technology to provide the first and only 'Extensibility as a Service' offering called Auth0 Extend [2]. Auth0 Extend builds on the familiar webhook model but removes the friction webhooks impose on user; no more standing up and managing servers just to handle webhook invocations. Auth0 Extend makes it trivial to transform a platform's webhook integration into an in-platform custom code editing experience.
The programming model exposed by a SaaS implementing Auth0 Extend is totally customizable by middleware. If you feel that your users would be more familiar with a Promise-based model, this can easily be provided.
So... a business model around signed mobile code..? Neat, but I have many questions regarding safety: confinement, isolation, termination, resource management, etc. Shunting code around is the easy part... it's preventing code from doing bad/dangerous things that's hard. Need more info.
@mmalone: Auth0 Extend uses the Webtask technology stack we created at Auth0 that has run our Rules pipeline for over 3 years.
Your questions are spot on: isolation is really the selling point of Auth0 Extend. When running your customers' code on their behalf, a platform needs to be absolutely sure that each customer's runtime environment is isolated from all others. We provide the concept of 'named containers'. These containers represent isolation boundaries. On a PaaS, each tenant of that platform might be assigned a container or each project may be assigned a container. The level at which isolation guarantees are delivered is really up to the platform implementing Auth0 Extend.
Another feature that distinguishes Extend from other 'Serverless' offerings is the absence of material cold latency. Because we use Extend at Auth0 to provide extensibility for the user authentication pipeline, minimal latency is and has always has been a requirement.
It is a very hard (if not impossible in a generic language like Javascript) to _prevent_ code from doing dangerous things. This is not something we pretend to do. Instead, we provide isolation so that the only tenant affected by bad code is that tenant. To minimize the impact of bad code, we have great tooling like real-time streaming logs to facilitate debugging.
Can someone explain to me in simple term. What kind of thing is this Auth0 extend, and why would i need this compared to service like heroku, zeit now, or something else?
15 comments
[ 7.7 ms ] story [ 71.1 ms ] threadYou may have seen something similar before in Auth0 Rules [1]. That the two share similarities is no coincidence! Auth0 Rules and Graphcool's 'inline functions' use the same Webtask technology behind the scenes.
We packaged up this technology to provide the first and only 'Extensibility as a Service' offering called Auth0 Extend [2]. Auth0 Extend builds on the familiar webhook model but removes the friction webhooks impose on user; no more standing up and managing servers just to handle webhook invocations. Auth0 Extend makes it trivial to transform a platform's webhook integration into an in-platform custom code editing experience.
1: https://auth0.com/docs/rules 2: https://auth0.com/extend
[0]: https://www.ecma-international.org/ecma-262/6.0/#sec-promise...
See: https://github.com/auth0/extend/wiki/Auth0-Extend-User's-Gui...
Your questions are spot on: isolation is really the selling point of Auth0 Extend. When running your customers' code on their behalf, a platform needs to be absolutely sure that each customer's runtime environment is isolated from all others. We provide the concept of 'named containers'. These containers represent isolation boundaries. On a PaaS, each tenant of that platform might be assigned a container or each project may be assigned a container. The level at which isolation guarantees are delivered is really up to the platform implementing Auth0 Extend.
Another feature that distinguishes Extend from other 'Serverless' offerings is the absence of material cold latency. Because we use Extend at Auth0 to provide extensibility for the user authentication pipeline, minimal latency is and has always has been a requirement.
It is a very hard (if not impossible in a generic language like Javascript) to _prevent_ code from doing dangerous things. This is not something we pretend to do. Instead, we provide isolation so that the only tenant affected by bad code is that tenant. To minimize the impact of bad code, we have great tooling like real-time streaming logs to facilitate debugging.
Hope this answers some of your questions. If not, join us on Slack: https://auth0-extend.run.webtask.io/slack-signup