https://www.boundaryml.com logo
Powered by
Hey folks,
# contributing
a
Hey folks, I've been looking into what it would take to get the TS client working in CF Workers and I'd like to help get this over the line if there's interest. From what I can tell, most of the hard runtime work is already done - 
baml-schema-wasm
compiles the full runtime to WASM and already makes real LLM calls (the playground uses it). The gap is that it exposes a playground/IDE API rather than the `callFunction`/`streamFunction`/`TypeBuilder` etc. API that the generated client code expects. My rough read on what's left: - Add 
callFunction
, 
streamFunction
, 
buildRequest
, 
TypeBuilder
, 
ClientRegistry
, 
RuntimeContextManager
as 
#[wasm_bindgen]
exports to 
baml-schema-wasm
(the pattern is already there via 
run_tests
) - A thin 
wasm-entry.js
shim in 
language_client_typescript
that initialises the WASM and re-exports everything under the same interface as the NAPI module - 
package.json
export conditions (
workerd
, 
browser
) pointing at the shim - A couple of small 
process.env
/ 
process.on
guards in 
async_context_vars.ts
- 
wasm-pack build
wired into the publish pipeline alongside the existing 
napi build
Before I start digging in I wanted to ask: 1. Is this actually wanted? Don't want to open a big PR into a dead end 2. Is 
baml-schema-wasm
the right place to add these bindings or should they live in a new crate? 3. Any known blockers I've missed - e.g. WASM binary size concerns, streaming edge cases? 4. Preferred way to contribute - draft PR early, or work something out in an issue first? Happy to take a stab at the Rust bindings side if the direction is clear.
a
we are migrating to a new compiler architecture, in the baml_language directory. You could try implementing the missing APIs in bridge_wasm. We have already started implementing bridge_python and bridge_node
thank you for the interest!
there is no typebuilder yet in this compilerv2
and yes we would love to have a working wasm/web client. We dont have a 
generator
made for it yet in compilerv2
CC @baml-sam is working through these bridge implementations, and he could guide you through the process
so tl;dr 1. yes 2. no, baml_language 3. wasm binary size is def something to look out for. 4. We love looking at some design docs (like an ai generated markdown file) of your plan, and the 'phases', before you start on it
a
Awesome, thanks! I'll have a look and come back with a plan.
@User are you already working on streaming in 
bridge_wasm
? Don't want to duplicate work there.
b
Hiya! Sorry for the delay. I'm not doing anything in bridge_wasm right now, but we also don't actually have streaming set up across FFI boundaries right now, so that has to get solved first
We're also still working on TypeBuilder into baml_language - we've done some brainstorming on what its semantics would look like, but haven't yet implemented it
For context for us, what timezone are you operating out of / what are your working hours? It sounds like it would be good to hop on a call for a little bit to get on the same page We're based out of Seattle, so our core available hours are 9am-6pm but happy to do earlier or later depending on where you are
a
I'm based in London so it's an 8h time difference but happy to jump on a call out of hours.
b
How's Monday 8:30am PT / London 4:30pm PT sound?
2 Views
PreviousNext
Powered by