hono-jev-router

How we reviewed this: we ran it in Docker on Node 24 with a local stand-in for the API, ran its tests, captured a real request payload, and injected faults — a 500, and a server that never replies.

What it does

hono-jev-router, by Yusuke Wada (Hono’s author), lets you register a route with a description instead of a path:

app.on('jev', 'requests about resetting a password', handler)

Path routes are matched first by Hono’s normal trie; the Jev dispatcher is appended last, so anything that matches a path wins. For everything else, one request asks a Noul per description:

A router has a handler for requests described as “…” (the description may be in any language). Is this HTTP request one that the handler should receive?

Code compares against a threshold and takes the first description over it. One request per dispatched HTTP request, however many routes you have. Seven tests, all passing offline.

Two failure modes worth knowing

A Jev failure is an app failure. The dispatcher doesn’t catch, and the fetch has no abort signal. With the stand-in returning 500, the client got a 500 from the app. With the stand-in accepting the connection and never replying, the request was still pending after eight seconds, with nothing to stop it. Because this is the app’s router, every request that reaches the dispatcher waits with it. The README warns about latency and cost; this is the part to add.

Duplicate descriptions collapse. Probabilities are keyed by the description text, so two handlers registered with the same sentence share one key, and the lookup takes the first. We scored the second one at 0.9 and the first handler ran.

Also: with no key configured, the header is sent as Bearer undefined rather than failing fast — which on a platform where the binding name is a typo away is a 500 with a confusing cause.

What it sends

The state is the method, the full URL, the headers and (for text-ish content types) up to 4 KB of the body. Authorization and cookie headers are redacted; the query string and the body are not. Our captured payload contained a reset token in the URL and a password in the JSON body. If you route authenticated or form-carrying requests, that is what leaves your process.

Nothing is written to disk, and the key never appears in the state.

Verdict

As an experiment — the author’s own word — it is a clean one: small, readable, and it composes with normal routing rather than replacing it. The README already tells you not to use it for authorization.

Before it could be more than an experiment it needs a timeout, a catch that falls through to your 404 handler, and unique keys for descriptions. The data question is yours: this router sees whole requests.

For routing by capability rather than URL, see JevRouter and jev-gateway.

See how it compares with other tools in Best Jev tools, tested hands-on.

Review updated Sep 20, 2026. Numbers quoted from the project are its author's own; we don't publish our own measurements of Jev.