One of the big reasons for going with Deno is that it's an open runtime closely based on web standards. You can download the open source Deno Cli and all code written for our edge layer will run exactly the same there.
As more and more front-end frameworks starts leaning in on running part of their code at the edge, we felt it was important to champion and open, portable runtime for this layer vs a proprietary runtime tied to a specific platform.
Anything running JS comes with some TS support, you just have to transpile it before releasing :) I'm not sure why shipping the transpiler on the production server rather than keeping it in your CI is a good idea, but I think that's what Deno is doing.
> I'm not sure why shipping the transpiler on the production server rather than keeping it in your CI is a good idea, but I think that's what Deno is doing.
IMHO, the decoupling of build step and runtime step in JavaScript was a terrible mistake. I've wasted hours just trying to find tsconfig settings that are compatible with the other parts I'm using. Shipping a transpiler with a known-good configuration alongside the runtime forces everyone to write their packages in a way that are compatible with that configuration, instead of creating a wild west.
The current state of modules and npm reminds me a bit of the bad old ”php.ini” days, where you would have to make sure you enabled the language features enabled by the code you wanted to import. What a mess.
> I've wasted hours just trying to find tsconfig settings that are compatible with the other parts I'm using.
Deno only “solves” that problem by not having a legacy ecosystem, and that’s only if you stick to the happy path of only using modules with first class Deno support. If you try to tap into the vast Node ecosystem, where Deno’s lacking, through e.g. esm.dev, you can waste hours just as easily. Even packages that claim Deno support sometimes have minor problems.
I understand that it might be a problem for browser target, but nodejs is pretty easy to target (at least I never had anyissue).
Also speaking of wild west, Deno did not even manage to have their TS be the same as everyone else, as apparently they do import with .ts file extension, while everyone else is using .js. I feel like this would be creating more mess than fixing anything...
I'm surprised that the function is async but context.rewrite() doesn't use an await. Is that because the rewrite is handed back off to another level of the Netlify stack to process?
Promises are flat, so if a async function or promise callback returns a promise the result is just a promise, not promise<promise>.
Using async for functions that do not use await is still a good idea because thrown errors are converted to rejected promises.
`return await` can be useful because it's a signal that the value is async, causes the current function to be included in the async stack trace, and completes local try/catch/finally blocks when the promise resolves
Actually `context.rewrite` returns a `Promise<Response>`. The `async` isn't necessary here, but it also doesn't particularly hurt. You can return a `Promise` from an async function no problem.
Since it's being returned it doesn't really matter whether `.rewrite()` is returning a promise or not. `return await x` is mostly equivalent to `return x` within an async function.
Netlify and Supabase use Deno's infrastructure for code execution (https://deno.com/deploy/subhosting). Vercel hosts their edge functions on Cloudflare (nothing to do with Deno). Slack's Deno runtime is hosted on AWS.
Are you willing to talk a bit about how Deno Deploy works internally? I think you have an internal build of Deno that can run multiple isolates (unlike the CLI, which basically runs one). How do you limit the the blast radius in case of a vuln in Deno?
Kenton Varda did a pretty great writeup on CF worker security [0]. Would love to see Deno Deploy do something similar.
We probably will eventually. A talk like this takes a _lot_ of time to prepare though, so it's not on the top of our priority list. But it will happen eventually.
The TLDR is that Deno Deploy works pretty similarly to CFW in that it can run many isolates very tightly packed on a single machine. The isolation strategy differs slightly between CFW and Deploy, but both systems make extensive use of "defense in depth" strategies where you minimize the blast radius by stacking two or more defenses against the same issue on-top of each other. That makes it _much_ more difficult to escape any isolation - instead of breaking out of one sandbox, you might have to break out of two or three layers of isolation.
These levels of isolation could happen at different layers. For example network restrictions could be initially restricted by an in-process permission check, then additionally a network namespace, and finally a routing policy on the network that the machine is connected to. Imagine this, but not just for network, but also for compute, storage, etc.
How many Deno instances might an edge server run? Does each tenant have an instance or is there multi-tenancy? What interesting tweaks have you made making a cloudified offering of Deno tailored for http serving?
We're building a highly multi-tenant "isolate cloud" (think VMs => containers => isolates, as compute primitives).
The isolate hypervisor at the core of our cloud platform is built on parts of Deno CLI (since it has a modular design), but each isolate isn't an instance of Deno CLI running in some kind of container.
Isolate clouds/hypervisors are less generic and thus flexible than containers, but that specialization allows novel integration and high density/efficiency.
