Call usTry Fastly free

Compute@Edge: the JavaScript support you demanded without cold starts or increased security risks

Until now, developers haven’t been able to write JavaScript and compile it to WebAssembly for Compute@Edge. With so many developers accustomed to using JavaScript, we knew this presented a barrier to entry for Compute@Edge, but we didn’t want to cut corners or suffer tradeoffs between security and performance

When I say tradeoffs, this is what I mean: JavaScript environments (such as V8) have historically suffered from ~5 milliseconds of startup latency at minimum, not including the time it takes to initialize the application. These “cold starts” increase security risk and add latency.

However, today, I’m happy to say that we found a solution to these concerns and that JavaScript is now available for WebAssembly and Compute@Edge. This will help you get started on Compute@Edge faster than ever with a language you already know — while ensuring the speed and security you need in a serverless build environment. Here’s how we brought the most popular computing language to Compute@Edge. 

JavaScript and Compute@Edge

Because the JavaScript engines used to create instances are large codebases, it can be easy for bugs to be introduced that allow attackers to escape the JavaScript virtual machine and get access to the system. This is why browsers like Chrome and Firefox go to great lengths to ensure that sites run in fully separated processes, and advise against treating their in-process sandboxes as security boundaries. 

To bring JavaScript to Compute@Edge, we started by homing in on security. By running the JavaScript virtual machine inside a WebAssembly sandbox, we can provide customers with an outer, more secure boundary as another line of defense. Compute@Edge’s isolation technology creates and destroys a sandbox for each request flowing through our platform in microseconds. This technology holistically minimizes attack surface area while maintaining the ability to scale and perform, and keeps your code completely isolated from other requests flowing through the platform. Other serverless platforms use techniques to hide latency and often reuse instances between requests, which is a security hazard because it results in a larger blast radius for attacks.  

We also took a hard look at performance, because the way we reach high performance in Compute@Edge has a direct impact on the security of the platform. Even though JavaScript environments have historically suffered from measurable startup latency, JavaScript on Compute@Edge takes advantage of zero millisecond cold starts, meaning you have access to 65+ high-performance server clusters, offering scalability and unprecedented computing resources that are at the ready to execute your code. This improves the performance of your application and reduces the attack surface area. The way we run JavaScript (as described on the Bytecode Alliance blog) enables us to use the same new-instance-per-request approach that we do for other languages, where normally that wouldn't be feasible because the combination of creating an instance and initializing the JavaScript running in it would make that prohibitively expensive and slow.

Serverless JavaScript today 

JavaScript is everywhere. Today, more developers use JavaScript than any other programming language. Nearly everyone building a web experience has a JavaScript development background, and although adoption of in-browser WebAssembly is increasing, many web applications still run on JavaScript today. 

We’re pleased to be able to offer this language support on Compute@Edge. Find out more — including how to get going — in our Developer Hub. And if you're not yet using Compute@Edge, sign up now and experience the power of serverless for yourself.

Want to continue the conversation?Schedule time with an expert
Share this post