Rust/WASM Edge Functions vs Cloudflare i Vercel Edge

Ten tekst w języku angielskim został wygenerowany automatycznie na podstawie francuskiego oryginału i nie był jeszcze recenzowany.

Ta strona została przetłumaczona automatycznie. Wersja angielska jest miarodajna.

Jednakże domyślnym trybem Aurabase pozostaje Deno (również V8 Isolate), jak udokumentowano w Rdzeń Rust Aurabase. „Funkcje brzegowe w Rust” obejmują trzy różne rzeczywistości w zależności od platformy: społeczność SDK po stronie Cloudflare, brak oficjalnej trasy po stronie Vercel, natywny tryb wykonywania z własnym CLI po stronie Aurabase. To porównanie szczegółowo opisuje trzy architektury bez mieszania tego, co zostało zweryfikowane, i tego, co pozostaje celem platformy.

Najważniejsze

Aurabase oferuje dwa środowiska wykonawcze Edge Functions: deno (izolacje V8, usługa dedykowana, tryb domyślny) i wasm (skompilowany w języku Rust, uruchamiany natywnie przez Wasmtime).
Cloudflare Workers działają na izolatach V8 i mogą dodatkowo uruchamiać WebAssembly, zwłaszcza za pośrednictwem pakietu SDK społeczności workers-rs. Nie jest to dedykowane, natywne środowisko uruchomieniowe Rusta, takie jak tryb wasm Aurabase.
Vercel Edge Functions opiera się na Edge Runtime, podzbiorze Node.js API w izolowanej wersji V8: nie ma oficjalnego SDK ani CLI do napisania samej funkcji w Rust.
Tryb wasm Aurabase izoluje każde wykonanie z budżetem procesora Wasmtime, limitem dedykowanej pamięci i limitem czasu na epokę, ale obecnie nie udostępnia modułu gościa żadnego wychodzącego dostępu sieciowego.
Trzy różne architektury mające ten sam cel: szybko rozpoczynaj i izolowaj każde wykonanie, bez ponoszenia kosztów kompletnego kontenera.

Kontekst

Izolaty V8 i moduły WASM: dwie mechaniki sandboxingu

Izolat V8 to lekki kontekst wykonawczy JavaScript w tym samym silniku V8: żadnych nowych procesów systemowych, żadnego nowego jądra do uruchomienia. Jest to mechanizm, który Cloudflare po raz pierwszy udostępnił pracownikom i który Vercel wykorzystuje ponownie w swoim środowisku Edge Runtime. Cel jest ten sam po obu stronach: uniknąć kosztów kontenera lub maszyny wirtualnej dla każdego żądania.

Moduł WebAssembly spełnia tę samą potrzebę za pomocą innego mechanizmu. Kod bajtowy WASM działa w ograniczonej pamięci liniowej, określonej w samej specyfikacji. Moduł gościa nie może adresować poza tym obszarem, niezależnie od języka źródłowego (Rust, C, Go…), który wygenerował plik binarny. To właśnie ten model Wasmtime stosuje w trybie wasm Aurabase, szczegółowo opisanym poniżej. Aby zapoznać się z pomiarami rozruchu między dwiema mechanikami, zobacz nasz plik w testach porównawczych zimnego startu WebAssembly.

Środowisko wykonawcze WASM

Jaki tryb Wasm Aurabase działa w środowisku produkcyjnym

Każda funkcja Aurabase zawiera pole runtime o wartości "wasm" lub "deno". Silnik wywołań odpowiednio wybiera ścieżkę wykonania:

runtime/dispatch.rsrust

// Wysyłka zgodnie ze środowiskiem wykonawczym: WASM (wasmtime) lub Deno (izolacja V8 za pośrednictwem środowiska Edge-Runtime)
let resp = if func.runtime == "wasm" {
    state.runtime.invoke(&wasm_bytes, &func.code_hash, req).await?
} else {
    // Serwer proxy dla aura-edge-runtime — izolaty V8 (supabase/edge-runtime, MIT)
    proxy_to_edge_runtime(&state.config.edge_runtime_url, …).await?
};

Piaskownica opiera się na trzech połączonych mechanizmach Wasmtime. Budżet procesora liczony w „paliwie”: zużywa go każda instrukcja WASM. Limit czasu stosowany w przyrostach epoki: dedykowany wątek zwiększa zegar Wasmtime po skonfigurowanym opóźnieniu, co przerywa bieżące wykonanie. Limit pamięci ustawiony za pomocą StoreLimits. Trzy terminale są konfigurowane podczas tworzenia instancji silnika:

runtime/wasm.rsrust

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

// Pamięć ograniczona StoreLimits, początkowe paliwo = max_fuel,
// timeout = przyrost epoki po timeout_secs (dedykowany wątek)

