Skip to main content

SDK references

Per-language SDK reference for exd-client. The SDKs preserve the single-validator invariant — every implementation FFIs into the same crates/exd-client/ source the server uses, so lint, eval, telemetry, and closure-delta apply behave identically on every runtime. No language-specific reimplementation.

LanguagePackageStatusReference
Rustexd-client (crates.io)shipped01-rust.md
TypeScript@exd/client (npm)shipped02-typescript.md
Pythonexd-client (PyPI)spec only — not yet implemented03-python.md
Javadev.exd:exd-client (Maven)spec only — not yet implemented04-java.md

The TypeScript SDK consumes the Rust core via WebAssembly (two artifacts: lite + full). The Python SDK consumes it via PyO3 + maturin. The Java SDK consumes it via JNI / Panama. All three FFI surfaces target the same crates/exd-client/ library.

Choosing an SDK shape​

ScenarioSDK shapeReference
Trusted backend service that wants in-process evaluationRust SDK with namespace_uri(...) or server(...)01-rust.md
Backend service that can't or won't embed the SDKNone — call POST /evaluate with a namespace-read token—
Browser bundle, public clientTypeScript SDK with @exd/client/remote and a namespace-client token02-typescript.md
Node service that wants in-process eval + SSE refreshTypeScript SDK with @exd/client/full02-typescript.md
Python or Java servicePython / Java SDK (spec only today)03-python.md, 04-java.md

The full deployment-mode picker lives at server-api § Deployment modes.

Cross-runtime conformance​

Every conformant SDK runs the parity-fixture suite at fixtures/evaluation-parity.json in CI. A failure in any runtime blocks merge. The fixture-file format is implementer-facing and lives in docs/spec/evaluation-parity.md.

See also​