Belajar WebAssembly - Edge Functions & Serverless (FaaS)

#Pendahuluan

Setelah di episode 11 kita mengenal runtime server-side — pada episode ini kita membawa Wasm ke tempat ia benar-benar bersinar: edge computing dan serverless (FaaS). Inilah alasan paling praktis mempelajari Wasm pada 2026 — platform edge besar mengadopsinya sebagai fondasi eksekusi fungsi.

Mengapa Wasm begitu cocok di edge? Karena serverless butuh cold start yang sangat cepat — fungsi harus mulai merespons dalam milidetik, bukan detik. Wasm dikompilasi dan divalidasi jauh lebih cepat daripada mem-boot container, binary-nya kecil, dan sandbox-nya aman untuk multi-tenant. Kombinasi ini membuatnya menjadi engine pilihan untuk fungsi di edge.

#Platform Edge Berbasis Wasm

Perbedaan kunci antar platform ada pada kontrak fungsi: Cloudflare Workers memakai API ala Service Worker (fetch handler), sementara Fastly Compute menjalankan modul WASI yang mengekspor handler sendiri.

#Cloudflare Workers: contoh pola

Di Cloudflare Workers, fungsi dipanggil sebagai handler fetch. Untuk Wasm, kalian mengekspor fungsi dan memanggilnya dari handler:

use worker::*;
 
#[event(fetch)]
pub async fn main(req: Request, env: Env, ctx: Context) -> Result<Response> {
    let url = req.url()?;
    let nama = url.path().trim_start_matches('/');
 
    let pesan = format!("Halo, {nama}! Dari edge WebAssembly.");
    Response::ok(pesan)
}

Deploy ke Cloudflare:

npx wrangler deploy

Worker ini berjalan di ratusan data center Cloudflare sekaligus — request dari Jakarta diproses di lokasi terdekat, bukan di satu region pusat. Inilah janji edge computing: latensi rendah karena komputasi didekatkan ke pengguna.

#Fastly Compute: modul WASI murni

Fastly Compute menjalankan modul Wasm/WASI secara langsung — tidak ada layer JS Service Worker. Handler didefinisikan dalam bahasa host kalian:

use fastly::http::StatusCode;
use fastly::{Request, Response};
 
#[fastly::main]
fn main(req: Request) -> Result<Response, fastly::Error> {
    let body = format!(
        "Edge computing dengan WASI! UA: {}",
        req.get_header_str("user-agent").unwrap_or("-")
    );
    Ok(Response::builder()
        .status(StatusCode::OK)
        .body(body)
        .unwrap())
}

Karena berjalan di Wasmtime dengan WASI, modul Fastly bisa memakai sistem I/O async WASI 0.3 — stream request dan response yang efisien.

#Streaming Response

Salah satu pola edge yang paling berguna adalah streaming: mengirim response secara bertahap, bukan menunggu seluruh payload selesai. Untuk file besar atau real-time updates:

use fastly::streaming_body::{StreamingBody, BodyError};
 
fn stream_text() -> Result<(), BodyError> {
    let mut body = StreamingBody::new();
    body.write_str("bagian 1")?;
    body.write_str(" — lanjutan dikirim saat data tersedia")?;
    Ok(())
}

Dengan WASI 0.3, stream bukan lagi emulasi — ia adalah tipe stream<u8> native yang mengalir di antara komponen, HTTP server, dan client (detail di episode 17).

#Stateless vs Stateful di Edge

#Stateless (rekomendasi default)

Fungsi tidak menyimpan state di memori; semua data persisten disimpan di layanan eksternal:

• Cloudflare KV / D1 / R2 — key-value, SQLite, dan object storage.
• Redis / object storage di platform lain.

Keuntungan: mudah diskalakan horizontal, tidak ada masalah konsistensi antar instance.

#Stateful (Durable Objects)

Cloudflare Durable Objects memungkinkan fungsi memegang state deterministik di satu lokasi — seperti singleton yang hidup selama workflow berlangsung. Cocok untuk koordinasi WebSocket, workflow, atau counter terdistribusi. Kita bedah pola state management lebih dalam di episode 18.

#SpinKube: Wasm di Kubernetes

SpinKube membawa Spin ke Kubernetes: operator + runtime yang menjalankan aplikasi Spin sebagai pod yang lebih ringan. Alih-alih container berisi OS penuh, pod memuat modul Wasm yang dijalankan runtime Wasmtime — hasilnya image yang jauh lebih kecil dan startup jauh lebih cepat.

helm install spin-operator spin/operator --namespace spin-system
kubectl apply -f - <<EOF
apiVersion: core.spinoperator.dev/v1
kind: SpinApp
metadata:
  name: hello-spin
spec:
  image: ghcr.io/devvnull/hello-spin:1.0
  replicas: 3
EOF

Bayangkan perbandingannya: image container Node.js sekelas ratusan MB; image Spin + modul Wasm biasanya di bawah 10 MB, dengan cold start ~milidetik. Inilah argumen "Wasm menggantikan container untuk workload ringan" yang kita evaluasi kritis di episode 22.

#Common Pitfalls

• File besar di edge — payload besar lewat body worker; jangan simpan state besar di memori worker.
• Salah mengasumsikan region — edge functions tidak punya "rumah"; jangan menaruh state di memori instance.
• Cold start tetap ada — meski cepat, hitungan ms masih terasa untuk warm-up; ukur dengan real observability, bukan tebakan.
• Sempitnya quota — baca batas CPU, memori, dan waktu eksekusi tiap platform sebelum mendesain workload.

#Penutup

Pada episode 12 ini, kalian telah memahami peran WebAssembly di edge computing dan serverless.

Inti yang harus dibawa pulang:

• Cloudflare Workers, Fastly Compute, Akamai EdgeWorkers, dan Spin memakai Wasm sebagai engine fungsi edge.
• Cold start ~milidetik dimungkinkan karena Wasm kecil, cepat dikompilasi, dan aman multi-tenant.
• Pola HTTP handler dan streaming response adalah bread-and-butter edge functions.
• Default stateless; gunakan KV/object storage, dan Durable Objects hanya saat perlu stateful.

Di episode 13 selanjutnya kita akan membahas data & binary processing — codec dan image/video transcoding dengan wasm, parse/serialize binary dengan serde, pemanfaatan SIMD, dan caching WebAssembly.Module dengan compileStreaming. Sampai jumpa di episode 13!