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:
|Availability||General availability||General availability|
|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 backends are automatically triggered by client requests (unless aborted by ||Requests to backends are made explicitly by your edge code using the fetch method of your chosen language SDK|
|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 ||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|
Dictionaries and ACLs
|General purpose compute|
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.
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:
|Using the ||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||Part of a |
|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.
For more information on the key mechanisms that make up Fastly, learn more about core concepts.
Our edge cloud stores data which is accessible to your Fastly services.
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!