Streams are a totally different use case. Streams are used when you want to process data one part at a time without having to have all of the data in memory at once.
*edit: typo
With a promise (or rather, following the promise specification) you instead get back an object that you choose how to handle. That object is either pending or else an immutable success or failure result. Either success or failure will be called (not both), and whichever result is called can only be called once. As such, promises allow you to avoid inversion of control and to safely interact with potentially untrusted code.
This great series of articles helped me understand this: http://blog.getify.com/promises-part-2/
A queue of promises would be similar to a stream.
var stream = fs.createReadStream(__dirname + '/data.txt');
stream.pipe(res);
and if streams become a better and better option as response sizes get larger and larger. The streams syntax is nicer looking in any case.
fs.readFile(...) reads the entire contents of the file into memory. For small files that may be acceptable but if you're dealing with anything that could be large it's not going to be very pleasant or even work properly.
I just tried it out on my laptop for a 100MB and a 1GB file. For a 100MB file using streams is about 25% slower. However the sync method failed for the 1GB file:
Style 100MB 1GB
===== ===== ===
fs.readFileSync .176s <failed>
streams/pipe .234s 1.25sDefault buffer size seems to be 64k: https://github.com/joyent/node/blob/912b5e05811fd24f09f9d652...
Stream buffering: http://www.nodejs.org/api/stream.html#stream_buffering
For example, can you use ffmpeg to pull live video via rtsp, re-encode and pipe to nodejs for it to stream down to browser and to be consumed by html - with or without a plugin?
Any working code sample?
While this is not exactly what you are talking about, I think it demonstrates that node.js streams can do that too.
Install via:
npm install -g stream-adventure
stream-adventure