Request should allow WritableStream as body

[jimmywarting]

Now we can get a readable stream from the response, which is cool! But i think it needs a complementary WriteableStream for the request as well. Imagine being able to post more then what can fit into the memory or were you simply just don't have everything you need to post.

let ws = new WritableStream
let encoder = new TextEncoder
let writer = ws.getWriter()

fetch('api/upload', {
    method: 'post',
    body: ws
})

let uint8array = encoder.encode('chunk')

writeStream.write(uint8array)
writeStream.close()

But i guess the WritableStream has to be implemented first ^^

[annevk]

Duplicate of #88. I think we might offer ReadableStream-based uploads first. It's a little unclear how WritableStream can work still.

[domenic]

Yeah, we're actively working on this, although as you can see from #88 and other issues at https://github.com/yutakahirano/fetch-with-streams/issues, there are some complexities :-/.

Also, FYI writable streams are getting much closer to finalized :).

[jimmywarting]

Emh, just why is WritableStream unclear? Feels weird to have a ReadableStream based upload When you are writing to a stream that are sending stuff.

I'm trying to think of this like node's http server request

http.createServer((req, res) => {
  // here you have both a readable (req) from which you read what has been written by the client
  // and a writeable (res) that you write back to the client
})

Should be similar but the other way around, You write to the server and read from the response

[domenic]

The problem essentially is that Requests, as specified in Fetch, are timeless objects that can be carted around and used. They aren't tied to a specific actual fetch() call (i.e. a specific actual request). This means that associating a writable stream with each Request gets strange, as you have to then hook up the writable stream to a specific "actual writable stream" when the fetch() happens.

The design we settled on was instead that you could have a Request with a body that is a readable stream, which gets carted around along with the timeless Request object. Then, fetch() takes care of doing an invisible request.body.pipeTo(writableStreamRepresentingThisFetch) behind the scenes, once we've figured out what that writableStreamRepresentingThisFetch is. But writableStreamRepresentingThisFetch is never exposed to the user, by the nature of the timeless-Request model.

[wanderview]

And if you want to you can create pipe (identity transform, etc) to give yourself a WritableStream with a ReadableStream for the Response. This is explicitly opt'ing in to the buffering that this approach would require instead of the browser implicitly sticking a bunch of buffering in the path magically.

[jimmywarting]

I think i would use the identity transform trick...

But it's true that in most cases you send non-streamable object and often you have everything before making a ajax call so those need to be readable so just passing a readable is okey i guess.

But for something like JSZip it would have been nice if the lib could just write directly to the writableStreamRepresentingThisFetch where you zip a bunch of stuff and uploads them.

[ioquatix]

I may also comment on the other issue, but this is exactly the design I came up with in async-http: A Body::Writable is just a Body::Readable with an internal queue of chunks.

https://github.com/socketry/async-http/blob/master/lib/async/http/body/writable.rb

I think the design works well.

[an0ndev]

Just as an aside, the feature is still broken. See here for the commit and associated discussion: #425