January 14, 2025

Agenda

Lucas demonstrated a refreshed version of the Blobby example with a new web interface, making it more presentable and user-friendly:
The demo now includes a visual UI served by Blobby itself, replacing the need for curl commands
Users can upload files (single or multiple) through the interface
Added a copy link feature to easily get URLs for uploaded files
The UI includes an activity bar showing recent operations
The demo showcases hosting both UI and API in the same WebAssembly component
When you run the demo with wash dev, data is stored in-memory, while in Kubernetes environments it's backed by NATS Object Store

The team implemented significant architectural changes to how wash build and wash dev work, moving from implicit to explicit configuration
Previously, wash would infer build methods based on files in the directory (Cargo.toml for Rust, go.mod for Go), which caused problems in monorepos
The new approach enables developers to specify custom build commands in their configuration
Developers can now control where the WebAssembly artifact will be located after build
Different commands can be specified for wash dev (debug builds) vs wash build (release builds)
Build commands now support environment variable interpolation and forwarding from the shell environment
Teams can use makefiles or any other build tool of their choice
The -c flag allows changing to a project directory before wash executes
No longer limited by hardcoded build logic - developers have full control

The new wash configuration supports developing services (long-running WebAssembly components) alongside stateless components
Developers can specify additional WebAssembly files to bring into the workload during wash dev
Example shown with cron service and cron component working together
The workload assembled during development matches the structure that would be deployed to production

The team discussed improving local development storage
Current in-memory plugins clear data on every code change, requiring re-seeding
Plan to back in-memory plugins with file system storage in the cache directory
This will allow developers to seed applications by copying files into a directory and persist data across code changes
In production, the host plugin approach means platform administrators decide the storage backend (e.g., NATS, S3)
Each workload gets its own instance of plugins, not a shared monolithic provider

Completed: v2 Glossary
- v2 Glossary with entries for "Service" and "Workload"
- Currently the best quick reference for top-level v2 concepts
In Progress: Installation page re-work
- New three-page QuickStart guide following the v1 structure
- Covers installing wash, creating components, adding functionality with persistent storage
- New addition: deploying Wasm workload in local Kubernetes environment
- This update is in draft, and feedback is always appreciated!

New WASI P3 release candidate is now in Wasmtime (requires newer version of wit-bindgen, will be in next month's release)
New Go component SDK released, compatible with latest TinyGo, latest Go, and latest wasm-tools