Learn to build on the Fastly platform
Fastly brings your applications closer to the world - with thousands of servers in data centers across the world, you can count on consistent reliability, security, and exceptional performance.
Domains are hostnames that point to your services on Fastly. Backends are hostnames that point to the origin servers hosting your application. Health checks are pre-configured requests that Fastly POPs should make, to your backends, to confirm that they are ready to receive end user traffic.
Fastly offers two types of edge services: highly performant and configurable delivery services powered by Fastly VCL, and next generation Wasm-powered Compute@Edge services.
- Use VCL-powered delivery services if you want efficient, high performance services that don't require you to write any code (but still offer the flexibility to write your own logic in Fastly VCL)
- Use Compute@Edge if you want the edge service to be an application you can fully manage in the programming language of your choice.
Here is a more detailed comparison of what is available on each platform:
| VCL | Compute@Edge | |
|---|---|---|
| Availability | General availability | General availability |
| Language support | Fastly VCL, a derivative of Varnish Configuration Language | Any language that compiles to WebAssembly (with official support for Rust, JavaScript, and Go) |
| Invocation | Fastly invokes your code at multiple predefined points in the request-response cycle | Your code handles the entire request-response cycle |
| Making backend requests | Requests to statically-defined backends are automatically triggered by client requests (unless aborted by error or restart). | Requests to backends are made explicitly by your edge code using the fetch method of your chosen language SDK. Backends can be defined statically or created at runtime. |
| Caching responses | HTTP cache directives are used by default but caching policy can be modified at the edge. Responses can be inspected and headers and caching decisions can be modified in vcl_fetch before the response is written to cache. No access to response body. | HTTP cache directives alone are used to determine cache policy. Response is only accessible after being written to cache, but can be fully inspected and modified (including the body) before delivery to the client. |
| Common capabilities | Logging, Streaming, Request collapsing, Purging, Serving stale, Edge dictionaries, Geolocation & device detection | |
| Unique capabilities | Clustering Shielding Image optimizer Rate limiting Load balancing Segmented caching Dictionaries and ACLs | General purpose compute Content transformation Async fetch Request composition Parsing and serialization |
| Learn more about VCL > | Learn more about Compute@Edge > | |
Whichever service type you choose, many concepts are common. And while not all Fastly features are supported by Compute@Edge yet, many more will be added in the coming months.
Learning to code on Fastly
Because you can write your own code in a Fastly service, there are an infinite set of tasks you could choose to do at the edge. Start with our onboarding guides for VCL or Compute@Edge, and then try some tutorials or copy some of our code examples.
When you're ready to level up and test your knowledge, try your hand at our code challenges!