Why are you reading data from the response object and not from the request object

[IonelLupu]

In this example you are reading the data from the response object. Shouldn't the data be read from the request object?

Usually, the user makes a request from the client to the server and that request contains the data. Then, the server reads that data from the request. After that, the server does some work and uses the response object to send data back to the client.

Ins't it the case here too?

[uasan]

Then it’s even more strange, if onData is a response method, why can’t it be used in another microtask, answer - because in fact onData is a method of the request object, but for some reason it’s in the response object )

[uNetworkingAB]

Honestly, it's splitting hairs. Consider it a quirk kept for backwards compatibility.

[slkerndnme]

We read data from request to prépare tje response. Literal wtf Le sam. 28 oct. 2023, 01:06, uNetworkingAB ***@***.***> a écrit :

…

Honestly, it's splitting hairs. Consider it a quirk kept for backwards compatibility. — Reply to this email directly, view it on GitHub <#982 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIUGDOFCMWGFV2EX3UNDBC3YBQ5ABAVCNFSM6AAAAAA6TGDS5WVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TIMBYGEYTQ> . You are receiving this because you are subscribed to this thread.Message ID: <uNetworking/uWebSockets.js/repo-discussions/982/comments/7408118@ github.com>

[uNetworkingAB]

It makes sense if you think of it like so:

"HttpRequest" in uws really is "HttpHead" and "HttpResponse" in uws really is "HttpRequest".

That is - uws is not designed like other Node.js "frameworks" because uws is not, "a framework" atop the given design of Node.js.

The same goes with onAborted. It too "does not belong" where it is, until you think of it like HttpHead and HttpRequest. Yes, this requires thinking outside of the Node.js universe.

That's why uws is fast, and not slow. Because it isn't a smooth brain replica of what everyone else is doing.