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"}`	Error correlated by ID; `errorCode` is 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)

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();

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 only abandon the local TypeScript wait. They do not kill or disconnect the shared bridge, late responses are ignored, and later commands can continue using the same bridge.

The JSON-lines protocol has no cancellation message. After a command has been written, Rust may still execute it even if the local wait times out or is aborted. 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 elapsed
`ERR_RUST_BRIDGE_REQUEST_ABORTED`	The caller's signal aborted the local wait
`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.

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 });

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, its value is available as responseErrorCode on that error.

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. 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

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();
// Result is cached — call clearCache() to force 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'])
  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)
  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
`exit`	`(code, signal)`	Transport closed (process exited or socket disconnected)
`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`)

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": {...}}\n chunks before the final response
Emit events anytime by writing {"event": "name", "data": {...}}\n to stdout
Use stderr for logging — it won't interfere with the IPC protocol

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":{...}}\n event
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 the binary and wait for ready; returns `false` on failure
`connect(socketPath, options?)`	`Promise<boolean>`	Socket mode: Connect to a running daemon; returns `false` on failure
`sendCommand(method, params, options?)`	`Promise<TCommands[K]['result']>`	Send a typed command with an optional per-call timeout or abort signal
`sendCommandStreaming(method, params)`	`StreamingResponse<TChunk, TResult>`	Send a streaming command; 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>`	Find the binary using the priority search; result is cached
`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? }`
`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? }`
`IManagementEvent`	IPC event shape: `{ event, data }`
`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`, `requestId`, and `method` 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.

readme.md

@push.rocks/smartrust