Use Cases & When to Use Wasm

WebAssembly ไม่ใช่ค้อนที่มองหาตะปู แต่โดดเด่นในสถานการณ์เฉพาะและเพิ่มความซับซ้อนโดยไม่จำเป็นในสถานการณ์อื่น บทเรียนนี้ map use case จริงและให้ decision framework แก่คุณ

Use case 1: ระบบ Plugin

แอปพลิเคชันจำนวนมากต้องการพฤติกรรมที่ผู้ใช้ขยายได้ — เช่น IDE extension, game mod, data-pipeline transform หรือ CI/CD step executor โดยทั่วไปหมายถึงการฝัง scripting language (Lua, Python, JavaScript) พร้อมปัญหาด้านความปลอดภัยและ versioning

ด้วย Wasm + WASI คุณสามารถ:

รับ plugin ที่เขียนด้วย ภาษาใดก็ได้ (Rust, Go, C, AssemblyScript)
รันใน sandbox ที่เข้มงวด — ไม่มี filesystem, ไม่มี network เว้นแต่คุณจะ grant
โหลด, unload และ version ขณะ runtime โดยไม่ต้อง restart host

Projects ที่ใช้ pattern นี้: Envoy (filter plugin), Zellij (terminal multiplexer plugin), Shopify (checkout extension), Extism (plugin SDK)

Use case 2: Edge และ Serverless

แพลตฟอร์ม edge เช่น Cloudflare Workers, Fastly Compute และ Fermyon Spin รัน Wasm module บนเครือข่าย PoP ทั่วโลก ข้อได้เปรียบหลักเทียบกับ container:

Cold start เป็น microsecond — ไม่มี OS process, container runtime หรือ JVM
Isolation ที่แข็งแกร่ง — แต่ละ request ได้ Wasm instance ของตัวเอง
Footprint เล็ก — Wasm module มีขนาด kilobyte ไม่ใช่ megabyte

# Deploy Rust function ไปยัง Fermyon Spin
spin new --template http-rust my-api
cd my-api
spin build
spin deploy

Use case 3: การรัน code ที่ไม่น่าเชื่อถือแบบ sandbox

Online code judge, notebook runner (เช่น WasmRunner ในคอร์สนี้เอง), CI step isolation และ customer-defined logic ใน SaaS ล้วนต้องการรัน arbitrary code อย่างปลอดภัย

Sandboxed memory model ของ Wasm รับประกัน:

module ไม่สามารถเข้าถึง host memory นอก linear memory ของตัวเอง
module ไม่สามารถทำ arbitrary syscall — เฉพาะ WASI import ที่รันไทม์เปิดเผย
module ไม่สามารถสร้าง thread หรือ process ด้วยตัวเอง

ทำให้ Wasm เป็น sandbox ที่ปลอดภัยและเบาที่สุดที่มีอยู่ — เบากว่า Docker, เบากว่า gVisor, เบากว่า eBPF sandbox

Use case 4: Portable CLI tools

Binary .wasm ที่คอมไพล์สำหรับ WASI คือ portable executable ที่รันบน OS ใดก็ได้ที่มี WASI runtime — ไม่ต้องใช้ cross-compilation matrix

# แจกจ่าย CLI tool เป็น .wasm binary
wasmtime my-tool.wasm -- --input file.csv --output result.json

# หรือ package ด้วย wasmer สำหรับ one-liner install
wasmer publish && wasmer run yourname/my-tool -- --help

Decision framework

flowchart TD
  Q1{"Need to run\nuntrusted code?"}
  Q1 -->|Yes| Wasm1["Use Wasm sandbox\n(WASI + wasmtime/wasmer)"]
  Q1 -->|No| Q2{"Performance-critical\ncompute in the browser?"}
  Q2 -->|Yes| Wasm2["Compile C/Rust/Go\nto wasm32-unknown-unknown"]
  Q2 -->|No| Q3{"Need edge cold-start\n< 1 ms?"}
  Q3 -->|Yes| Wasm3["Use Wasm on\nedge platform"]
  Q3 -->|No| Q4{"Plugin system\nacross languages?"}
  Q4 -->|Yes| Wasm4["Component Model\n+ WASI"]
  Q4 -->|No| Native["Stick with\nnative code / containers"]

เมื่อใดควรเลือกใช้ WebAssembly

เมื่อใด Wasm ไม่ใช่ทางเลือกที่ถูกต้อง

สถานการณ์	ทางเลือกที่ดีกว่า
CRUD web API ทั่วไป	Node.js / Go / Python — ความซับซ้อน toolchain น้อยกว่า
Stateful service ที่รันนาน	Docker container — observability tooling ดีกว่า
ML inference แบบ GPU-accelerated	CUDA / WebGPU — Wasm ไม่มี GPU access
Desktop app แบบ native	Tauri / Electron / native — OS integration ง่ายกว่า
Script และ glue code	Bash / Python — startup overhead ของ Wasm ไม่คุ้มค่า

ข้อแลกเปลี่ยน

ตัวเลือก	Benefit	Cost
WASI capability-based security	ปลอดภัยกว่ามาก — plugin หรือ sandboxed code ได้สิทธิ์เฉพาะที่ grant อย่างชัดเจน ไม่มี ambient access	ยังไม่ compatible กับ POSIX เต็มรูปแบบ native library บางตัวที่ assume ambient filesystem/network access จะ port เข้ามาไม่ราบรื่น
Edge/serverless (Wasm) vs container	Cold-start ระดับ microsecond และ footprint เล็กกว่า container มาก เหมาะกับ edge PoP	Container ecosystem ยังมี tooling และ battle-tested orchestration กว้างกว่า รวมถึง library support ที่ครบกว่า

ข้อผิดพลาดที่พบบ่อย

คาดหวังว่า filesystem หรือ network จะ “ใช้งานได้เลย” โดยไม่ grant capability ให้ WASI runtime อย่างชัดเจน — code จะ fail แบบเงียบ ๆ หรือโยน permission error
เลือกใช้ Wasm เป็นตัวแทน container ในทุกกรณีโดยไม่ตระหนักว่า tooling, orchestration และ library support ของ container ยัง mature กว่ามาก
Deploy ไป edge platform โดยไม่ตรวจสอบก่อนว่า runtime ปลายทางรองรับ SIMD หรือ threads proposal จริงหรือไม่ — feature เหล่านี้ยัง opt-in และไม่ universal

💡 ตัวอย่างจากของจริง

Cloudflare Workers และ Fastly Compute@Edge ใช้ Wasm sandboxing เพื่อ isolate tenant code นับพันตัวบน edge network เดียวกัน โดยได้ cold-start ระดับ microsecond ที่ container ทำไม่ได้