Learn to build on the Fastly platform
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:
| 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 SDK support for Rust, AssemblyScript, and JavaScript) |
| Invocation | Fastly invokes your code at multiple predefined points in the request-response cycle | Your code handles the entire request-response cycle |
| Commmon capabilities | Edge caching, Logging, Streaming, Request collapsing, Purging, Serving stale, Edge dictionaries, Geolocation & device detection | |
| Unique capabilities | Clustering Shielding Image optimizer Rate limiting Per-response cache settings | 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 as we move towards general availability.
Core concepts
Domains are hostnames that point to your services on Fastly. Backends are hostnames that point to the origin servers hosting your application. Healthchecks are pre-configured requests that Fastly POPs should make, to your backends, to confirm that they are ready to receive end user traffic.
Domains, backends, and healthchecks can be configured in multiple ways:
| Domains | Backends | Healthchecks | |
|---|---|---|---|
Using the fastly CLI | fastly domain create | fastly backend create | fastly healthcheck create |
| Using the API | Create domain endpoint | Create backend endpoint | Create healthcheck endpoint |
| Using VCL | Cannot be managed in VCL | backend { ... } declaration | Part of a backend { ... } declaration |
| Using the web interface | See Managing domains | See Managing origins | See Working with health checks |
Content served through Fastly is cached based on freshness rules you define in Cache-Control headers, or in the configuration of your Fastly service. Within each Point of Presence (POP), many servers act together in a cluster to provide a single large, efficient pool of cache storage.
Fastly POPs operate independently of each other and forward requests to your origin server if a request cannot be satisfied in that POP. Similar requests arriving at the same time in the same POP are collapsed and only one is forwarded. However, using shielding you can opt to focus all origin requests from across the Fastly network to a single Fastly POP, greatly reducing origin traffic, especially if your customers are spread globally.
Our purging system allows objects previously cached by Fastly to be marked stale or invalidated entirely. Globally purging an object takes around 150ms.
For more information on the key mechanisms that make up Fastly, learn more about core concepts.
Dynamic configuration, data storage and caching
Our edge cloud stores data which is accessible to your Fastly services.
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!