Rust/WASM Edge Functions frente a Cloudflare y Vercel Edge

Un aislamiento V8 es un contexto de ejecución de JavaScript liviano dentro del mismo motor V8: no hay nuevos procesos del sistema, no hay un nuevo kernel para iniciar. Este es el mecanismo que Cloudflare hizo público por primera vez para los trabajadores y que Vercel reutiliza para su Edge Runtime. El objetivo es el mismo en ambas partes: evitar el coste de un contenedor o una VM por cada solicitud.

Un módulo WebAssembly satisface la misma necesidad a través de un mecanismo diferente. El código de bytes WASM se ejecuta en una memoria lineal limitada, definida por la propia especificación. El módulo invitado no puede direccionar fuera de esta área, independientemente del idioma de origen (Rust, C, Go…) que produjo el binario. Es este modelo el que aplica Wasmtime en el modo wasm de Aurabase, que se detalla a continuación. Para conocer las mediciones de inicio entre las dos mecánicas, consulte nuestro archivo en los puntos de referencia de arranque en frío de WebAssembly.

Cada función de Aurabase lleva un campo runtime que vale "wasm" o "deno". El motor de invocación elige la ruta de ejecución en consecuencia:

// Despacho según tiempo de ejecución: WASM (wasmtime) o Deno (V8 Aisla vía edge-runtime)
let resp = if func.runtime == "wasm" {
    state.runtime.invoke(&wasm_bytes, &func.code_hash, req).await?
} else {
    // Proxy para aura-edge-runtime: aislamientos V8 (supabase/edge-runtime, MIT)
    proxy_to_edge_runtime(&state.config.edge_runtime_url, …).await?
};

El sandbox se basa en tres mecanismos Wasmtime combinados. Un presupuesto de CPU contado en “combustible”: cada instrucción WASM lo consume. Un tiempo de espera aplicado en incrementos de época: un subproceso dedicado aumenta el reloj Wasmtime después del retraso configurado, lo que interrumpe la ejecución actual. Un límite de memoria establecido a través de StoreLimits. Los tres terminales se configuran cuando se crea una instancia del motor:

let mut cfg = Config::new();
cfg.consume_fuel(true);
cfg.epoch_interruption(true);

// Memoria limitada por StoreLimits, combustible inicial = max_fuel,
// timeout = incremento de época después de timeout_secs (hilo dedicado)

El módulo compilado se almacena en caché mediante code_hash: el mismo binario implementado no se vuelve a compilar en cada llamada. Sin embargo, cada invocación crea una instancia de un nuevo Store y una instancia. Ningún estado se filtra de una llamada a la siguiente. El área de superficie expuesta al módulo invitado sigue siendo deliberadamente mínima, cinco funciones de host en total: aura.log, aura.get_input, aura.set_output, aura.get_env y un código auxiliar env.abort para compatibilidad con AssemblyScript. Ninguna función del host expone las llamadas de red salientes en este momento.

En el lado de la implementación, la CLI compila su caja localmente antes de enviarla: aura functions new estructura una caja cdylib, aura functions deploy la compila y luego la envía.

# Andamio: crea aurabase/functions/<nombre>/ (Cargo.toml crate-type = cdylib)
aura functions new my-fn

# cargo build --target wasm32-unknown-unknown --liberar, luego cargar
# POST /v1/functions/:project_id { tiempo de ejecución: "wasm", código: <wasm en base64> }
aura functions deploy my-fn

Los trabajadores de Cloudflare ejecutan de forma nativa JavaScript y TypeScript en aislados V8 distribuidos en la red global de Cloudflare. WebAssembly ha sido un ciudadano de primera clase desde el inicio de la plataforma: un módulo .wasm se puede importar directamente a un Worker como cualquier otro módulo.

Para escribir un Worker completamente en Rust, la ruta más utilizada es el SDK comunitario workers-rs, que compila el código en wasm32-unknown-unknown y lo ejecuta en el tiempo de ejecución de Workers. La diferencia con el modo wasm de Aurabase es el área de superficie disponible. Un trabajador escrito en Rust a través de este SDK se ejecuta en el entorno de trabajadores completo y, por lo tanto, puede llamar a fetch u otros enlaces de plataforma. El modo wasm de Aurabase comienza desde una superficie de host deliberadamente reducida (sección anterior).

Edge Runtime de Vercel también ejecuta código en aislados V8, con un subconjunto de API web estándar (fetch, Request/Response, crypto.subtle…) en lugar del entorno Node.js completo. Los módulos de nodo nativo y las cadenas de herramientas de compilación arbitrarias no tienen cabida allí.

El objeto WebAssembly es parte de este subconjunto: nada le impide cargar un binario .wasm y crear una instancia de él manualmente desde una función JavaScript o TypeScript. Pero hasta donde sabemos, Vercel no publica ningún SDK o CLI oficial para escribir directamente una función Edge en Rust, a diferencia de workers-rs en el lado de Cloudflare o aura functions deploy en el lado de Aurabase. El camino sigue siendo posible, pero totalmente manual, sin herramientas específicas.

Un aislamiento V8 separa el código ejecutado por un montón dedicado y su propio contexto, dentro del mismo proceso del motor. Es un mecanismo probado, a una escala de millones de solicitudes por segundo en Cloudflare y Vercel, pero que sigue siendo un mecanismo de aislamiento de software dentro de un único motor JavaScript.

El modelo WASM se aísla de manera diferente: cada instancia obtiene su propia memoria lineal, un búfer contiguo fuera del cual no es posible acceder mediante la construcción del formato binario en sí, independientemente del motor que lo ejecuta. En el tiempo de ejecución de Aurabase, cada función de host que manipula un puntero proporcionado por el módulo invitado (aura.log, aura.get_env…) revalida explícitamente los límites antes de cualquier acceso a la memoria. Esta es una defensa adicional en profundidad contra un módulo malicioso o con errores.

Especificaciones del tiempo de ejecución de Aurabase. Las columnas de Cloudflare y Vercel se describen a partir de la arquitectura pública documentada de cada plataforma (aísla V8 y WebAssembly como destino de compilación).

Cálculo puro, sin llamadas de red: validación de esquemas, transformación de datos, puntuación, generación de imágenes ligeras. El modo wasm de Aurabase es adecuado directamente, con una zona de pruebas de memoria estricta, un presupuesto de CPU explícito y sin dependencia de un servicio externo.

Función que llama a una API de terceros (pago, correo electrónico, webhook saliente). El modo deno de Aurabase sigue siendo la opción predeterminada hoy en día, de la misma manera que un Cloudflare Worker clásico o una función Vercel Edge se basan en fetch de forma nativa.

El equipo ya invirtió en el ecosistema de Cloudflare (KV, Durable Objects, R2). Permanecer en Workers tiene sentido; workers-rs te permite introducir Rust gradualmente, sin cambiar de plataforma.

Necesita un tiempo de ejecución nativo de Rust administrado de extremo a extremo, con una CLI dedicada y el mismo lenguaje que el resto del backend. Este es el ángulo que documenta en nuestra comparación Wasmtime vs Wasmer, sobre la elección del motor WebAssembly.