Get Started

kkrpc is a TypeScript-first RPC library for communication channels that are not always HTTP: child processes, Web Workers, iframes, Chrome extensions, Electron, Tauri, WebSocket servers, and message buses.
HTTP is supported, but the core design is transport-agnostic. If you only need an HTTP application API, tRPC may be a better fit. If you need one typed API surface across runtimes, kkrpc is the intended tool.
Install from npm
Section titled “Install from npm”npm install kkrpcbun add kkrpcpnpm add kkrpcInstall from JSR
Section titled “Install from JSR”deno add jsr:@kunkun/kkrpcnpx jsr add @kunkun/kkrpcbunx jsr add @kunkun/kkrpcpnpm dlx jsr add @kunkun/kkrpcFirst RPC Call
Section titled “First RPC Call”This example uses WebSocket, but the wrap() and expose() pattern is the same for other evented transports.
import { expose } from "kkrpc"import { webSocketTransport } from "kkrpc/ws"import { WebSocketServer } from "ws"
const api = { math: { add(a: number, b: number) { return a + b } }, async greet(name: string) { return `Hello, ${name}` }}
export type API = typeof api
const wss = new WebSocketServer({ port: 3000 })
wss.on("connection", (socket) => { expose(api, webSocketTransport(socket))})import { wrap } from "kkrpc"import { webSocketClientTransport } from "kkrpc/ws"import type { API } from "./server"
const api = wrap<API>(webSocketClientTransport({ url: "ws://localhost:3000" }))
console.log(await api.greet("World"))console.log(await api.math.add(1, 2))Bidirectional Channels
Section titled “Bidirectional Channels”Use RPCChannel when both sides expose APIs or when you need explicit ownership and cleanup.
import { RPCChannel } from "kkrpc"
const channel = new RPCChannel<LocalAPI, RemoteAPI>(transport, { expose: localAPI })const remote = channel.getAPI()
await remote.ping()channel.destroy()HTTP is the exception: it is unary request/response and does not support callback arguments or server-initiated calls. Use WebSocket, stdio, workers, iframes, desktop IPC, or message buses for bidirectional traffic.
Pick An Entry Point
Section titled “Pick An Entry Point”| Use case | Import |
|---|---|
| Core proxy/channel API | kkrpc |
| Browser-safe explicit core entry | kkrpc/browser |
| Deno-friendly core entry | kkrpc/deno |
| Web Worker | kkrpc/worker |
| Child process stdio | kkrpc/stdio |
| HTTP | kkrpc/http |
| WebSocket | kkrpc/ws, kkrpc/ws/hono, kkrpc/ws/elysia |
| iframe | kkrpc/iframe |
| Chrome extension | kkrpc/chrome-extension |
| Electron | kkrpc/electron |
| Tauri | kkrpc/tauri |
| Message buses | kkrpc/rabbitmq, kkrpc/kafka, kkrpc/redis-streams, kkrpc/nats |
| Plugins and codecs | kkrpc/validation, kkrpc/middleware, kkrpc/superjson, kkrpc/inspector |
Optional Peer Dependencies
Section titled “Optional Peer Dependencies”Only install the integrations you use. For example, WebSocket servers commonly need ws, Hono integration needs hono, RabbitMQ needs amqplib, Kafka needs kafkajs, Redis Streams needs ioredis, and NATS needs @nats-io/transport-node.
Next Steps
Section titled “Next Steps”- Read the HTTP example for request/response APIs.
- Read the WebSocket example for bidirectional RPC and callbacks.
- Read the stdio example for child process communication.
- Read the validation guide and middleware guide for plugins.
- Read the design reference if you want to implement a custom transport or another language client.