Closed Gambero81 closed 2 years ago
yes, it can work, the sole purpose of this lib was to write chunks of data being generated on the client side as a stream to the hard drive.
but it have some drawbacks. StreamSaver mimics what backend server dose by responding with a content-disposition attachemnt header and opens up that request to trigger a download. This dose not work in safari so it generates a blob and holds everything in memory and then download it.
also b/c the webpage takes control of writing data to the disk then clients are also forced to stay on the page as well until it's completed. it dose not do any background download like normal even do it looks like it
so my recommendation are if the data is coming from the server and you have control over it, then it's always best to download it directly from the server in background instead of having to mimic what a server dose with StreamSaver.js
so my recommendation are if the data is coming from the server and you have control over it, then it's always best to download it directly from the server in background instead of having to mimic what a server dose with StreamSaver.js
I have control on server (ASP.NET Core) but the request is made from gRPC method who return a IAsyncEnumerable<byte[]>
how can i set a content-disposition header in this mode?
the only solution to save binary stream from a gRPC request i found is using StreamSaver..
there is a better way?
I suppose you can't use gRPC do download a file if you want to avoid any client side solution like streamsaver, it needs to be opened using a navigation so the browser can do the "default thing" which is to save the data when it's unable to render the content. You can't use ajax, gRPC or websocket to fetch the data. it needs to be opened using a regular link, an iframe or a <form>
submit
I don't know anything about .NET or gRPC, but from my understanding gRPC is just a client-to-server communication via some websocket of some sort?
the server should at very least add a Content-Disposition: attachment header in the response with a filename
Content-Disposition: form-data; name="fieldName"; filename="filename.jpg"
then you can include other helpful headers like:
content-length
will tell how large the file is and estimate the downloadcontent-type: application/octet-stream
will mostly make the browser incompatible of rendering the content so it will forcefully try to save the response insteadAccept-Ranges: bytes
could technically make a download resume/pause-able and allow for retry attempts when download fails or drops the connection.maybe something of this resources can help you
I would like to replace rest with gRPC in my web app. The only feature who is not very well replaced with grpc is file download.
Actually i can download a file from server by chunk with grpc but it require to full download in memory, then i can save to disk.
This library seem to solve this issue allow to read from server with grpc by chunk and stream to disk by chunk.
It's a good solution?
What about download speed performance? (my choice for grpc over rest is performance reated)