ENGINEERING NOTES
Engineering a local-first Rust/WASM poker analysis tool
Local-first does not merely mean “compiled to WebAssembly.” It requires explicit execution domains, bounded memory, cancellation, stale-result isolation, and a trustworthy boundary between cached bytes and displayed conclusions.
Rust owns the mathematical and rule contracts
Card encoding, legal hand state, evaluator ordering, exact enumeration, game-tree construction, CFR/DCFR, checkpoint identity, and replay verification belong in typed core code rather than duplicated UI logic.
The browser should display and orchestrate those contracts, not silently invent a second poker engine.
Workers isolate long-running tasks
Rule replay must remain responsive while exact equity or strategy computation is active. Separate request ownership prevents an old task from updating a newly edited configuration.
Fatal Worker errors must reject all pending callers immediately; termination and cancellation should produce one bounded terminal state.
Local cache is not automatic evidence
IndexedDB can store a checkpoint and snapshot, but the UI should not trust localStorage text as a qualified recommendation. Restore requires identity checks, hash validation, and replay against the matching Rust/WASM session.
Corrupt records should be removable so a valid solve can heal the same key, while a merely lower-quality result should not be misclassified as corruption.
Static editorial pages keep scale inexpensive
Guides, hand examples, feeds, search indexes, and social metadata are generated at build time and served as static files. They do not require a community database or server-side solver.
Only the application routes load the heavier Worker and WASM bundles; content pages remain fast and independently crawlable.
CONTINUE IN FLOPFORGE
Inspect the product methodology
Read the declared calculation scope, evidence rules, cache boundaries, and unsupported conclusions.FAQ
Questions this page should not hide
Why not run the solver on a server?
Browser execution avoids a remote compute bill and keeps entered hand data local, but requires strict memory and performance budgets.
Why use multiple Workers?
A single Worker serializes quick rule operations behind long equity or solver work. Separate domains protect the primary interaction path.
Can static pages still be interactive?
Yes. Small calculators and search can run as local JavaScript without a database, account system, or server API.