Skompilowany moduł jest buforowany przez code_hash: ten sam wdrożony plik binarny nie jest rekompilowany przy każdym wywołaniu. Niemniej jednak każde wywołanie tworzy instancję nowego Store i instancji. Żaden stan nie wycieka z jednego połączenia do drugiego. Powierzchnia wystawiona na działanie modułu gościa pozostaje celowo minimalna, w sumie pięć funkcji hosta: aura.log, aura.get_input, aura.set_output, aura.get_env i kod pośredniczący env.abort dla zgodności z AssemblyScript. Żadne funkcje hosta nie ujawniają obecnie wychodzących połączeń sieciowych.

Zweryfikowany a cel produktu

Tryb wasm nadaje się teraz do czystych obliczeń: walidacji, transformacji danych, scoringu, analizy. Funkcja, która musi wywołać API strony trzeciej (płatność, e-mail, usługa zewnętrzna) musi nadal przejść przez tryb deno. Jest to tryb domyślny dla Aurabase i tryb zalecany do migracji istniejącego kodu Deno.

Po stronie wdrożenia CLI kompiluje skrzynkę lokalnie przed wysłaniem: aura functions new buduje skrzynkę cdylib, aura functions deploy kompiluje ją, a następnie wysyła.

terminalbash

# Rusztowanie: tworzy aurabase/functions/<nazwa>/ (Cargo.toml crate-type = cdylib)
aura functions new my-fn

# kompilacja ładunku --target wasm32-unknown-unknown --release, a następnie przesłanie
# POST /v1/functions/:project_id { środowisko uruchomieniowe: "wasm", kod: <wasm w base64> }
aura functions deploy my-fn

Cloudflare

Pracownicy Cloudflare: izoluje V8, dodatkowo z WebAssembly

Pracownicy Cloudflare natywnie uruchamiają JavaScript i TypeScript w izolacji V8 rozproszonej w globalnej sieci Cloudflare. WebAssembly jest obywatelem pierwszej klasy od początku istnienia platformy: moduł .wasm można zaimportować bezpośrednio do Workera, jak każdy inny moduł.

Aby napisać Workera w całości w Rust, najczęściej używaną trasą jest społeczność SDK workers-rs, która kompiluje kod do wasm32-unknown-unknown i wykonuje go w środowisku wykonawczym Workers. Różnica w stosunku do trybu wasm programu Aurabase polega na dostępnej powierzchni. Proces roboczy napisany w języku Rust za pośrednictwem tego pakietu SDK działa w pełnym środowisku Workers i dlatego może wywoływać fetch lub inne powiązania platformy. Tryb wasm Aurabase rozpoczyna się od celowo zmniejszonej powierzchni hosta (poprzednia sekcja).

Vercel

Funkcje Vercel Edge: podzbiór Node.js, brak oficjalnej ścieżki Rusta

Vercel's Edge Runtime uruchamia również kod w izolacji V8, z podzbiorem standardowych interfejsów API sieci Web (fetch, Request/Response, crypto.subtle…) zamiast pełnego środowiska Node.js. Nie ma tam miejsca na moduły Native Node i dowolne łańcuchy narzędzi do kompilacji.

Obiekt WebAssembly jest częścią tego podzbioru: nic nie stoi na przeszkodzie, aby załadować plik binarny .wasm i ręcznie utworzyć jego instancję za pomocą funkcji JavaScript lub TypeScript. Jednak według naszej wiedzy Vercel nie publikuje żadnego oficjalnego SDK ani CLI do bezpośredniego pisania funkcji brzegowej w Rust, w przeciwieństwie do workers-rs po stronie Cloudflare lub aura functions deploy po stronie Aurabase. Ścieżka pozostaje możliwa, ale całkowicie ręczna, bez dedykowanych narzędzi.

Bezpieczeństwo

Sandbox: pamięć liniowa WASM kontra izolacja V8

Izolat V8 oddziela kod wykonywany przez dedykowaną stertę i jego własny kontekst w ramach tego samego procesu silnika. Jest to mechanizm sprawdzony w skali milionów żądań na sekundę w Cloudflare i Vercel, pozostający jednak mechanizmem izolacji oprogramowania w ramach jednego silnika JavaScript.

Model WASM izoluje inaczej: każda instancja otrzymuje własną pamięć liniową, ciągły bufor, poza którym nie jest możliwy dostęp poprzez konstrukcję samego formatu binarnego, niezależnie od silnika, który go wykonuje. W środowisku wykonawczym Aurabase każda funkcja hosta, która manipuluje wskaźnikiem dostarczonym przez moduł gościa (aura.log, aura.get_env…) jawnie ponownie sprawdza granice przed jakimkolwiek dostępem do pamięci. Jest to dodatkowa, dogłębna obrona przed złośliwym lub błędnym modułem.

Przegląd

Trzy architektury obok siebie

	Aurabaza (wasm)	Pracownicy Cloudflare	Funkcje krawędziowe Vercela
