Last 12 weeks ยท 11 commits
2 of 6 standards met
Hono's Node.js adapter was underperforming compared to h3, fastify, and koa โ especially on body parsing. These changes bring Hono from 4th place to 2nd, virtually tied with h3. Addresses #76 On my macOS (M1-Max) Before After Improvement Benchmarked with bun-http-framework-benchmark using at 500 concurrent connections for 10s per test. Changes 1. Direct body reading from () The biggest bottleneck was body parsing. When or was called on the pseudo-Request, it triggered a long chain of allocations: This created 5+ intermediate objects and piped the body through multiple stream conversion layers on every request. The fix overrides , , , and on the request prototype to read directly from the Node.js using event-based I/O: If is later called (e.g. user accesses ), the cached buffer is reused as the body source to avoid double-consumption. Falls back to the original path when the full object has already been materialized. 2. URL construction fast-path () was called for every request purely for validation and normalization. Since Hono's and both do string-based parsing (no URL object needed), we skip for common requests: Fast path: validate host with a charCode loop, concatenate Slow path: fall back to only when is present in the path (needed for path normalization) 3. optimization () Added check before iterating headers. In the common case (no cookies), this skips the per-header string comparison against . Thanks for the great lib :)
I was creating a custom server which would serve built css/js files, the files are hashed which means I can make their cache-control headers immutable. does not have an option to set any custom headers, so I added a new option that takes a function which can set custom headers and has the context as a parameter. I have updated the tests and Readme to reflect the changes.
Repository: honojs/node-server. Description: Node.js Server for Hono Stars: 593, Forks: 84. Primary language: TypeScript. Languages: TypeScript (98.7%), JavaScript (1.3%), HTML (0%). License: MIT. Homepage: https://hono.dev Topics: hono, http-server, nodejs, server. Latest release: v1.19.9 (1mo ago). Open PRs: 15, open issues: 29. Last activity: 1w ago. Community health: 37%. Top contributors: yusukebe, usualoma, tangye1234, tavvy, Jayllyz, nakasyou, tsctx, beeequeue, alexfriesen, alumowa and others.
TypeScript
Hello here, I am starting to suspect something odd in @hono/node-server We have random ReadableStream is already closed in the app, everything is try/catch but anyway it crashes the container. We are also using GraphQL Yoga, I found out about this: https://github.com/honojs/node-server/issues/77 But I hesitate to do that because GraphQL Yoga is using @whatwg-node/fetch which is supposed to be a good abstraction. the full trace is: Of course I don't reproduce easily, it happens randomly Any idea? to identify the problem better?