allow to run tests using uWebSockets.js + uwebsockets-express

[endel]

Hi there, I maintain the uwebsockets-express project, which aims to keep compatibility between Express and uWebSockets.js

I understand this PR may be out of scope, though it may be helpful in case anyone is curious how Express can perform when used in conjunction with uWebSockets.js.

# Run load test with Express 4
npm run load -- --node=22.19.0 --uws --overrides='{"express":"^4", "uwebsockets-express":"1.3.13"}'

# Run load test with Express 5
npm run load -- --node=22.19.0 --uws --overrides='{"express":"5.1.0", "uwebsockets-express": "2.0.0"}'

Cheers and Happy Holidays

[wesleytodd]

Hey @endel, this is totally in scope. I would love for us to have this support, but unfortunately this PR is a bit invasive to get the job done. Could you help me better understand the goals of the approach to this integration, what is technically required to support uWebSockets, and maybe sort out a way to simplify the code integration to achieve the support?

[andrehrferreira]

I disagree with that for several reasons. First, because uWebSockets is a C++ project, which will generate completely inaccurate results when compared to HTTP servers implemented using the Node.js HTTP standard. Second, and no less important, the uWebSockets developers were very unpleasant to me when I interacted with them, and I prefer not to have that kind of toxicity in the project.

[bjohansebas]

Just to clarify, the fact that this is a C++ project does not mean we can’t support it. In Express there was work done so that developers could use uWebSockets or their own implementation; it just wasn’t completed for Express 5 due to lack of time (expressjs/express#3213). Because of that, I don’t see it as a bad thing, and it’s actually something I’d like us to achieve for Express, to decouple ourselves from it a bit. Keep in mind that in Node.js you can pass implementations of IncomingMessage and ServerResponse through http.createServer.

Also, let’s not allow having had a bad experience with some developers using that technology to affect decisions that could benefit the Express community. We’re all free here to share opinions and make certain decisions, but we should reach a point where we agree on whether this is good or bad. @wesleytodd asked for some clarifications on this (which I was also waiting for). Let’s get to a point where we either merge this or, as a team, decide to close it.

[andrehrferreira]

uNetworking/uWebSockets.js#1096

According to the uWebSockets.js maintainer himself:

"The only benchmark that matters is uWS vs. Node.js. These "frameworks" are irrelevant and pointless to track, as they all build on Node.js."

If this person thinks they're so great that they call Express irrelevant, when it's the biggest HTTP framework in Node.js, why would we add support for it to our performance pipeline?

[GroophyLifefor]

Hi Andre, I have read many of your comments in issues and PRs, and right now it feels like things are getting a bit emotional. I completely understand you. In the open source ecosystem there is often too much ego and toxicity, but uWS is not like against us or Express.js.

I want to share my thoughts about the PR, and I hope that if someone from uWS reads this, they do not get angry with me. Likewise, I hope you do not get angry with uWS. In the end, these are just projects.

I think uWS implementation is a good proposal, but not the right time. At the first we should focus on http, not uWS.

[andrehrferreira]

@GroophyLifefor How are you all doing?

The reason I started the thread that resulted in the formation of this performance group is to improve Express. This type of request, in my view, is increasingly hindering us from achieving that goal. I would like to ask everyone in the group to focus more objectively on improving Express performance, and nothing else matters at this moment. Everything else is just window dressing, nothing objective. Especially if you want to support uWS, no problem, just create middleware like everyone else does. This is an Express performance group.