Initial pass at wasm support via cffi #2330
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Add comprehensive implementation plan for WASM FFI TypeScript client - Include 5-phase approach: compilation, async runtime, protobuf, client, testing - Add original research findings on WASM compatibility - Mark Phase 1 & 2 as complete with verification steps
Phase 1: WASM Compilation Infrastructure - Add dual-target compilation support (C FFI + WASM) in Cargo.toml - Make tokio/tokio-util optional, only for native builds - Add WASM-specific dependencies (wasm-bindgen, js-sys, web-sys) - Create build_wasm.sh script for WASM compilation - Make baml-cli optional to exclude from WASM builds Phase 2: Async Runtime Adaptation - Create AsyncRuntime abstraction for platform-agnostic spawning - Replace direct tokio::runtime usage with AsyncRuntime::spawn_local - Add conditional compilation for libc types (c_char, c_int, c_void) - Add WASM-bindgen exports for runtime creation and function calls - Fix either crate imports for WASM compatibility Both native and WASM targets now compile successfully: - Native: cargo build --release - WASM: cargo build --target wasm32-unknown-unknown --no-default-features --features wasm - Generated WASM module size: ~11MB
Completed implementation of WASM FFI support for BAML runtime to enable browser-based execution. This includes: Phase 1: WASM Compilation Infrastructure - Updated Cargo.toml with WASM target dependencies - Created dual-target build system (native + WASM) - Added build_wasm.sh script for WASM compilation Phase 2: Async Runtime Adaptation - Created platform-agnostic AsyncRuntime abstraction - Replaced Tokio spawns with conditional compilation - Implemented spawn_local for WASM compatibility Phase 3: TypeScript Protobuf Layer - Added TypeScript protobuf generation to build.rs - Created buf.gen.yaml configuration - Implemented encode.ts and decode.ts modeled after Go client - Set up language_client_wasm package structure Phase 4: WASM Runtime Client - Implemented BamlWasmRuntime class with module loading - Added WASM-specific exports to lib.rs - Created promise-based function calling with callbacks - Implemented streaming support Current Status: - WASM builds successfully (11MB) - TypeScript compilation working - Module exports configured - Ready for Phase 5 browser testing Known Issues: - Protobuf serialization using JSON placeholder - Callback mechanism needs completion - WASM size needs optimization - Browser testing pending 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
- Add debug logging to async runtime spawn_local for WASM - Add comprehensive debugging to FFI function calls - Improve JavaScript callback invocation through window.__baml_callbacks - Initialize baml_log directly in init_wasm for proper logging setup - Add MIT license for language_client_cffi - Fix callback data serialization to JavaScript arrays
- Update runtime.ts to handle global wasmModule and improve callback mechanism - Add callbacks.js for JavaScript callback management utilities - Add proto_utils.ts for protobuf serialization helpers - Expand test.html with comprehensive test suite including memory management - Add specialized test files for callback, debug, LLM, and simple scenarios - Update implementation plan with Phase 5 completion and test results - Document known limitations and production readiness checklist
|
@dexhorthy is attempting to deploy a commit to the Boundary Team on Vercel. A member of the Team first needs to authorize it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What problem(s) was I solving?
The BAML runtime needed WebAssembly support to enable browser-based execution. Previously, BAML only supported server-side runtimes (Python, Ruby, Node.js). This PR implements WASM compilation of the FFI layer and creates a TypeScript client that can load and execute BAML functions directly in web browsers.
What user-facing changes did I ship?
language_client_wasm) for browser environmentsHow I implemented it
Implemented a 5-phase approach:
cfg(target_arch = "wasm32")and wasm-bindgen supportAsyncRuntimethat uses Tokio on native andspawn_localon WASMBamlWasmRuntimeclass with module loading and function invocationKey technical decisions:
nativevswasm) to conditionally compile platform-specific codewindow.__baml_callbacksregistryBuilt in close collaboration with @hellovai who sat in my apartment and shouted at claude with me all day
plan/Research artifacts in thoughts/ can be removed once they get put in a good location, leaving them in for now
How to verify it
To verify the WASM implementation:
cd engine/language_client_cffi && ./build_wasm.shcd engine/language_client_wasm && npm run buildpython3 -m http.server 3000inengine/language_client_wasmCurrent status:
Description for the changelog
Add WebAssembly support for BAML runtime, enabling browser-based execution of BAML functions through a new TypeScript client library