llhttp VS undici

In the source code of the Node.js opensource project, lib folder contains JavaScript code, mostly wrappers over C++ and function definitions. On the contrary, src folder contains C++ implementations of the functions, which pulls dependencies from the V8 project, the libuv project, the zlib project, the llhttp project, and many more - which are all placed at the deps folder.

Some useful libraries include nghttp2 for HTTP/2 and llhttp for HTTP/1.1. Both are network stack and TLS implementation agnostic.

There is a HTTP parser directly bundled in node (https://github.com/nodejs/llhttp)

Those wasm blobs are Node's own llhttp https://github.com/nodejs/llhttp in wasm to speed up HTTP parsing.

The question is totally legitimate but please assume core doesn't make "load random binary" level kind of goofs :)

For HTTP, you have to look at HTTP parser. For example, https://github.com/nodejs/llhttp is used in NodeJS.

Whoa, I didn't know that! But yeah, it seems like https://github.com/nodejs/http-parser is based on nginx. It now uses https://github.com/nodejs/llhttp but has some of the same legacy.

On the other hand, deno's HTTP stuff is built on top of Hyper, a Rust library https://github.com/hyperium/hyper

No, parsing HTTP/1.x is a nightmare and definitely not simple. It wasn't even particularly well defined until 2014 when the original RFCs were modernized, and even now there are bugs reported in HTTP parsers all the time.

Node.js came out in 2009, a full ten years after HTTP/1.1 (RFC 2068) and it's original http-parser is full-on spaghetti code, doesn't conform to the RFCs for performance reasons, and is considered unmaintainable by the author of it's replacement[0]

[0] https://github.com/nodejs/llhttp

Yeah: interestingly, they had a test for the biggest category of frame, but not for the two other categories: https://github.com/nodejs/undici/blob/main/test/websocket/se...

The test I contributed is very specific to the frame fix I made, but I should probably go back and contribute more tests in send.js that test other lengths too.

The native fetch in Node.js 18 is based on undici.

Sadly, Undici's slow. Reference issue.

Did you try just using the http lib, or even axios/node-fetch? The fetch API in node is very new and looks like there have been concerns about its performance: https://github.com/nodejs/undici/issues/1203

A library that can be handy is Undici - a great HTTP/1.1 client, see here where they apparently added unix:// support: https://github.com/nodejs/undici/pull/226

Afterwards, create your new project and install our lone requirement [undici](https://github.com/nodejs/undici) to make HTTP requests in Node.js by running:

Test coverage currently sits at 89%, hopefully will be stable soon.

undici

We implemented fetch API operation with Node without the need for any library imports. The thing to note that under the hood that the fetch implementation is done based on another HTTP client, undici, which is actually a HTTP client written specifically for Node.js. It is an HTTP 1.1 only client.

> ...enough insights of how much better/faster Deno is

We moved our Deno project to Node because of lack of lower-level APIs on their Conn interfaces [0][1], but otherwise for our use-case (lots of tiny HTTPS connections) Deno absolutely blew Node out-of-the-water. Even at p50 (100tps) Deno (v1.18) was 10x faster than Node (v17.x) [2]

RAM wise, I found Deno (v1.18+) use 10M or so higher for the same code-base.

[0] https://github.com/denoland/deno/issues/13636

[1] https://github.com/denoland/deno/issues/9109

[2] https://github.com/nodejs/undici/issues/1203#issuecomment-10...