WASI & Beyond the Browser

WebAssembly ถูกออกแบบมาสำหรับ browser แต่คุณสมบัติของตัวเอง (sandbox ที่ปลอดภัย, ความเร็วใกล้เคียง native, และความพกพาข้ามภาษา) ทำให้มีคุณค่าเท่ากันบนเซิร์ฟเวอร์, edge node, อุปกรณ์ embedded และระบบ plugin กุญแจที่ปลดล็อกทุกสภาพแวดล้อมเหล่านี้คือ WASI — WebAssembly System Interface

ทำไมต้องรัน Wasm นอก browser?

ใน browser JavaScript engine คือ host ที่ให้สภาพแวดล้อมรันไทม์, จัดการหน่วยความจำ และเปิดเผย browser API นอก browser ไม่มี JavaScript engine, DOM หรือ fetch module Wasm ที่ต้องการอ่านไฟล์, เขียน stdout หรือเปิด socket ต้องการ host อื่นมาจัดหาความสามารถเหล่านั้น

WASI คือคำตอบที่เป็นมาตรฐาน: ชุดนิยาม system-call คล้าย POSIX ที่แสดงออกมาเป็น Wasm import รันไทม์ใดก็ตามที่ implement WASI สามารถรัน binary .wasm เดียวกัน — บน Linux, macOS, Windows หรือไมโครคอนโทรลเลอร์ขนาดเล็ก

ความสัมพันธ์ระหว่าง host, runtime และ module

flowchart LR
  H["Host\n(OS / Edge Platform)"]
  R["WASI Runtime\n(wasmtime / wasmer)"]
  M["Wasm Module\n(.wasm binary)"]
  H -->|"grants capabilities\n(dirs, sockets, env vars)"| R
  R -->|"exposes WASI imports\n(fd_write, path_open …)"| M
  M -->|"calls imports to\nread/write/execute"| R

Host → WASI runtime → Wasm module

ไดอะแกรมแสดงโมเดลสามชั้น:

Host — ระบบปฏิบัติการหรือ cloud platform ที่ตัดสินใจว่าทรัพยากร (directories, sockets, environment variable) ใดที่รันไทม์จะส่งผ่านได้
WASI Runtime — executable อิสระเช่น wasmtime หรือ wasmer ที่ implement WASI spec เป็น Wasm import function และบังคับใช้ capability grant
Wasm Module — binary ที่คอมไพล์แล้ว โดย import WASI function แบบเดียวกับ Wasm import อื่น ๆ ไม่มีการเรียก OS โดยตรง

บทเรียนใน module นี้

#	บทเรียน	สิ่งที่คุณจะเรียนรู้
1	ภาพรวมนี้	เหตุผลและสถาปัตยกรรม
2	WASI Deep Dive	ความปลอดภัย capability, Preview 1 vs 2, คอมไพล์ Rust ไป WASI
3	wasmtime & wasmer	รันและ embed Wasm binary ด้วยรันไทม์จริง
4	Component Model, SIMD & Threads	WIT interface, SIMD `v128`, และภาพรวม threads
5	Use Cases & When to Use Wasm	Plugin, edge, sandboxing, portable CLI และข้อพิจารณา