Clients

Embedded or remote

The first decision is not which library but which shape. Embedded means the engine runs inside your process: no ports, no authentication surface, no serialization across a wire. Today that is a Rust-only option, because the engine is a Rust library. Remote means your application connects to the reifydb server, which exposes the same engine to any language over WebSocket (8091) and HTTP (8090), with admin statements confined to loopback-only listeners. The transports, ports, and login flow are covered on Connect and are the same for every remote client.

The rule of thumb: a single Rust process that owns its state should embed. A frontend, a fleet of services, or a mixed-language system should run the server and connect remotely. The two shapes execute identical RQL, so starting embedded and moving behind a server later does not change your queries - it changes how requests reach the engine and adds policies and login at the boundary.

There is a third shape for trying things: the engine compiled to WebAssembly runs entirely in the browser. The playground and every runnable snippet in these docs use it. It needs no client library and no server at all.

At a glance

ReifyDB is pre-1.0. The Rust crates and the TypeScript packages are versioned in lockstep with the engine, so a 0.8.x client pairs with a 0.8.x server. All remote clients speak the same protocol: every request is a query (read), a command (write), or an admin statement (schema and identities, admin listeners only), and authentication is the same token-based login everywhere. Capabilities differ by transport, not by language: subscriptions need the persistent WebSocket connection, so no HTTP client has them.

Rust (Embedded)

The reifydb crate is not a client in the strict sense - it is the whole engine as a library, embedded the way you would embed SQLite. Build a database with embedded::memory() for a purely in-memory engine or embedded::sqlite(config) for disk persistence, then run statements directly: query_as_root, command_as_root, and admin_as_root, or the _as(identity) variants to execute as a specific identity. Sessions (db.root_session(), db.session(identity)) bundle an identity with retry strategies, and in-process subscriptions deliver changes without any socket. Because it is the engine itself, this surface is always the most complete: migrations, event handlers, and custom flow operators are available here first.

The same crate also hosts the server builder (server::memory() and friends), so "embedded" and "runs the server" are one dependency: swap embedded:: for server:: and the same process serves WebSocket and HTTP clients while still calling the engine directly. Details on Rust (Embedded).

Rust (Client)

The reifydb-client crate connects to a running server. Transports are opt-in Cargo features: ws gives you WsClient (one persistent connection carrying queries, commands, procedure calls, and subscriptions, including batch subscriptions), and http gives you HttpClient (plain request/response, no subscriptions). Both connect with a wire format argument - WireFormat::Json is the default, WireFormat::Rbcf the binary alternative - and both carry the full authentication flow: login_with_password, login_with_token, authenticate(token), logout.

Results come back as Frames; derive FromFrame on a struct to extract typed rows instead of walking columns by hand. A gRPC client and server subsystem exist behind feature flags, but WebSocket and HTTP are the transports the default server binary exposes. Details on Rust (Client).

TypeScript / JavaScript

@reifydb/client runs in Node.js and the browser. Client.connect_ws(url) returns a WebSocket client with queries, commands, subscriptions, automatic reconnection, and the login methods; Client.connect_http(url) is the request/response equivalent without subscriptions. Its companion @reifydb/core provides the value types and the Shape system: pass a shape describing the result you expect and rows arrive as typed objects instead of raw frames.

Around the client sits the largest ecosystem of any language: @reifydb/react wraps queries, commands, and subscriptions in hooks (useQueryOne, useCommandMany, useSubscription, useConnection), and @reifydb/wasm packages the in-browser engine so tests and demos can run with no server. All packages ship together at the engine version. Details on TypeScript / JavaScript.

Python

The Python binding is an early prototype and currently stale. It is a PyO3 module at version 0.0.1 that embeds the engine in the Python process - there is no remote client - and exposes a single Embedded class with a tx() method. It was written against an older engine API and has not kept pace: it is excluded from the default workspace build and does not reflect how the current engine works. If Python is your main language today, run the server and use HTTP directly, or wait for the rewrite. Current status on Python.

Wire formats

Every remote client speaks the same protocol underneath: requests tagged as query, command, or admin, with parameters as typed {type, value} pairs. Result payloads come in three encodings. frames is the default - a columnar JSON layout that preserves column types. json is the row-shaped alternative, easiest to consume from curl or any language without a client library. RBCF (ReifyDB binary columnar format, application/vnd.reifydb.rbcf) is the compact binary option for result-heavy workloads. Clients choose per connection; the encoding never changes what a query means or returns. The Wire Formats page specifies both, which is also the place to start if you want to write a client for a language ReifyDB does not cover yet.