Bindings
How you embed the engine in a host environment.
Three distinct layers
These layers are separate concerns. Do not conflate them.
| Layer | What it is | Crates |
|---|---|---|
| Core engine | The pure temporal engine — computation graph, windowing, timers, typed absence, event-time semantics, CEP pattern matching, and the operator catalog. No I/O, no host assumptions. | tflo-core, tflo-cep, tflo-ops |
| Bindings / runtimes | How you embed the engine in a specific host: native Rust crate, WebAssembly module, or (on the roadmap) a foreign-language binding. Each binding exposes the engine's semantics in idiomatic form for its target. | tflo-wasm, tflo-cep-wasm, (native: direct) |
| Examples / applications | Concrete things built on a binding: a React temporal UX, a browser analytics library, an edge gateway, a backtesting harness. They are built on top of a binding; they do not define it. | React UX, browser-events, … |
Native Rust binding
Embed tflo-core directly as a Rust dependency. There is no separate binding crate
for native Rust — the core is the binding. You get the full
Iterator::tflo and Stream::tflo surface, keyed execution,
snapshot/restore, and the complete operator catalog from tflo-ops.
Suitable for: edge gateways, server-side services (tonic / axum / actix), batch pipelines, and backtesting harnesses. Compiles to ARM and musl targets; heap footprint is proportional to window state, not to a runtime. Ships today.
WebAssembly binding
The engine compiled to WebAssembly for JavaScript and TypeScript hosts. Two crates cover the two engine surfaces:
- tflo-wasm — the windowing and operator layer
(
tflo-core+tflo-ops), exposed as a JS module. - tflo-cep-wasm — the complex-event pattern engine
(
tflo-cep), exposed for JS/TS consumers.
This WASM layer is the substrate under both browser examples — the React temporal UX and the browser analytics library. The engine is not married to React, to any framework, or to any particular JS packaging. The two examples are independent applications that happen to share the same WASM binding. Ships today.
Cross-tier parity follows directly: because the server runs native Rust and the browser runs the same engine compiled to WASM, both evaluate the same rule against the same event log and produce the same output. This is not "same algorithm reimplemented twice" — it is the same compiled artifact, different ABI.
Other languages — roadmap
Roadmap, not shipped. C#, Go, and Python bindings do not exist today. Native Rust and WASM are what ship.
A pure, deterministic engine with no runtime assumptions ports cleanly across language runtimes. The same property that makes cross-tier parity tractable for Rust/WASM makes cross-language parity tractable more broadly: the engine is a function of the event log and the rule, with no ambient state. The bindings differ; the semantics do not.
Likely paths: C# and Go via WASM (same artifact, different host); Python via WASM or PyO3 FFI. The ordering and exact mechanism are not settled. If you have a concrete need, file an issue on the crate's repository.
See also: Examples — concrete applications built on the native and WASM bindings — and Positioning for the React temporal UX walkthrough, or browser analytics for the framework-agnostic browser example.