Model wykonania	Natywny moduł WASM, Wasmtime	Izoluj V8 + WASM jako moduł opcjonalny	Wyizoluj podzbiór V8, Node.js
Rdza na pierwszym planie	Tak, tryb dedykowany + CLI	Za pośrednictwem społeczności SDK (workers-rs)	Nie, nie ma oficjalnej trasy
Dostęp sieciowy wychodzący z modułu	Nie, sprawdziłem kod (brak funkcji hosta sieciowego)	Tak, poprzez pełne środowisko Workers	Tak, standardowe API pobierania
Budżet procesora	Czas zużycia paliwa, konfigurowalny	Limit czasu procesora na żądanie (dokument Cloudflare)	Limit czasu trwania jednego wezwania (dok. Vercel)
Dedykowane wdrożenie Rusta	rozmieszczenie funkcji aury (lokalne budowanie ładunku)	wrangler + pracownicy-rs	Brak oficjalnego równoważnego narzędzia

Specyfikacje środowiska wykonawczego Aurabase. Kolumny Cloudflare i Vercel opisane na podstawie udokumentowanej architektury publicznej każdej platformy (izoluje V8, WebAssembly jako cel kompilacji).

Decyzja

Które środowisko wykonawcze wybrać w zależności od funkcji

Czysta kalkulacja, bez wywołań sieciowych: walidacja schematu, transformacja danych, scoring, lekkie generowanie obrazu. Tryb wasm Aurabase jest odpowiedni bezpośrednio, ze ścisłą piaskownicą pamięci, jawnym budżetem procesora i bez zależności od usługi zewnętrznej.

Funkcja wywołująca zewnętrzne API (płatność, e-mail, wychodzący webhook). Tryb deno Aurabase pozostaje dziś domyślnym wyborem, w taki sam sposób, w jaki klasyczny Cloudflare Worker lub Vercel Edge Function natywnie opierają się na fetch.

Zespół zainwestował już w ekosystem Cloudflare (KV, Durable Objects, R2). Pozostanie w programie Workers ma sens; workers-rs pozwala na stopniowe wprowadzanie Rusta, bez zmiany platformy.

Potrzebujesz natywnego, kompleksowo zarządzanego środowiska uruchomieniowego Rust, z dedykowanym interfejsem CLI i tym samym językiem, co reszta backendu. Jest to kąt, który dokumentuje w naszym porównaniu Wasmtime i Wasmer, w zależności od wyboru samego silnika WebAssembly.

Często zadawane pytania

Często zadawane pytania

Czy możesz pisać funkcje krawędziowe Aurabase w Rust?+

Tak, w trybie Wasm. Interfejs CLI będzie miał funkcje nowego rusztowania i skrzynki Rust (cdylib typu skrzyni). Polecenie aura Functions Deploy kompiluje je lokalnie za pomocą cargo build --target wasm32-unknown-unknown --release, następnie wysyła plik binarny do usługi aura-functions, która uruchamia go natywnie ze środowiskiem wykonawczym Wasmtime. Nie jest to tryb domyślny: domyślnie funkcja brzegowa Aurabase działa w języku JavaScript/TypeScript (środowisko wykonawcze Deno, izolacje V8).

Czy Cloudflare Workers naprawdę pozwalają na pisanie funkcji w Rust?+

Tak, ale pośrednio: Cloudflare Workers natywnie wykonuje JavaScript/TypeScript w izolatach V8. Pakiet SDK społeczności workers-rs umożliwia skompilowanie całego Workera w Rust do WebAssembly, ale nie jest to najbardziej oficjalnie udokumentowana droga. WASM uzupełnia tam Robotnika, zamiast całkowicie zastępować model JS.

Czy Vercel Edge Functions obsługuje natywnie WebAssembly lub Rust?+

Środowisko wykonawcze Vercel Edge udostępnia standardowe interfejsy API sieci Web, w tym obiekt WebAssembly, dzięki czemu moduł .wasm można załadować i utworzyć ręcznie za pomocą funkcji JavaScript/TypeScript. Jednak według naszej wiedzy Vercel nie publikuje żadnego oficjalnego SDK ani CLI do pisania funkcji brzegowej bezpośrednio w Rust, w przeciwieństwie do workers-rs po stronie Cloudflare lub funkcji aury wdrażanych po stronie Aurabase.

Czy tryb Wasm Aurabase może wywoływać interfejs API strony trzeciej (płatność, e-mail itp.)?+

Nie dzisiaj: funkcje hosta udostępniane modułowi gościa WASM to dziennik, odczytywanie żądania wejściowego i zapisywanie odpowiedzi wyjściowej, a także odczytywanie zmiennych środowiskowych. W przypadku funkcji, która musi wywołać zewnętrzne API (pobieranie sieci), zalecaną ścieżką jest środowisko uruchomieniowe Deno (domyślne).