Rust/WASM Edge Functions versus Cloudflare e Vercel Edge

Um V8 isolado é um contexto leve de execução de JavaScript dentro do mesmo mecanismo V8: sem novos processos de sistema, sem novo kernel para iniciar. Este é o mecanismo que a Cloudflare tornou público pela primeira vez para Workers e que a Vercel reutiliza em seu Edge Runtime. O objetivo é o mesmo dos dois lados: evitar o custo de um contêiner ou de uma VM para cada solicitação.

Um módulo WebAssembly atende à mesma necessidade por meio de um mecanismo diferente. O bytecode WASM é executado em uma memória linear limitada, definida pela própria especificação. O módulo convidado não pode endereçar fora desta área, independentemente da linguagem fonte (Rust, C, Go…) que produziu o binário. É este modelo que o Wasmtime aplica no modo wasm do Aurabase, detalhado a seguir. Para medições de inicialização entre as duas mecânicas, consulte nosso arquivo em benchmarks de inicialização a frio do WebAssembly.

Cada função Aurabase carrega um campo runtime que vale "wasm" ou "deno". O mecanismo de invocação escolhe o caminho de execução de acordo:

// Despache de acordo com o tempo de execução: WASM (wasmtime) ou Deno (V8 isola via edge-runtime)
let resp = if func.runtime == "wasm" {
    state.runtime.invoke(&wasm_bytes, &func.code_hash, req).await?
} else {
    // Proxy para aura-edge-runtime — Isolados V8 (supabase/edge-runtime, MIT)
    proxy_to_edge_runtime(&state.config.edge_runtime_url, …).await?
};

A sandbox depende de três mecanismos Wasmtime combinados. Um orçamento de CPU contado em “combustível”: cada instrução WASM o consome. Um timeout aplicado em incrementos de época: um thread dedicado aumenta o relógio Wasmtime após o atraso configurado, o que interrompe a execução atual. Um limite de memória definido por meio de StoreLimits. Os três terminais são configurados quando o mecanismo é instanciado:

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

// Memória limitada por StoreLimits, combustível inicial = max_fuel,
// timeout = incremento de época após timeout_secs (thread dedicado)

O módulo compilado é armazenado em cache por code_hash: o mesmo binário implantado não é recompilado em cada chamada. No entanto, cada invocação instancia um novo Store e uma nova instância. Nenhum estado vaza de uma chamada para outra. A área de superfície exposta ao módulo convidado permanece deliberadamente mínima, cinco funções de host no total: aura.log, aura.get_input, aura.set_output, aura.get_env e um stub env.abort para compatibilidade com AssemblyScript. Nenhuma função de host expõe chamadas de rede de saída neste momento.

No lado da implantação, a CLI compila sua caixa localmente antes de enviar: aura functions new cria uma caixa cdylib, aura functions deploy compila-a e depois a envia.

# Andaime: cria aurabase/functions/<nome>/ (Cargo.toml crate-type = cdylib)
aura functions new my-fn

# cargo build --target wasm32-unknown-unknown --release e, em seguida, carregue
# POST /v1/functions/:project_id { tempo de execução: "wasm", código: <wasm em base64> }
aura functions deploy my-fn

Os Cloudflare Workers executam JavaScript e TypeScript nativamente em isolados V8 distribuídos pela rede global da Cloudflare. WebAssembly tem sido um cidadão de primeira classe desde o início da plataforma: um módulo .wasm pode ser importado diretamente para um Worker como qualquer outro módulo.

Para escrever um Worker inteiramente em Rust, a rota mais utilizada é o SDK da comunidade workers-rs, que compila o código para wasm32-unknown-unknown e o executa no runtime do Workers. A diferença com o modo wasm do Aurabase é a área de superfície disponível. Um Worker escrito em Rust por meio deste SDK é executado no ambiente Workers completo e pode, portanto, chamar fetch ou outras ligações de plataforma. O modo wasm do Aurabase começa a partir de uma superfície de host deliberadamente reduzida (seção anterior).

O Edge Runtime da Vercel também executa código em isolados V8, com um subconjunto de APIs da Web padrão (fetch, Request/Response, crypto.subtle…) em vez do ambiente Node.js completo. Módulos Native Node e conjuntos de ferramentas de compilação arbitrários não têm lugar lá.

O objeto WebAssembly faz parte deste subconjunto: nada impede que você carregue um binário .wasm e instancie-o manualmente a partir de uma função JavaScript ou TypeScript. Mas, até onde sabemos, Vercel não publica nenhum SDK ou CLI oficial para escrever diretamente uma Edge Function em Rust, ao contrário de workers-rs no lado Cloudflare ou aura functions deploy no lado Aurabase. O caminho continua possível, mas totalmente manual, sem ferramentas dedicadas.

Um isolado V8 separa o código executado por um heap dedicado e seu próprio contexto, dentro do mesmo processo do mecanismo. É um mecanismo comprovado, na escala de milhões de solicitações por segundo na Cloudflare e Vercel, mas que continua sendo um mecanismo de isolamento de software dentro de um único mecanismo JavaScript.

O modelo WASM isola de forma diferente: cada instância obtém sua própria memória linear, um buffer contíguo fora do qual nenhum acesso é possível pela construção do próprio formato binário, independentemente do mecanismo que o executa. No tempo de execução do Aurabase, cada função host que manipula um ponteiro fornecido pelo módulo convidado (aura.log, aura.get_env…) revalida explicitamente os limites antes de qualquer acesso à memória. Esta é uma defesa adicional em profundidade contra um módulo malicioso ou com bugs.

Especificações de tempo de execução do Aurabase. Colunas Cloudflare e Vercel descritas a partir da arquitetura pública documentada de cada plataforma (isola V8, WebAssembly como destino de construção).

Cálculo puro, sem chamadas de rede: validação de esquema, transformação de dados, pontuação, geração de imagens leves. O modo wasm do Aurabase é adequado diretamente, com uma área restrita de memória, um orçamento de CPU explícito e sem dependência de um serviço externo.

Função que chama uma API de terceiros (pagamento, email, webhook de saída). O modo deno do Aurabase continua sendo a escolha padrão hoje, da mesma forma que um Cloudflare Worker clássico ou uma função Vercel Edge depende de fetch nativamente.

Equipe já investiu no ecossistema Cloudflare (KV, Durable Objects, R2). Permanecer nos Trabalhadores faz sentido; workers-rs permite introduzir Rust gradualmente, sem alterar plataformas.

Precisa de um tempo de execução Rust nativo gerenciado de ponta a ponta, com uma CLI dedicada e a mesma linguagem do resto do back-end. Este é o ângulo que documenta em nossa comparação Wasmtime vs Wasmer, na escolha do próprio mecanismo WebAssembly.