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.
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.
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.
robertlagrant|3 years ago
bobfunk|3 years ago
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.
hobo_mark|3 years ago
tppiotrowski|3 years ago
simonw|3 years ago
seniorsassycat|3 years ago
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
lucacasonato|3 years ago
glenjamin|3 years ago
ignoramous|3 years ago
lucacasonato|3 years ago
rektide|3 years ago
AaronO|3 years ago
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.