Joor

Type-safe RPC, compiled ahead of time

By Arpan Bhandari

Source: https://arpan.sh/projects/joor

A TypeScript RPC framework that keeps the server, client, and API documentation in sync through code generation.

I built Joor to keep an API's server code, client types, and documentation in sync. Defining the same operation in several places makes even a small change harder to trust. A renamed field can work on the server while an older client still expects something else.


Why I chose a compiler

Joor generates the dispatcher, client, and documentation from procedure definitions. I chose to do that work during the build, when the application already knows which operations exist.

That introduces a regeneration step, but it gives a change one place to start. It also keeps route discovery out of the request path. Types carry through to the client, while runtime validation still checks data arriving over the network.

Supporting several runtimes added another constraint. The same procedure should behave consistently on Node.js, Bun, and Deno, including when a request fails. I kept the core based on Fetch and handled runtime differences in adapters. Streaming made those differences particularly visible: cleanup after a disconnected client must finish even if the stream's own cancellation handler hangs.


Testing it with application traffic

In June 2026, I benchmarked Joor on Node.js with product lookups, dashboard reads, and quote writes. The requests used a local SQLite database, a shared cache, and per-app caching.

Across ten runs of 5,000 requests with 100 concurrent requests, Joor RPC measured 8.4 ms median latency and 11,346 median requests per second.

Joor is still pre-release. This write-up covers v1.0 development work ahead of the public repository [https://github.com/arpan404/joor].