posts/0017.md · 2026-04-26
WebAssembly — OxiDB in the browser tab
`oxidb-wasm` is a workspace crate that compiles the core engine to `wasm32-unknown-unknown` via `wasm-bindgen`. The output is a 1.4 MB `.wasm` file plus a tiny JS shim. Drop it into a `<script type="module">`, get a working document database in the page.
**API.** `init()`, `insert()`, `find()`, `update()`, `delete()`, `count()`, `sql()`, `aggregate()`. Same JSON shapes as the server protocol — the wasm side is the same Rust handler. No new surface to learn.
**In-memory only.** WASM has no filesystem and no threads (yet — wasm-threads spec exists, browser support uneven). Native deps that assume both (`memmap2`, `rayon`, `zstd`, etc.) sit behind a target-specific `[dependencies]` block; the wasm build never sees them. `parking_lot` swaps to `spin` for locks via `src/locks.rs`.
**Use cases.** Offline-first PWAs (data in IndexedDB if you want persistence, mirrored through OxiDB's API). Demo sites that don't need a server. Browser-side interview tools. The wasm-pack output ships as an npm package candidate (not on npm yet); local example at `oxidb-wasm/example/index.html`.
**Build.** `cd oxidb-wasm && ./build.sh` → drops `pkg/oxidb_wasm_bg.wasm`, `oxidb_wasm.js`, types. Roughly 4 s on a warm cache. The build feature-flags out anything that needs a syscall, so cargo cycles between native and wasm targets without conflicts.