Make Req and Res a Stream

[Wallacy]

Hello,

First, tanks for the project, very good to see a project with a performance goal in mind.

So... Its possible to make Req and Res (from ws or/and http) a Node Stream?

*quick reference: "https://www.freecodecamp.org/news/node-js-streams-everything-you-need-to-know-c9141306be93/"

Current the core HTTP/TCP stack is already a stream object, and this a very userfull feature. Of couse we can do some kind of intermediary stream like you did on the video sample, but the full drain/cork/uncork/pipe/unpipe... cicle probably can be made on the c++ side (plugin/addon/host) improving performance and reducing the some type conversions.

[ghost]

Hi,

From v0.15 and forward the project is not concerned with or tied to any particular Node.js design. So this means it does not try to mimic any particular interface such as Node.js Streams or anything like that.

It also does not try and mimic Express or anything similar.

[Wallacy]

Understood.

Anyway, the Stream interface probably is very good for you C/C++ side too (IMHO). It's an interesting pattern.
Basically it is only necessary to implement these methods:

	Readable Streams	Writable Streams
Events	data, end, error, close, readable	drain, finish, error, close, pipe, unpipe
Methods	pipe(), unpipe(), wrap(), destroy()	write(), destroy(), end()
	read(), unshift(), resume(), pause(), isPaused(), setEncoding()	cork(), uncork(), setDefaultEncoding()

And you already have some functions using the same logic (like getBufferedAmount / onAborted, onWritable etc) to make a good pipe. Then at the end of the day, it may not require many changes.

My only concern is to reduce some of the hacking necessary to make a streaming (as in the example), avoiding things like "buffer.buffer.slice".

Anyway, thank you very much for your attention.

[ghost]

not concerned with or tied to any particular Node.js design

What Node.js does with their streams has no significance to this project. If you see similarities - good - but that doesn't mean anything more than that there are similarities.

The entire premise, the hypothesis of this project since day 1 has always been and will continue to be:

"Node.js is doing things unreasonably inefficient."

In other words - the differences between this project and Node.js is no act of random.

[ghost]

I just remember I have a lot of opinions on this subject.

[mattfbacon]

A stream is the opposite of "unreasonably inefficient". It can obviate several trips through std::string, std::string_view, etc. For example when writing JSON, most JSON APIs allow you to write to an ostream.

I would really appreciate this. Your'e not mimicking anything by using arguably one of the best features of C++.

[ghost]

Nobody is talking about "a stream". We already do implement "a stream". What was brought up was to change to the Node.js Streams API. How do you expect an ostream to map to the API we have today? There is no buffering, so it doesn't even fit together.

[mattfbacon]

Streams don't need to be buffered. I think they were just referring to the ABC std::ostream, so you could pass it to a function taking it, or use existing << overloads, etc. I know for one that in my use of this library one of the first thing I've done is implement an ostream wrapper around the Response, because it makes things easier to manage.

[ghost]

If C++ streams don't need to be buffered then how do you handle (async) backpressure? If you pass std::cout a string that is very big, it will block the process until stdout can take everything. This is not how uWS does it, we cannot have the process block on backpressure.

[mattfbacon]

Whatever you do in the Response's write method, you can do in std::ostream's operator<<.

[ghost]

The write method is buffered. You shouldn't use it unless passing small chunks. tryEnd is unbuffered and what you should use primarily. The C++ streams do not expose interfaces such as tryEnd or tryWrite they just take whatever they are given and either blocks or buffers what cannot be written.

[yamiteru]

Isn't it faster for c++ to work with an array of bytes anyway? We don't even need streams as in NodeJS streams. We just need UInt8Array. Are you sure it wouldn't make things faster?

[mattfbacon]

Maybe if you have all the bytes up-front, but not if you have to do a bunch of copies and heap allocations to get that single contiguous buffer.