Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adhere to the full Streams API #159

Open
mcollina opened this issue Apr 10, 2018 · 4 comments
Open

Adhere to the full Streams API #159

mcollina opened this issue Apr 10, 2018 · 4 comments

Comments

@mcollina
Copy link

Currently send does not implement the Streams API (even if it inherits from Stream), and in fact inside send(..).pipe(res), it does stream.pipe(res).

Specifically, we had to use an "hack" to make it work well on Fastify. See fastify/fastify-static#46, where we had to pipe it through a modified PassThrough.

I'm thinking of changing the API to something:

const { stream, headers, statusCode } = await send(req, path, options)

As well as:

send(req, path, options, (err,  { stream, headers, statusCode }) => {
  // ...
})

I would like to also remove the dependency on on-finished and some of the others modules that were needed in the 0.8/0.10 days.

I think this work should help as well with http2 compatibility as well. I'm happy to prototype this work in a forked module as well, just let me know.

cc @apapirovski

@dougwilson
Copy link
Contributor

Yea, definitely would like to see. Node.js 0.8 will be dropped with the next major but 0.10 support won't be removed anytime soon, so if it's possible to still support 0.10 that would be super awesome.

@dougwilson
Copy link
Contributor

FWIW I feel like the current API is pretty janky so totally open to an API that flows better, especially the output side. Many would like to see this write to a transform stream to do transformations, which sounds like you're ask too.

@dougwilson
Copy link
Contributor

In addition for Node.js versions, everything in this org tries to support as many Node.js versions as possible -- it's part of our philosophy. We have the ideal support line (down to 0.10 currently) and the hard line of must go down to at least (4.0 currently). Really the minimum version is negotiable between those two, and if 0.10 isn't picked there should be some good reasons to why it's impossible to support lower (in the past we have used compat helps like on-finished to accomplish tasks like this, so perhaps it's just to make a new one).

@mcollina
Copy link
Author

Yes, I need to apply a transform afterwards (compression).

I'll see what I can come up with, I'll target Node 4, and then we can see if we can stretch it to 0.10.

I'm in your same shoes for backward compat, as readable-stream@2 (pulled from Node 8) supports down to Node 0.8.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants