Support Upload Stream about async-graphql

[sunli829]

Actually, I am preparing to implement Read for Upload, which will probably be completed tomorrow. Because this depends on the new parser.😁

[nicolaiunrein]

Sorry didn’t realise. That’ll awesome!

[sunli829]

This is very difficult to achieve, and I don't think GraphlQL can do it. 🙂

[sunli829]

So I was reading about it, I think it would be possible but only when you have one file. In theory we could get a stream of the body directly from the TCP stream after we read the query and the map of files.

You are right, it can indeed be optimized when only one file is uploaded, I will think about it. 🙂

[sunli829]

I'm also leaning towards the first option, and I want to remove the dependency on the actix-multipart to make it more compatible with other web servers. The actix-multipart input is Stream<Item=Bytes>, but I want it to be an AsyncRead. I searched existing crates and didn't have a working asynchronous multipart parser, so I probably had to write a new one.

Then add a function like Schema::query_from_request<R: AsyncRead>(&self, content_type: &str, body: R), should be easier to use.

[nicolaiunrein]

Sounds good. 👍

[sunli829]

I ended up choosing the first option because the second option had some problems with the order of requests.

[Sytten]

@sunli829 I was reading the code and as far as I understand the file needs to be completely uploaded (either in memory or in temp) before it is returned as an async stream. This is not great for large files where you might want to stream the data without buffering it. Unsure if it is doable though.

[Sytten]

So I was reading about it, I think it would be possible but only when you have one file. In theory we could get a stream of the body directly from the TCP stream after we read the query and the map of files.

But if you upload more than one file you need to buffer for sure to the disk. Still for a lot of cases it would be a worthwhile optimisation. Just unsure if you want to support it @sunli829

My use case is that users are uploading large files to the server and since tempfile is used I can't just move them where I want, I have to copy them so for a bit of time I have 2x the disk usage which is annoying. An alternative that would work for me would be to have a named file, so maybe that would be a better approach (just another feature flag).

[nicolaiunrein]

I‘m reading this thread since I originally opened the issue. I currently do not use this library anymore. Just wondering @Sytten can‘t you just persist the tempfile? In general I think it would be good if one could get a reference to an AsyncRead of the uploaded content.