1. Home
2. Guides
3. Compute
4. Developer guides

When building for the Compute platform, you have several options to test and debug your application:

• Deploy to a live service: If you need the full functionality of the Compute platform, you can deploy to a Fastly-hosted service andmonitor logs in your console.
• Run a local test server: If you need to develop rapidly or work offline, you can run your application with thelocal testing server.
• UseFastly Fiddle: If you are prototyping your application or experimenting with Fastly Compute, you can use Fiddle to create ephemeral Fastly services, and writetest assertions against their instrumentation data.

Live log monitoring in your console

During development it can be helpful to deploy your application to the Compute platform usingfastly compute deploy and interact with it using a*.edgecompute.app domain (or other testing domain that you attach to the service). To make debugging easier, theFastly CLI also provides afastly log-tail command that allows you to watch your service'sstdio output from your local console.

Any output sent tostdout andstderr will be forwarded to your console, along with runtime errors encountered by the application. To see log tailing in action, add someprintln! statements to thedefault starter kit for Rust:

usefastly::http::StatusCode;
usefastly::{mime,Error,Request,Response};
#[fastly::main]
fnmain(req:Request)->Result<Response,Error>{
// Log request path to stdout.
println!("Request received for path {}", req.get_path());
Ok(Response::from_status(StatusCode::OK)
.with_content_type(mime::TEXT_HTML_UTF_8)
.with_body("<iframe src='https://developer.fastly.com/compute-welcome' style='border:0; position: absolute; top: 0; left: 0; width: 100%; height: 100%'></iframe>\n")
)
}

Build and deploy the application withfastly compute publish, then runfastly log-tail to see log output from the live service streaming into your console:

$ fastly log-tail
INFO: Managed logging enabled on service PS1Z4isxPaoZGVKVdv0eY
stdout | d81ad0e4 | Request received for path /
stdout | f00dfcda | Request received for path /favicon.ico

Constraints and limitations

The following limits apply to the use of log tailing:

Other limitations apply tologging in general.

Using log endpoints

Data sent tonamed log endpoints is not included inlog tailing output. In production, the best way to get logs out of your application is with one of our manylogging integrations, which support batching and high volumes as part of the Real Time Logging feature.

If you wish to retain the capability to debug your service using log tailing once it is serving production traffic, it's important that you do not log on every request, since you may generate more output than can be practically streamed to your local machine (seeconstraints and limitations). Consider switching the log destination based on a simple request flag such as a cookie:

usefastly::http::StatusCode;
usefastly::{mime,Error,Request,Response};
#[fastly::main]
fnmain(req:Request)->Result<Response,Error>{
log_fastly::init_simple("my_endpoint_name",log::LevelFilter::Warn);
ifletSome(cookie_val)= req.get_header("Cookie"){
if cookie_val.to_str().unwrap_or("").contains("key=some-secret"){
println!("This will go to stdout and be available for log tailing");
}
}
log::warn!("This will be written to the log endpoint...");
Ok(Response::from_status(StatusCode::OK)
.with_content_type(mime::TEXT_HTML_UTF_8)
.with_body("<iframe src='https://developer.fastly.com/compute-welcome' style='border:0; position: absolute; top: 0; left: 0; width: 100%; height: 100%'></iframe>\n")
)
}

Running a local testing server

With thefastly compute serve command, you can run a local development server that behaves like the Fastly platform. Much like a Fastlyservice, the development server can be configured with backends.

Features

See thelocal testing section of thefastly.toml reference for all of the available configuration parameters. The following compute platform features are emulated in the local development server:

Starting the server

Once you have defined your resources in thefastly.toml file, runfastly compute serve to start the testing server:

$ fastly compute serve
✓ Initializing...
✓ Verifying package manifest...
✓ Verifying local rust toolchain...
✓ Building package using rust toolchain...
✓ Creating package archive...
SUCCESS: Built rust package carpet-room (pkg/carpet-room.tar.gz)
✓ Initializing...
✓ Checking latest Viceroy release...
✓ Checking installed Viceroy version...
✓ Running local server...
Jul 16 12:51:52.346  INFO checking if backend 'example_backend' is up
Jul 16 12:51:52.546  INFO backend 'example_backend' is up
Jul 16 12:51:52.546  INFO Listening on http://127.0.0.1:7676

Open a web browser and go tohttp://127.0.0.1:7676 to see your Compute application served by your own machine. Check the console to see both stdio and log endpoint output from your application.

Detecting whether code is running under a local environment

In the local server, the value ofFASTLY_HOSTNAME is always "localhost", which can be used to determine that your code is executing locally rather than on the live Compute platform.

letLOCAL=std::env::var("FASTLY_HOSTNAME").unwrap()=="localhost";
ifLOCAL{
println!("I'm testing locally");
}

Constraints and limitations

The local server is developed and maintained in parallel to our compute platform, and while it is not intended to be a perfect replica of the Fastly platform, features are regularly added to allow testing as much of the functionality of a Compute program as possible. TheFastly CLI will keep your local server instance up to date automatically as new features become available.

The following limitations apply to the current version of the local server:

• There is no readthrough cache, so backend responses that would ordinarily be cacheable, will not be stored.
• Data written to named log endpoints will not be routed to those endpoints but instead will be emitted tostdout, along with any output generated by code that prints to stdio directly.
• Requests made to the local server do not transit Fastly's routing infrastructure and as a result differ in a few ways:
  • Requests that would normally be rejected, for example for exceeding our platform limit on URL length, may instead reach your code.
  • Outbound response filters triggered by headers, such asX-Compress-Hint, are not available.
• Requests made from the local server to backends also differ as a result of not transiting Fastly's routing infrastructure:
  • Additional headers normally appended by Fastly such asCDN-Loop,Fastly-FF andX-Varnish are not added
• TLS information about the client connection is not available.
• MostCompute environment variables are not available. The following are defined:
  • FASTLY_HOSTNAME: Always set to "localhost"
  • FASTLY_TRACE_ID: An ID starting from 0 and incrementing with each incoming request, providing each instance with its own unique ID