Fastly Compute: edge de alto rendimiento con WebAssembly

Actualizado: 2026-05-03

Fastly Compute^[1] (antes Compute@Edge) es la apuesta de Fastly por el edge computing serio. Mientras Cloudflare Workers usa isolates V8 y un ecosistema JavaScript maduro, Fastly apostó por WebAssembly puro sobre su propio runtime Lucet/Wasmtime. Dos filosofías distintas con implicaciones de rendimiento, portabilidad y ergonomía. Este artículo compara honestamente ambas y explica cuándo Fastly es la elección correcta.

La apuesta técnica de Fastly

Fastly no construyó un runtime JavaScript propio ni se apoyó en Node. Optó por WebAssembly como target universal:

• Tu código (Rust, Go, AssemblyScript, JS vía Javy) compila a .wasm.
• Fastly despliega el binary a sus ~70 PoPs globales.
• Cada request invoca una instancia efímera del módulo Wasm.
• Cold start: 35 microsegundos (μs, no ms) — Fastly lo usa como argumento central de marketing.

El número es real pero merece contexto: Workers también tiene cold start sub-5ms. La diferencia de 1ms→35μs no es visible para el usuario final; pero sí permite ejecutar miles de funciones por request sin overhead acumulativo.

Lenguajes soportados

Oficialmente son cuatro:

• Rust: ciudadano de primera clase. Tooling más maduro (fastly crate), documentación más completa.
• JavaScript: soporta subset de JS + TypeScript, ejecutado vía Javy^[2] — JS → Wasm ahead-of-time.
• Go: soportado vía TinyGo. Limitaciones respecto a Go estándar.
• AssemblyScript: subset de TypeScript que compila directo a Wasm.

Para proyectos nuevos, Rust es la recomendación. Para equipos JS puros, el soporte es bueno pero no alcanza la ergonomía de Workers, donde el ecosistema npm está mucho más integrado.

Modelo de ejecución

El ciclo de vida de cada request en Fastly Compute:

1. Llega al PoP más cercano al usuario.
2. Se instancia el módulo Wasm (35μs de cold start).
3. Se ejecuta el handler con acceso a request/response/stores.
4. Se destruye la instancia — ejecución stateless por defecto.
5. Se envía la respuesta al cliente.

No hay estado compartido entre requests dentro del mismo proceso. Fastly prioriza determinismo y aislamiento fuerte sobre conveniencia de estado.

Hello world en Rust

use fastly::http::{Method, StatusCode};
use fastly::{Error, Request, Response};

#[fastly::main]
fn main(req: Request) -> Result<Response, Error> {
    match (req.get_method(), req.get_path()) {
        (&Method::GET, "/") => Ok(Response::from_status(StatusCode::OK)
            .with_body("Hola desde Fastly Compute")),
        _ => Ok(Response::from_status(StatusCode::NOT_FOUND)),
    }
}

Deploy con un solo comando:

fastly compute publish

El workflow CLI es pulido: builds locales, preview deployments y rollback, todo con fastly. Para el contexto de WebAssembly como estándar más amplio, ver WebAssembly y componentes y WASI preview 2.

Fastly Compute vs Cloudflare Workers

Comparación honesta:

Para código intensivo en cómputo en Rust/Go, Fastly rinde mejor. Para apps JS/TS con ecosystem npm, Workers es más productivo. Cloudflare tiene ventaja clara en número de PoPs y precio de entrada.

Dónde Fastly gana de forma clara

Escenarios donde Fastly es la elección natural:

• Código Rust portable: si ya tienes lógica crítica en Rust, portarla es natural y sin overhead de traducción a JS.
• Compliance y control enterprise: Fastly tiene una reputación más madura en regulación y enterprise.
• Integración con Fastly CDN: para clientes ya en Fastly, Compute es la evolución natural sin añadir proveedor.
• Performance predecible: el cold start sub-milisegundo importa para workloads de alta concurrencia donde se lanzan muchas funciones por request.
• Edge personalizado serio: A/B tests complejos con lógica determinística, rewriting de HTML, transformaciones de imagen.

Dónde Workers gana

Por contra, Cloudflare Workers domina en:

• Ecosystem JS: packages de npm con adaptaciones funcionan directamente.
• Durable Objects + KV + D1: Workers tiene más primitivas listas.
• Precio de entrada: empezar es 10x más barato.
• Cobertura geográfica: ~300+ PoPs vs ~70.
• Comunidad y ejemplos: más recursos públicos disponibles.

Casos de uso comunes con Fastly

Patrones que se repiten en producción:

• API gateway: validar auth, transformar requests, rutear según feature flags.
• Optimización de imágenes: redimensionar y optimizar on-the-fly en el edge.
• Rewriting HTML: inyectar banners de consentimiento o contenido personalizado.
• A/B testing: split traffic con lógica determinística basada en headers o cookies.
• Geo-based routing: servir contenido distinto según país o región.

Para contenido estático puro, un CDN convencional basta. Compute es para lógica que necesita vivir en el borde, reduciendo round-trips al origen.

Costes realistas

Fastly Compute:

• Plan Essential: $50/mes incluye 1M requests.
• Requests adicionales: $0.50 / 1M.
• Tiempo de cómputo: cargo separado por milisegundos usados.

Cloudflare Workers:

• Free: 100k requests/día.
• Paid: $5/mes incluye 10M requests.
• Adicionales: $0.30 / 1M.

Para cargas bajas, Workers es claramente más barato. Para cargas altas con lógica compleja, Fastly puede ser competitivo gracias a la eficiencia del runtime Wasm.

Limitaciones actuales

Seamos honestos sobre los puntos débiles:

• Tamaño del binary limitado (~100 MB). Para apps grandes compiladas a Wasm puede quedarse corto.
• Tiempo máximo por request: ~60s.
• Sin WebSockets persistentes nativos: Workers Durable Objects gana aquí.
• Debugging limitado: los stack traces Wasm no son tan claros como las devtools de JS.
• Menos ejemplos y contexto comunitario que Workers.

WebAssembly en edge: la tendencia

Más allá de Fastly, el patrón Wasm+edge se está consolidando:

• Cloudflare tiene Workers for Platforms con soporte Wasm opcional.
• wasmer-edge apuesta por edge Wasm distribuido.
• shuttle.rs ofrece Rust full-stack con deploy edge.

Fastly fue pionero en este espacio; otros lo están siguiendo. La tendencia es real independientemente de qué plataforma uses.

Conclusión

Fastly Compute es una apuesta técnica seria por WebAssembly en el edge. Para workloads intensivos en cómputo, lógica compleja en Rust o equipos ya en Fastly CDN, es la opción más rendidora. Para el caso medio de “edge lógica JS con ecosystem npm y precio de entrada bajo”, Cloudflare Workers sigue siendo más práctica. La elección no es ideológica — es de contexto: qué lenguaje, qué equipo, qué escala, qué compliance.

1. Fastly Compute
2. Javy