Benchmarks

This run compares the local generated Codexa Core build using JetRouter with Express, Oak, Fastify, Hono, NestJS, and Thunder. Codexa uses Deno; Express, Fastify, and NestJS use Node; Oak, Hono, and Thunder use Deno. These are complete HTTP stack measurements, including runtime overhead.

Download the audited JSON · Read the complete report · Download raw evidence

What was measured

Every framework registers the same 1,004 definitions. The four workloads are a static JSON response at GET /hello, parameters at GET /users/:id, JSON parsing and common Zod validation at POST /users, and 64 varied paths drawn from 1,000 deeply nested parameterized routes. POST responses use the same deterministic ID and return status 201.

Thunder runs its unmodified file-discovery and hook dispatcher with named router registrations, following its official routing documentation. The exact source revision is recorded with the results. Optional database startup is excluded for every framework. NestJS uses real controllers with its Express adapter and standard response handling. Fastify uses the common Zod schema without an additional compiled response schema.

The raw Deno entry uses manual matching. A second, identical raw Deno entry is measured separately to detect run-order and machine variation; its control results are retained in the raw report rather than displayed as another framework.

Methodology

• Load: autocannon 8.0.0, 50 connections, pipelining 1, 3 seconds discarded warmup followed by 10 seconds measured per workload.
• Repetition: three rounds with fresh server processes and rotated framework and workload order. Only one tested server runs at a time.
• Correctness: exact response bodies and statuses are validated during load. Preflight checks also cover static/parameter overlap, missing routes, malformed JSON, and invalid body data. Response totals must agree with per-path and per-second counters.
• Reporting: rates are medians of completed responses divided by measured wall seconds. Each row shows the run range and coefficient of variation. Displayed p99 is the median of three per-run p99 values, not a pooled latency percentile.
• Provenance: npm and Deno lockfiles pin dependencies. The result records source hashes and verifies that Core, the generated package, and benchmark inputs stayed unchanged during measurement.

How to interpret this

108 timed samples and 22,252,810 responses passed the status, body, and counter audits. The client CPU warning threshold was crossed in 68 of 108 samples, so the faster entries may be limited by the load generator.

Client and server share a developer machine. The raw report flags samples where load-generator CPU exceeds 85% of one core and shows drift between identical controls. Close differences can be noise; the chart establishes neither a universal framework ranking nor maximum production capacity. Repeat on deployment hardware with a separate load-generator machine for capacity decisions.

This is a local build with JetRouter, not a measurement of the currently published JSR release. The historical September 7 results for Codexa Core 1.0.7 are preserved byte-for-byte under benchmarks/results/history/2026-09-07/. Download the historical JSON or read the original report. They used three route definitions, different dependency versions, and a different runtime version. Comparing those figures with this larger workload does not isolate the effect of replacing the routing engine.

Reproducing this

The reproducible harness lives in the Core repository at benchmarks/http/. Run the following from the Core project:

deno task build
cd benchmarks/http
npm ci --ignore-scripts
npm run prepare
node --test report.test.mjs
npm run validate
node run.mjs --rounds=3 --warmup=3 --duration=10 --connections=50
node report.mjs results/http-YYYY-MM-DDTHH-MM-SS-SSSZ

The timestamped run directory contains raw samples, latency data, request manifests, validation counters, and server logs. The audited summary is copied to benchmarks/results/results.json and results.md in Core and this documentation project; the chart reads the same JSON from src/data/benchmark-results.json.