You can now test Compute code in Fastly Fiddle

Fastly customers have been using our Fiddle tool for years to try out ideas for edge logic in VCL. With the advent of Compute, we made our edge compute network accessible to any language that compiles to WebAssembly, and now you can write Compute code in Fiddle too.

Compute, now available to all, is a big change from VCL in many ways — and our approach to Fiddle is totally different. We already offer a local server you can run on your own machine to test Compute programs, so the first difference is in the reason why Fiddle is useful.

Why a fiddle tool for Compute

Even with the ability to test code locally, there are still lots of reasons to love having a Fiddle tool for Compute. One of the best is that example code you see on developer.fastly.com can be executed right there in the documentation. Or in a blog post. Like this one! Click RUN below to see it happen right now:

Besides allowing you to try out code examples instantly, Fiddle is also a great tool for sharing. Our exceptionally talented and tenacious support team loves helping customers who can share their problems or questions in the form of a fiddle, and will often fire back solutions and ideas using Fiddle too. The built-in linting and instant feedback you get with Fiddle ensures that shared code does what you think it does, and avoids wasting time caused by copy/paste mistakes or misplaced semicolons.

Compute code is different

The use cases may be largely the same, but the code structure of Compute is very different from VCL. VCL services use a state machine that allows customer code to run in a number of predefined 'subroutines' — like windows or hooks, providing access to the request and response cycle at various stages. If you write zero VCL code, your service will still work, it just performs as a standard caching reverse proxy. In contrast, Compute programs have a single entry point and you're responsible for the entire request-response cycle. If you write zero Compute code, your service won't activate.

To accommodate this, If you choose a non-VCL language in Fiddle, you'll see the familiar VCL subroutine boxes disappear to be replaced with a single field called 'MAIN'. This is where you write all your code. Since Compute requires at least a minimal amount of code to work, we pre-populate your fiddle with a simple boilerplate program. It works, too, so if you want, just choose your preferred language and press RUN. One of the most important design goals of Fiddle is that you start with a working configuration in a single click. There's no tedious setup, so you can start iterating right away.

If you're familiar with using Fastly Fiddle for VCL, you'll know that when you run a request, we display a bunch of instrumentation that shows you how your request was processed by our cache servers, including the VCL subroutines that were executed. In the Compute world, things need to be a bit different.

Instrumenting Compute

Some things that happen when Fastly processes a request are the same for Compute as they are for VCL. You'll still see:

• The client request and response

• Any origin requests and responses

• Any content emitted to a log endpoint (including, in the case of Compute, stdout and stderr)

However, we can't show you 'subroutines' because there aren't any. Instead, we can show you instance events, which in most cases means instance started and instance terminated.  You'll see these show up in an exciting new green hue:

Most excitingly though, we can show you host calls, the invocations your code makes to trigger behaviors outside of the Wasm runtime like forwarding a request to an origin server. VCL services don't really make host calls because they already run as native code, with security and safety guaranteed by the VCL compiler. In Compute, the security guarantees offered by Wasm result in a side benefit: we can see and instrument when the service makes a call to a resource outside the program.  

In Fiddle, we've started to integrate hostcalls with support for geolocation lookups:

We expect to expand this in the coming months to report on dictionary and ACL lookups, and cache interactions — things that we weren't able to instrument effectively in VCL programs.

Specifying dependencies

One major difference between VCL and Compute is that Compute programs may have dependencies on imported packages. VCL has never allowed user-defined imports. In Compute, imports declared in your package manifest are built into the program at compile time, but for security reasons Fiddle can't let you import anything on crates.io or npm. Right now, we have defined a set of the most commonly used dependencies (listed in our developer hub for JavaScript and Rust), and you can use any of these in your code. This is a similar approach to that used by tools like Rust Playground.

We love the approach used by Runkit, which allows any npm module to be added to a sketch by simply requiring it or importing it as if it's already in your project. However, doing something like that requires language-specific parsing, which we will try to avoid to maximize compatibility with the widest range of languages.  We're continuing to iterate on this and better support for more dependencies is coming soon.

In the meantime, Compute Fiddle can already be used to demonstrate many hundreds of use cases.

Give it a try

If that all sounds interesting, why not give it a try? And if you're not yet using Compute for real, sign up now and experience the power of serverless. We recently launched a free trial to give you the opportunity to try it out without commitment.