Live data from Hacker News

Netlify Edge Functions: A new serverless runtime powered by Deno

netlify.com

31–40 of 166 posts

Re: Netlify Edge Functions: A new serverless runtime powered by Deno

#31
post #21
post #2

Aaron from Deno here, happy to answer any questions you may have !

Question about https://edge-functions-examples.netlify.app/example/rewrite export default async (request: Request, context: Context) => { return context.rewrite("/something-to-serve-with-a-rewrite"); }; 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.

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

Re: Netlify Edge Functions: A new serverless runtime powered by Deno

#32
post #5

This is great news. I'm really rooting for a successful trend of Serverless runtimes, mainly as a weapon against rising cloud deployment costs. While the general trend today is to back the serverless environment with Javascript runtimes (Cloudflare runs its edge on top of V8, Netlify uses deno, most other serverless runtimes use nodejs), I'm optimistic that WebAssembly will take over this space eventually, for a bunc…

I fully agree with your take. I think JS-directed computation is very good towards short-term adoption (since running JS on the Edge is probably the most popular use case), but eventually the needs to run other programming languages at the Edge will likely eclipse the JS use case.

At Wasmer [1] we have been working actively towards this future. Lately more companies have been also doing awesome work on these fronts: Lunatic, Suborbital, Cosmonic (WasmCloud) and Fermyon (Spin). However, each of us with a different take/vision on how to approach the future of Computation at the Edge. I'm very excited about to see what each approach will bring into the table.

[1] https://wasmer.io/

Re: Netlify Edge Functions: A new serverless runtime powered by Deno

#33
post #5

This is great news. I'm really rooting for a successful trend of Serverless runtimes, mainly as a weapon against rising cloud deployment costs. While the general trend today is to back the serverless environment with Javascript runtimes (Cloudflare runs its edge on top of V8, Netlify uses deno, most other serverless runtimes use nodejs), I'm optimistic that WebAssembly will take over this space eventually, for a bunc…

> mainly as a weapon against rising cloud deployment costs.

Cloud Functions is literally code you're running in the cloud. And the moment you approach their limit(ation)s, you will see the same "rising cloud deployment costs"

> Running a WASM engine on the cloud means ... a fraction of the overhead of a container or nodejs environment

You do realise that there are other languages than javascript in nodejs? That there other environments than cloud functions? And that you can skip that overhead entirely by running with a different language in a different environment? Or even run Rust in AWS Lambda if you so wish?

> so there’s no lock-in with the language that the Serverless provider mandates.

And at the same time you're advertising for a runtime lock in. This doesn't compute.

> Web pages that are as ancient as the early 90s are perfectly rendered even today... Basically, it means a WASM binary is future proof by default.

It's not future proof.

Web Pages from the 90s are not actually rendered perfectly today because browsers didn't agree on a standard rendering until late 2000s, and many web pages from the 90s and 2000s were targeting a specific browser's feature set and rendering quirks. Web Pages from the 90s are rendered good enough (and they had few things to render to begin with).

As web's standards approach runaway asymptotical complexity, their "future-proofness" is also also questionable. Chrome broke audio [1], browsers are planning to remove alert/confirm/prompt [2], some specs are deprecated after barely seeing the light of day [3], some specs are just shitty and require backtracking or multiple additional specs on top to fix the most glaring holes, etc.

> I've published my (ranty) notes on why Serverless will eventually replace Kubernetes as the dominant software deployment technique

"Let's replace somewhat unlimited code with severely limited, resource constrained code running in a slow VM in a shared instance" is not a good take.

[1] https://www.usgamer.net/articles/google-chromes-latest-updat...

[2] https://dev.to/richharris/stay-alert-d

[3] https://chromestatus.com/feature/4642138092470272 and https://www.w3.org/TR/html-imports/

Re: Netlify Edge Functions: A new serverless runtime powered by Deno

#34
post #2

Aaron from Deno here, happy to answer any questions you may have !

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?

Re: Netlify Edge Functions: A new serverless runtime powered by Deno

#35
post #13

Earlier quoted context omitted.

> Use cases > A bunch of server functionality Why is that the use case? I don't see how an edge function can be faster than a centralized server endpoint if it has to reach out to literally any other component of the system involved in auth / persistence

It's just serverless architecture. It may not fit for every project. We use the concept to add meta tags to our client-side-rendered webapp for search indexing. We can decouple our client app from our server and deploy each separately. We use "serverless functions" to add some meta tags that need to be added server-side.

I mean, it's incredibly easy to deploy client apps separately from the server in a lot of ways

To me, the only value I see for Edge compute is when some chunk of data requires processing going one way across the network, and that processing can be done entirely locally. I suppose what you describe with the meta tag qualifies in this case, otherwise I think serverless architecture looks like a pretty sweet deal for the cloud companies promoting it.

Re: Netlify Edge Functions: A new serverless runtime powered by Deno

#36
I would love to jump over to something like Vercel or Netlify Edge, but maddeningly none of these platforms give you control over the cache key. I have pages that are server-side rendered with Cache-Control headers, but because our visitors come with unique tracking params on the end of their URL (e.g. from Mailchimp or Branch), we would essentially have no cache hits.

It seems the only way to have control over this is to write your own Cloudflare Workers. There must be a better way? I can't imagine this is an infrequent problem for people at scale.

Re: Netlify Edge Functions: A new serverless runtime powered by Deno

#37

Earlier quoted context omitted.

Is Netlify running Deno on their edge and not on Deno.com Deploy 's? Is this also what Slack, Vercel (?), and Supabase do?

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.

[0] https://blog.cloudflare.com/mitigating-spectre-and-other-sec...

Re: Netlify Edge Functions: A new serverless runtime powered by Deno

#38
post #36

I would love to jump over to something like Vercel or Netlify Edge, but maddeningly none of these platforms give you control over the cache key. I have pages that are server-side rendered with Cache-Control headers, but because our visitors come with unique tracking params on the end of their URL (e.g. from Mailchimp or Branch), we would essentially have no cache hits. It seems the only way to have control over this…

So far Netlify Edge Functions runs before the cache layer, so you can actually use a minimal function to rewrite the URL to remove all unique params, etc, and then let it pass through our system to a Netlify Function which runs behind our caching layer.

For anything you can do at build time as a static HTML pages we already strip query parameters from cache keys.

Post reply on HN