JavaScript support hits 1.0 milestone on Compute@Edge

When Compute@Edge was launched, we talked about why we didnt fully support JavaScript at that time. Support was added in July last year, and it has been an exciting journey to see what people have already built with the SDK at scale. With confidence in its stability we are proud to announce a 1.0 release of our JavaScript SDK.

We listened to the community feedback, filled in feature gaps, and addressed many bugs in the SDK. Not only that, weve also overhauled the SDK reference docs making it easier for you to know whats supported and how to implement the features. All the Fastly specific features of the JS SDK now have interactive example applications in the documentation.

We've also been building out example code on our developer hub to showcase how to use JavaScript to address common use cases. Take a look at examples like geo-tagging of requests, capturing and aggregating log data from clients, normalizing requests to improve cache efficiency, or load balancing across multiple backends.

Want to deploy a site you've built using a JavaScript-based web framework? We got you - check out our tools and instructions for Gatsby and Next.JS. RemixJS is coming soon.

What if you have a dynamic backend in NodeJS running ExpressJS? It'd be cool if Compute@Edge offered Express-like abstractions, so you can write server apps on Fastly using familiar constructs like route handlers and middleware. No problem! Check out Expressly, our Express-alike server framework at the edge!

There are blogs and tutorials to inspire you if you're after something more advanced too: learn more about using JavaScript for A/B testing, or create a waiting room to handle traffic surges, for example.

Our support for JavaScript is unique

In the serverless world, cold starts are the enemy. Even if a platform can run your code fast 99% of the time, an occasional 300ms delay while your app starts up can create debugging headaches, and these can easily add together in a microservices architecture and lead to much more frequent poor performance for end users. At Fastly, we don't have cold starts because we don't do warm starts: your code starts from the same state on every request, and that startup takes microseconds. My colleague Lin Clark has explored how we do this over on the Bytecode Alliance blog.

Speaking of which, as a founding member of the Bytecode Alliance, we're building an ecosystem of languages that can run on the server using WebAssembly, using the Wasmtime runtime.

For JavaScript we use SpiderMonkey on top of Wasmtime, which provides spatial and temporal separation between concurrent tasks. Spatially, each request gets its own language runtime and memory heap. Temporarily, there is no state left over from previous requests. Starting from a fresh identical snapshot on every request makes debugging significantly easier. A bug in one task cannot affect subsequent or neighboring tasks.

Future of JavaScript on Compute@Edge

Weve solved the biggest security headaches of secure sandboxing, and have unmatched initialization performance of startup times, from cold, in the tens of microseconds. With the v1 release of our SDK we have achieved sufficient feature support in JavaScript while providing execution performance that is within a reasonable margin of modern JS JITs. But we're going to make it even faster, so stay tuned.

Not JUST JavaScript

And because our platform doesn't rely on a JavaScript engine at its core, you're not locked into one language - write JavaScript if you want to, but if you need the robustness of strict static typing and lower level memory management, you could just as well use Rust or Go instead. And developers outside of Fastly have even made SDKs for languages we don't officially support yet: we celebrate them and showcase them on our developer hub. All languages that run on Compute@Edge are equals on our platform.

We love to see what our customers build. Find us on twitter at @fastlydevs or tweet with #builtonfastly and let us know!