@push.rocks/smartrust
A type-safe, production-ready bridge between TypeScript and Rust binaries — with support for stdio (child process) and socket (Unix socket / Windows named pipe) transports, request/response, streaming, and event patterns.
Issue Reporting and Security
For reporting bugs, issues, or security vulnerabilities, please visit community.foss.global/. This is the central community hub for all issue reporting. Developers who sign and comply with our contribution agreement and go through identification can also get a code.foss.global/ account to submit Pull Requests directly.
Install 📦
pnpm add @push.rocks/smartrust
Overview 🔭
@push.rocks/smartrust provides a complete bridge for TypeScript applications that need to communicate with Rust binaries. It handles the entire lifecycle — binary discovery, process spawning or socket connection, request/response correlation, streaming responses, event pub/sub, and graceful shutdown — so you can focus on your command definitions instead of IPC plumbing.
Two Transport Modes 🔌
| Mode | Method | Use Case |
|---|---|---|
| Stdio | bridge.spawn() |
Spawn the Rust binary as a child process. Communicate via stdin/stdout. |
| Socket | bridge.connect(path) |
Connect to an already-running Rust daemon via Unix socket or Windows named pipe. |
The JSON protocol is identical in both modes — only the transport layer changes. Socket mode enables use cases where the Rust binary runs as a privileged system service (e.g., a VPN daemon needing root for TUN devices, a network proxy binding to privileged ports) while the TypeScript app connects to it unprivileged.
Why? 🤔
If you're integrating Rust into a Node.js project, you'll inevitably need:
- A way to find the compiled Rust binary across different environments (dev, CI, production, platform packages)
- A way to spawn it or connect to it and establish reliable two-way communication
- Type-safe request/response patterns with proper error handling
- Streaming responses for progressive data processing, log tailing, or chunked transfers
- Event streaming from Rust to TypeScript
- Graceful lifecycle management (ready detection, clean shutdown, auto-reconnection)
smartrust wraps all of this into a clean API: RustBridge, RustBinaryLocator, StreamingResponse, and pluggable transports.
Usage 🚀
The IPC Protocol
smartrust uses a simple, newline-delimited JSON protocol:
| Direction | Format | Description |
|---|---|---|
| TS → Rust (Request) | {"id": "req_1", "method": "start", "params": {...}} |
Command with unique ID |
| Rust → TS (Response) | {"id": "req_1", "success": true, "result": {...}} |
Final response correlated by ID |
| Rust → TS (Error) | {"id": "req_1", "success": false, "error": "msg", "errorCode": "EAPP_INVALID", "errorData": {...}} |
Error correlated by ID; errorCode and errorData are optional |
| Rust → TS (Stream Chunk) | {"id": "req_1", "stream": true, "data": {...}} |
Intermediate chunk (zero or more) |
| Rust → TS (Event) | {"event": "ready", "data": {...}} |
Unsolicited event (no ID) |
| Rust → TS (Ready with capabilities) | {"event": "ready", "data": {...}, "capabilities": ["cancel"]} |
Optional opt-in to cancel frames for this connection |
| TS → Rust (Cancel) | {"id": "req_1", "cancel": true} |
Sent only to binaries that advertised cancel, after a timeout or abort |
| Rust → TS (Cancelled) | {"id": "req_1", "success": false, "cancelled": true, "error": "msg"} |
The one answer to a cancelled request; errorCode and errorData are optional |
This protocol works identically over stdio and socket transports. Your Rust binary reads JSON lines from one end and writes JSON lines to the other. That's it.
Defining Your Commands
Start by defining a type map of commands your Rust binary supports:
import { RustBridge } from '@push.rocks/smartrust';
// Define your command types
type TMyCommands = {
start: { params: { port: number; host: string }; result: { pid: number } };
stop: { params: {}; result: void };
getMetrics: { params: {}; result: { connections: number; uptime: number } };
reload: { params: { configPath: string }; result: void };
};
Stdio Mode — Spawn a Child Process
This is the classic mode. The bridge spawns the Rust binary and communicates via stdin/stdout:
const bridge = new RustBridge<TMyCommands>({
binaryName: 'my-rust-server',
envVarName: 'MY_SERVER_BINARY', // optional: env var override
platformPackagePrefix: '@myorg/my-server', // optional: platform npm packages
});
// Spawn the binary and wait for it to signal readiness
const ok = await bridge.spawn();
if (!ok) {
console.error('Failed to start Rust binary');
process.exit(1);
}
// Send type-safe commands — params and return types are inferred!
const { pid } = await bridge.sendCommand('start', { port: 8080, host: '0.0.0.0' });
console.log(`Server started with PID ${pid}`);
const metrics = await bridge.sendCommand('getMetrics', {});
console.log(`Active connections: ${metrics.connections}`);
// Listen for events from Rust
bridge.on('management:configChanged', (data) => {
console.log('Config was changed:', data);
});
// Confirmed shutdown (SIGTERM → SIGKILL after 5s)
await bridge.terminate();
Stdio children can inherit caller-owned file descriptors. Values map in order starting at child fd 3; the source descriptors remain owned by the caller and are never closed by Smartrust:
import { open } from 'node:fs/promises';
const handle = await open('/run/my-app/control', 'r+');
const bridge = new RustBridge<TMyCommands>({
binaryName: 'my-rust-server',
inheritedFileDescriptors: [handle.fd], // available to the child as fd 3
});
await bridge.spawn();
await bridge.terminate();
await handle.close();
Each numeric source descriptor must remain open and refer to the intended
resource until spawn() resolves. Reusing the bridge with another spawn()
requires the descriptors to remain valid through that call as well. Closing a
source descriptor after a successful spawn does not close the child's copy, but
Smartrust never assumes ownership or closes the source itself.
Entries must be non-negative safe integers; invalid values throw RangeError
during bridge construction.
inheritedFileDescriptors applies only to spawn(). Calling connect() with a
non-empty descriptor list rejects because a socket daemon is not a child of the
bridge and cannot inherit them. Node.js does not support passing socket
descriptors this way on Windows.
One-shot sensitive byte requests
Stdio mode can append one Smartrust-owned pipe after all caller-owned inherited descriptors. It carries one raw byte payload without putting those bytes in the JSON request, a string, an environment variable, or a backing file:
const bridge = new RustBridge<TMyCommands>({
binaryName: 'my-rust-server',
sensitiveByteChannel: { maxPayloadSize: 2 * 1024 * 1024 },
});
await bridge.spawn();
const bytes = new Uint8Array([1, 2, 3]);
const result = await bridge.sendCommandWithSensitiveBytes('start', { port: 8080 }, bytes);
// Smartrust has cleared the exact `bytes` view before the promise settles.
Only one sensitive request may use a spawned generation. It runs exclusively
with respect to other commands, but ordinary JSON commands can continue after
its successful acknowledgement. A new spawn() creates a new pipe. Socket
mode rejects sensitiveByteChannel because the daemon is not a child process.
The JSON request adds only this value-free metadata:
{"sensitive":{"protocol":"smartrust-sensitive-v1","fileDescriptor":3,"byteLength":3}}
The child descriptor is 3 + inheritedFileDescriptors.length, so existing
inherited descriptor numbers never move. The binary frame is:
| Offset | Size | Value |
|---|---|---|
| 0 | 4 | ASCII SMRS |
| 4 | 1 | version 1 |
| 5 | 1 | flags 0 |
| 6 | 2 | big-endian request-id byte length |
| 8 | 8 | big-endian payload byte length |
| 16 | variable | ASCII request id, then raw payload bytes |
The receiver must consume and validate the complete frame before sending its normal JSON response. That response must include an exact value-free ACK:
{"sensitiveAck":{"protocol":"smartrust-sensitive-v1","consumed":true,"byteLength":3}}
Smartrust settles only after both the local pipe write callback and the matching ACK, regardless of their event order. Abort, timeout, partial pipe failure, malformed ACK, or a receiver error terminates the child and rejects every pending request, so buffered bytes cannot become a later request.
Calling the method transfers exclusive use of the supplied mutable
Uint8Array<ArrayBuffer> view until settlement. Smartrust clears that exact
view after the write callback or failure. It cannot promise erasure of aliases,
JavaScript engine or Node.js internal copies, kernel pipe buffers, or memory the
receiver owns; each receiver must bound and clear its own buffers.
Per-Command Deadlines and Cancellation
Non-streaming commands accept an optional IRustBridgeRequestOptions argument:
import { RustBridgeRequestError } from '@push.rocks/smartrust';
const controller = new AbortController();
try {
const metrics = await bridge.sendCommand(
'getMetrics',
{},
{
timeoutMs: 2000,
signal: controller.signal,
},
);
} catch (error) {
if (error instanceof RustBridgeRequestError) {
console.error(error.code, error.message);
}
}
timeoutMs must be a positive safe integer. When it is omitted, the bridge's
constructor-level requestTimeoutMs remains the default. An already-aborted
signal rejects before a request ID is allocated or anything is written.
Timeout and abort reject the local wait at once. They do not kill or disconnect the shared bridge, and later commands can continue using the same bridge. When the binary supports it, the bridge also asks Rust to stop the command; see Cancelling the Rust Side.
Use maxPendingRequestsByMethod to fail fast before serialization and transport
writes when one command type reaches its local pending-request limit. Limits are
independent, so saturated data-plane commands do not block control or callback
commands:
const bridge = new RustBridge<TMyCommands>({
binaryName: 'my-rust-server',
maxPendingRequestsByMethod: {
processData: 256,
},
});
Capacity is released when the local request resolves, rejects, times out, or is
aborted, when its transport write fails, or when the bridge terminates. Regular
and streaming calls to the same method share its capacity. Every configured
limit must be a positive safe integer; invalid values throw RangeError during
construction. The limit bounds local pending state, not remote execution: a
timed-out or aborted request frees its capacity immediately, even while Rust is
still working on it or answering its cancel frame.
Cancelling the Rust Side
A binary opts in to cancellation by adding "capabilities": ["cancel"] to its
ready event. The bridge records this per connection: a respawn or socket
reconnect starts without it until the next ready event advertises it again.
Binaries that do not advertise cancel never receive a cancel frame, so the
Rust command may keep running after the local wait ends.
With the capability, a timeout or abort of a request that was already written
sends one cancel frame, {"id":"req_1","cancel":true}. No cancel frame is sent
when the response already arrived, when the signal was aborted before the
request was written, or for sendCommandWithSensitiveBytes, whose failures
terminate the child instead.
The rejection's remoteSettlement then reports how Rust settled the request.
It resolves once and never rejects:
outcome |
Meaning |
|---|---|
cancelled |
Rust stopped and answered success: false, cancelled: true |
completed |
Rust finished anyway; result holds the result |
failed |
Rust answered success: false without cancelled: true |
disconnected |
The transport closed before Rust answered; the outcome is unknown |
cancelled and failed carry Rust's error, string errorCode and
errorData when it sent them. remoteSettlement is undefined when no cancel
frame was sent. Stream chunks and answers that arrive for a cancelled request
are consumed by the bridge and never reach the caller.
A Rust command may take a while to reach a point where it can stop, and a
faulty binary may never answer. Bound the wait yourself and terminate the child
when it runs out; the settlement then resolves as disconnected:
try {
await bridge.sendCommand('ingest', params, { timeoutMs: 60_000 });
} catch (error) {
if (error instanceof RustBridgeRequestError && error.remoteSettlement) {
let timer: ReturnType<typeof setTimeout> | undefined;
const deadline = new Promise<null>((resolve) => {
timer = setTimeout(() => resolve(null), 30_000);
});
const settlement = await Promise.race([error.remoteSettlement, deadline]);
clearTimeout(timer);
if (!settlement) {
await bridge.terminate(); // respawn with bridge.spawn() on next use
}
}
throw error;
}
Without the
cancelcapability, or when the settlement iscompletedordisconnected, Rust may have executed the command. Do not blindly retry mutating commands; first establish whether the original command executed or design the command to be idempotent.
Timeout, cancellation, transport-write/exit, and Rust response failures use
RustBridgeRequestError.
Existing message text remains available, while code is stable for
programmatic handling:
| Code | Meaning |
|---|---|
ERR_RUST_BRIDGE_REQUEST_TIMEOUT |
The local request deadline or streaming inactivity deadline elapsed |
ERR_RUST_BRIDGE_REQUEST_ABORTED |
The caller's signal aborted the local wait or stream |
ERR_RUST_BRIDGE_REQUEST_LIMIT |
The configured pending-request limit for this method is full |
ERR_RUST_BRIDGE_REQUEST_WRITE |
The transport rejected the request write |
ERR_RUST_BRIDGE_REQUEST_TRANSPORT |
The transport exited, disconnected, or was killed |
ERR_RUST_BRIDGE_REQUEST_RUST_RESPONSE |
Rust returned success: false |
When Rust supplies the optional response errorCode, the resulting
RustBridgeRequestError.responseErrorCode exposes it without parsing the
message. The bridge-owned code remains
ERR_RUST_BRIDGE_REQUEST_RUST_RESPONSE, so callers can distinguish transport
failures from application-specific Rust failures. Legacy responses and
non-string errorCode values leave responseErrorCode undefined.
When a failure has structured details, for example one reason per invalid
input, Rust can send them as the optional response errorData, any JSON
value. RustBridgeRequestError.responseErrorData carries it as sent, typed
unknown, so the caller narrows it for its own error codes. A response
without errorData leaves responseErrorData undefined.
// Rust: {"id":"req_7","success":false,"error":"Validation failed",
// "errorCode":"EVALIDATION","errorData":{"fields":[{"name":"port","messages":["must be 1-65535"]}]}}
try {
await bridge.sendCommand('configure', { port: 0 });
} catch (error) {
if (error instanceof RustBridgeRequestError && error.responseErrorCode === 'EVALIDATION') {
console.error(error.responseErrorData);
}
}
Confirmed Termination
Use await bridge.terminate() when later work must not overlap the current
worker. In stdio mode it sends SIGTERM, escalates to SIGKILL after five seconds,
and resolves only after the child process and its stdio handles have closed.
The grace period can be changed per termination; zero requests immediate
SIGKILL:
await bridge.terminate({ gracePeriodMs: 250 });
For workers that need longer cleanup, set terminationGracePeriodMs when
constructing the bridge. This default also applies when startup fails or stdin
breaks and cleanup begins automatically. Calling terminate() afterwards
cannot replace a grace period already selected by automatic cleanup.
const bridge = new RustBridge({
binaryName: 'worker',
terminationGracePeriodMs: 60_000,
});
await bridge.spawn();
await bridge.terminate(); // allows up to 60 seconds before SIGKILL
terminationGracePeriodMs accepts non-negative safe integers and defaults to
5000. StdioTransport accepts the same constructor option. Confirmed process
closure alone does not prove that an application's external cleanup succeeded.
Concurrent calls share one termination operation, and calls after confirmed
closure are no-ops. The first concurrent caller's grace period applies. In
socket mode, termination confirms only the local socket closure; the remote
daemon is never signaled. kill() remains available for compatibility as a
fire-and-forget wrapper, but callers that require confirmed ownership release
must await terminate().
If termination rejects, the bridge retains the transport and remains in its
stopping state because closure was not confirmed. A later terminate() call
starts a fresh cleanup attempt; activation remains unavailable until one of
those attempts confirms closure.
Socket Mode — Connect to a Running Daemon 🔗
When the Rust binary runs as a system service (e.g., via systemd, launchd, or a Windows Service), use connect() to talk to it over a Unix socket or named pipe:
const bridge = new RustBridge<TMyCommands>({
binaryName: 'my-daemon', // used for logging / error messages
});
// Connect to the daemon's management socket
const ok = await bridge.connect('/var/run/my-daemon.sock');
if (!ok) {
console.error('Failed to connect to daemon');
process.exit(1);
}
// Same API as stdio mode — completely transparent!
const { pid } = await bridge.sendCommand('start', { port: 8080, host: '0.0.0.0' });
const metrics = await bridge.sendCommand('getMetrics', {});
// terminate() confirms local socket closure — it does NOT kill the daemon
await bridge.terminate();
Auto-Reconnect
For long-running applications, enable automatic reconnection with exponential backoff:
const ok = await bridge.connect('/var/run/my-daemon.sock', {
autoReconnect: true, // reconnect on unexpected disconnect
reconnectBaseDelayMs: 100, // initial retry delay (doubles each attempt)
reconnectMaxDelayMs: 30000, // max retry delay cap
maxReconnectAttempts: 10, // give up after 10 attempts
});
// Listen for reconnection events
bridge.on('reconnected', () => {
console.log('Reconnected to daemon!');
});
Platform Notes
| Platform | Socket Path Format | Example |
|---|---|---|
| Linux | /var/run/<name>.sock or $XDG_RUNTIME_DIR/<name>.sock |
/var/run/my-daemon.sock |
| macOS | /var/run/<name>.sock |
/var/run/my-daemon.sock |
| Windows | \\.\pipe\<name> |
\\.\pipe\my-daemon |
Node.js net.connect() handles all formats transparently — no platform-specific code needed.
Streaming Commands 🌊
For commands where the Rust binary sends a series of chunks before a final result, use sendCommandStreaming. This is perfect for progressive data processing, log tailing, search results, or any scenario where you want incremental output.
Defining Streaming Commands
Add a chunk field to your command type definition to mark it as streamable:
type TMyCommands = {
// Regular command (request → response)
ping: { params: {}; result: { pong: boolean } };
// Streaming command (request → chunks... → final result)
processData: { params: { count: number }; chunk: { index: number; progress: number }; result: { totalProcessed: number } };
tailLogs: { params: { lines: number }; chunk: string; result: { linesRead: number } };
};
Consuming Streams
// Returns a StreamingResponse immediately (does NOT block)
const stream = bridge.sendCommandStreaming('processData', { count: 1000 });
// Consume chunks with for-await-of
for await (const chunk of stream) {
console.log(`Processing item ${chunk.index}, progress: ${chunk.progress}%`);
}
// Get the final result after all chunks are consumed
const result = await stream.result;
console.log(`Done! Processed ${result.totalProcessed} items`);
Error Handling in Streams
Errors propagate to both the iterator and the .result promise:
const stream = bridge.sendCommandStreaming('processData', { count: 100 });
try {
for await (const chunk of stream) {
console.log(chunk);
}
} catch (err) {
console.error('Stream failed:', err.message);
}
// .result also rejects on error
try {
await stream.result;
} catch (err) {
console.error('Same error here:', err.message);
}
A final success: false response rejects both paths with the same
RustBridgeRequestError. When the response includes an errorCode or
errorData, they are available as responseErrorCode and responseErrorData
on that error. When the transport exits, disconnects or is terminated, both
paths reject with a RustBridgeRequestError whose code is
ERR_RUST_BRIDGE_REQUEST_TRANSPORT, as regular commands do.
Aborting a Stream
Pass an AbortSignal to stop consuming a stream. The iterator and .result
reject with ERR_RUST_BRIDGE_REQUEST_ABORTED, and a binary with the cancel
capability receives a cancel frame, exactly as for regular commands:
const controller = new AbortController();
const stream = bridge.sendCommandStreaming('processData', { count: 100 }, {
signal: controller.signal,
});
Stream Timeout
By default, streaming commands use the same timeout as regular commands (requestTimeoutMs). The timeout resets on each chunk received, so it acts as an inactivity timeout rather than an absolute timeout. When it elapses, the stream rejects with a RustBridgeRequestError whose code is ERR_RUST_BRIDGE_REQUEST_TIMEOUT, and a binary with the cancel capability receives a cancel frame. You can configure it separately:
const bridge = new RustBridge<TMyCommands>({
binaryName: 'my-server',
requestTimeoutMs: 30000, // regular command timeout: 30s
streamTimeoutMs: 60000, // streaming inactivity timeout: 60s
});
Implementing Streaming on the Rust Side
Your Rust binary sends stream chunks by writing lines with "stream": true before the final response:
// For each chunk:
println!(r#"{{"id":"{}","stream":true,"data":{{"index":{},"progress":{}}}}}"#, req.id, i, pct);
io::stdout().flush().unwrap();
// When done, send the final response (same as non-streaming):
println!(r#"{{"id":"{}","success":true,"result":{{"totalProcessed":{}}}}}"#, req.id, total);
io::stdout().flush().unwrap();
Binary Locator 🔍
The RustBinaryLocator searches for your binary using a priority-ordered strategy:
| Priority | Source | Description |
|---|---|---|
| 1 | binaryPath option |
Explicit path — skips all other search |
| 2 | Environment variable | e.g. MY_SERVER_BINARY=/usr/local/bin/server |
| 3 | Platform npm package | e.g. @myorg/my-server-linux-x64/my-rust-server |
| 4 | Local dev paths | ./rust/target/release/<name> and ./rust/target/debug/<name> |
| 5 | System PATH | Standard $PATH lookup |
Supplying binaryPath selects only that filesystem path. Relative paths resolve
against the working directory at construction, and a bare name such as node
does not search PATH; use process.execPath to select the running Node executable.
The locator snapshots its options and checks the selected target on every lookup,
including restarts. Missing paths, empty/invalid values, directories and files
without execute permission reject with RustBinaryLocatorError and code
ERR_RUST_BINARY_EXPLICIT_PATH_INVALID. Explicit selection never changes file
permissions or falls back to environment variables, packages, local builds or
PATH. These guarantees also apply to RustBridge.spawn(); confirmed termination
remains available after selection fails. No global environment is modified.
When binaryPath is omitted, the normal discovery strategy remains available.
Discovered paths are cached and revalidated before reuse; a missing cached target
triggers discovery again. Permission repair applies only to regular discovery
candidates and preserves their existing read/write permission bits.
You can also use the locator standalone:
import { RustBinaryLocator } from '@push.rocks/smartrust';
const locator = new RustBinaryLocator({
binaryName: 'my-rust-server',
envVarName: 'MY_SERVER_BINARY',
localPaths: ['/opt/myapp/bin/server'], // custom search paths
});
const binaryPath = await locator.findBinary();
// Discovery results are cached and revalidated; clearCache() forces re-search.
Configuration Reference ⚙️
The RustBridge constructor accepts an IRustBridgeOptions object:
const bridge = new RustBridge<TMyCommands>({
// --- Binary Locator Options ---
binaryName: 'my-server', // required: name of the binary
binaryPath: '/explicit/path/to/binary', // optional: skip search entirely
envVarName: 'MY_SERVER_BINARY', // optional: env var for path override
platformPackagePrefix: '@myorg/my-server', // optional: platform npm package prefix
localPaths: ['./build/server'], // optional: custom local search paths
searchSystemPath: true, // optional: search $PATH (default: true)
// --- Bridge Options ---
cliArgs: ['--management'], // optional: args passed to binary (default: ['--management'])
inheritedFileDescriptors: [sourceFd], // optional: caller-owned source fds mapped to child fd 3+
sensitiveByteChannel: { maxPayloadSize: 2 * 1024 * 1024 }, // optional: one owned raw-byte pipe per spawn
requestTimeoutMs: 30000, // optional: default request timeout (default: 30000)
streamTimeoutMs: 30000, // optional: streaming inactivity timeout (default: requestTimeoutMs)
readyTimeoutMs: 10000, // optional: ready event timeout (default: 10000)
maxPayloadSize: 50 * 1024 * 1024, // optional: max message size in bytes (default: 50MB)
maxPendingRequestsByMethod: { processData: 256 }, // optional: fail-fast local request limits
env: { RUST_LOG: 'debug' }, // optional: extra env vars for the child process
readyEventName: 'ready', // optional: name of the ready event (default: 'ready')
logger: myLogger, // optional: logger implementing IRustBridgeLogger
});
Socket connection options (passed to bridge.connect()):
interface ISocketConnectOptions {
autoReconnect?: boolean; // default: false
reconnectBaseDelayMs?: number; // default: 100
reconnectMaxDelayMs?: number; // default: 30000
maxReconnectAttempts?: number; // default: 10
}
Events 📡
RustBridge extends EventEmitter and emits the following events:
| Event | Payload | Description |
|---|---|---|
ready |
— | Bridge connected and binary reported ready |
disconnected |
IRustBridgeDisconnectedEvent |
Current transport closed, including intentional closure and the automatic reconnect gap |
exit |
(code, signal) |
Unexpected transport closure with no reconnect pending, or exhausted reconnect attempts |
stderr |
string |
A line from the binary's stderr (stdio mode only) |
reconnected |
— | Socket transport reconnected after unexpected disconnect |
management:<name> |
any |
Custom event from Rust (e.g. management:configChanged) |
Use disconnected to invalidate capabilities tied to an uninterrupted IPC
connection, including when there is no pending request. Before emitting it the
bridge marks itself unavailable and rejects pending calls. The payload contains
intentional, reconnecting, code and signal; socket closures have null code
and signal. During automatic reconnect it precedes reconnected and the next
ready. A listener can call terminate() to stop further reconnection.
Stale transports from a replaced lifecycle cannot emit this event. It does not
prove that a separately supervised daemon stopped or replace awaited
terminate() for confirmed teardown.
Custom Logger 📝
Plug in your own logger by implementing the IRustBridgeLogger interface:
import type { IRustBridgeLogger } from '@push.rocks/smartrust';
const logger: IRustBridgeLogger = {
log(level: string, message: string, data?: Record<string, any>) {
console.log(`[${level}] ${message}`, data || '');
},
};
const bridge = new RustBridge<TMyCommands>({
binaryName: 'my-server',
logger,
});
Writing the Rust Side 🦀
Your Rust binary needs to implement a simple protocol. The transport (stdio or socket) doesn't change the message format — only how connections are established.
Stdio Mode (Child Process)
-
On startup, write a ready event to stdout:
{"event":"ready","data":{"version":"1.0.0"}}\n -
Read JSON lines from stdin, parse each as
{"id": "...", "method": "...", "params": {...}} -
Write JSON responses to stdout, each as
{"id": "...", "success": true, "result": {...}}\n -
For streaming commands, write zero or more
{"id": "...", "stream": true, "data": {...}}\nchunks before the final response -
Emit events anytime by writing
{"event": "name", "data": {...}}\nto stdout -
Use stderr for logging — it won't interfere with the IPC protocol
-
Optionally support cancellation: add
"capabilities":["cancel"]to the ready event, then treat{"id":"...","cancel":true}as a request to stop that command at its next safe point. Answer the original id exactly once, either{"id":"...","success":false,"cancelled":true,"error":"..."}or its normal result when the command could no longer stop. Ignore cancel frames for ids that already finished or are unknown, and keep reading stdin while commands run so cancel frames arrive promptly.
Socket Mode (Daemon)
- Listen on a Unix socket (e.g.,
/var/run/my-daemon.sock) or Windows named pipe - On each new client connection, send the
{"event":"ready","data":{...}}\nevent - Read/write JSON lines on the socket (same protocol as stdio)
- Support multiple concurrent clients — each connection is independent
Here's a minimal Rust skeleton (stdio mode):
use serde::{Deserialize, Serialize};
use std::io::{self, BufRead, Write};
#[derive(Deserialize)]
struct Request {
id: String,
method: String,
params: serde_json::Value,
}
#[derive(Serialize)]
struct Response {
id: String,
success: bool,
#[serde(skip_serializing_if = "Option::is_none")]
result: Option<serde_json::Value>,
#[serde(skip_serializing_if = "Option::is_none")]
error: Option<String>,
}
#[derive(Serialize)]
struct StreamChunk {
id: String,
stream: bool,
data: serde_json::Value,
}
fn main() {
// Signal ready
println!(r#"{{"event":"ready","data":{{"version":"1.0.0"}}}}"#);
io::stdout().flush().unwrap();
let stdin = io::stdin();
for line in stdin.lock().lines() {
let line = line.unwrap();
let req: Request = serde_json::from_str(&line).unwrap();
match req.method.as_str() {
"ping" => {
let resp = Response {
id: req.id,
success: true,
result: Some(serde_json::json!({"pong": true})),
error: None,
};
println!("{}", serde_json::to_string(&resp).unwrap());
io::stdout().flush().unwrap();
}
"processData" => {
let count = req.params["count"].as_u64().unwrap_or(0);
// Send stream chunks
for i in 0..count {
let chunk = StreamChunk {
id: req.id.clone(),
stream: true,
data: serde_json::json!({"index": i, "progress": ((i+1) * 100 / count)}),
};
println!("{}", serde_json::to_string(&chunk).unwrap());
io::stdout().flush().unwrap();
}
// Send final response
let resp = Response {
id: req.id,
success: true,
result: Some(serde_json::json!({"totalProcessed": count})),
error: None,
};
println!("{}", serde_json::to_string(&resp).unwrap());
io::stdout().flush().unwrap();
}
_ => {
let resp = Response {
id: req.id,
success: false,
result: None,
error: Some(format!("Unknown method: {}", req.method)),
};
println!("{}", serde_json::to_string(&resp).unwrap());
io::stdout().flush().unwrap();
}
}
}
}
Architecture 🏗️
┌──────────────────────────────────────────────────────┐
│ RustBridge<T> │
│ (protocol layer: handleLine, sendCommand, events) │
├──────────────┬───────────────────────────────────────┤
│ StdioTransport │ SocketTransport │
│ spawn() + │ net.connect() + auto-reconnect │
│ stdin/stdout │ Unix socket / named pipe │
├──────────────┴───────────────────────────────────────┤
│ IRustTransport interface │
│ connect() / write() / disconnect() │
├──────────────────────────────────────────────────────┤
│ LineScanner (shared newline scanner) │
├──────────────────────────────────────────────────────┤
│ RustBinaryLocator │
│ (binary search — stdio mode only) │
└──────────────────────────────────────────────────────┘
RustBridge— The main class. Protocol-level logic (JSON parsing, request correlation, streaming, events) is transport-agnostic.StdioTransport— Spawns a child process, manages stdin/stdout/stderr, handles SIGTERM/SIGKILL.SocketTransport— Connects to an existing Unix socket or named pipe, with optional auto-reconnect and exponential backoff.LineScanner— Shared buffer-based newline scanner used by both transports for efficient message framing.RustBinaryLocator— Priority-ordered binary search (used by stdio mode only).
API Reference 📖
RustBridge<TCommands>
| Method / Property | Signature | Description |
|---|---|---|
constructor |
new RustBridge<T>(options: IRustBridgeOptions) |
Create a new bridge instance |
spawn() |
Promise<boolean> |
Stdio mode: Spawn and wait for ready; rejects invalid explicit selection, returns false for ordinary discovery/startup failure |
connect(socketPath, options?) |
Promise<boolean> |
Socket mode: Connect to a running daemon; returns false on connection/readiness failure and rejects stdio-only descriptor/byte-channel options |
sendCommand(method, params, options?) |
Promise<TCommands[K]['result']> |
Send a typed command with an optional per-call timeout or abort signal |
sendCommandWithSensitiveBytes(method, params, bytes, options?) |
Promise<TCommands[K]['result']> |
Send one exclusive JSON command with its raw bytes on the generation-owned one-shot pipe |
sendCommandStreaming(method, params, options?) |
StreamingResponse<TChunk, TResult> |
Send a streaming command with an optional abort signal; returns immediately |
terminate(options?) |
Promise<void> |
Confirm stdio child exit or local socket closure; gracePeriodMs controls SIGKILL escalation |
kill() |
void |
Fire-and-forget compatibility wrapper around terminate() |
running |
boolean |
Whether the bridge is currently connected and ready |
StreamingResponse<TChunk, TResult>
| Method / Property | Type | Description |
|---|---|---|
[Symbol.asyncIterator]() |
AsyncIterator<TChunk> |
Enables for await...of consumption of chunks |
result |
Promise<TResult> |
Resolves with the final result after stream ends |
RustBinaryLocator
| Method / Property | Signature | Description |
|---|---|---|
constructor |
new RustBinaryLocator(options: IBinaryLocatorOptions, logger?) |
Create a locator instance |
findBinary() |
Promise<string | null> |
Validate explicit selection or discover a binary; rejects invalid explicit selection; revalidates cached discovery results |
clearCache() |
void |
Clear the cached path to force a fresh search |
StdioTransport
| Method / Property | Signature | Description |
|---|---|---|
constructor |
new StdioTransport(options: IStdioTransportOptions) |
Create a stdio transport |
connect() |
Promise<void> |
Spawn the child process |
write(data) |
Promise<void> |
Write to stdin with backpressure handling |
disconnect() |
void |
Kill the process (SIGTERM → SIGKILL after 5s) |
disconnectAndWait(options?) |
Promise<void> |
Confirm child close after SIGTERM/SIGKILL escalation |
connected |
boolean |
Whether the process is running |
SocketTransport
| Method / Property | Signature | Description |
|---|---|---|
constructor |
new SocketTransport(options: ISocketTransportOptions) |
Create a socket transport |
connect() |
Promise<void> |
Connect to the Unix socket / named pipe |
write(data) |
Promise<void> |
Write to socket with backpressure handling |
disconnect() |
void |
Close the socket (does not kill the daemon) |
disconnectAndWait() |
Promise<void> |
Confirm local socket closure without signaling the daemon |
connected |
boolean |
Whether the socket is connected |
reconnecting |
boolean |
Whether an automatic reconnect timer or attempt owns the socket lifecycle |
LineScanner
| Method / Property | Signature | Description |
|---|---|---|
constructor |
new LineScanner(maxPayloadSize, logger) |
Create a line scanner |
push(chunk, onLine) |
void |
Feed a Buffer chunk; calls onLine for each complete line |
clear() |
void |
Reset the internal buffer |
Exported Interfaces & Types
| Interface / Type | Description |
|---|---|
IRustBridgeOptions |
Full configuration for RustBridge |
IRustBridgeRequestOptions |
Per-command options: { signal?, timeoutMs? } |
IRustBridgeStreamingRequestOptions |
Per-stream options: { signal? } |
IRustBridgeRemoteSettlement |
Remote outcome of a cancelled request: { outcome, result?, error?, errorCode?, errorData? } |
TRustBridgeRemoteSettlementOutcome |
'cancelled' | 'completed' | 'failed' | 'disconnected' |
IRustBridgeTerminateOptions |
Confirmed termination options: { gracePeriodMs? } |
IRustTransportDisconnectOptions |
Optional confirmed-disconnect grace period for owned process transports |
IBinaryLocatorOptions |
Configuration for RustBinaryLocator |
ISocketConnectOptions |
Socket connection options (reconnect settings) |
IRustBridgeLogger |
Logger interface: { log(level, message, data?) } |
IRustTransport |
Transport interface (extends EventEmitter) |
IManagementRequest |
IPC request shape: { id, method, params } |
IManagementResponse |
IPC response shape: { id, success, result?, error?, errorCode?, errorData?, cancelled? } |
IManagementCancelRequest |
IPC cancel frame shape: { id, cancel: true } |
IManagementEvent |
IPC event shape: { event, data, capabilities? } |
IManagementStreamChunk |
IPC stream chunk shape: { id, stream: true, data } |
ICommandDefinition |
Single command definition: { params, result } |
TCommandMap |
Record<string, ICommandDefinition> |
TStreamingCommandKeys<T> |
Extracts keys from a command map that have a chunk field |
TExtractChunk<T> |
Extracts the chunk type from a streaming command definition |
RustBridgeRequestError |
Request error class with stable code, optional responseErrorCode, responseErrorData, requestId, method, and remoteSettlement fields |
TRustBridgeRequestErrorCode |
Union of stable request error code strings |
License and Legal Information
This repository contains open-source code licensed under the MIT License. A copy of the license can be found in the license file.
Please note: The MIT License does not grant permission to use the trade names, trademarks, service marks, or product names of the project, except as required for reasonable and customary use in describing the origin of the work and reproducing the content of the NOTICE file.
Trademarks
This project is owned and maintained by Task Venture Capital GmbH. The names and logos associated with Task Venture Capital GmbH and any related products or services are trademarks of Task Venture Capital GmbH or third parties, and are not included within the scope of the MIT license granted herein.
Use of these trademarks must comply with Task Venture Capital GmbH's Trademark Guidelines or the guidelines of the respective third-party owners, and any usage must be approved in writing. Third-party trademarks used herein are the property of their respective owners and used only in a descriptive manner, e.g. for an implementation of an API or similar.
Company Information
Task Venture Capital GmbH Registered at District Court Bremen HRB 35230 HB, Germany
For any legal inquiries or further information, please contact us via email at hello@task.vc.
By using this repository, you acknowledge that you have read this section, agree to comply with its terms, and understand that the licensing of the code does not imply endorsement by Task Venture Capital GmbH of any derivative works.