I have a UI and a .NET C# backend server that communicates with each other. I have a route
/getBigFile that the UI calls on a button click, which the C# backend can take up to 60 seconds to create and return so the user can download it. (The file size can be anywhere between 1 kB to 600 MB.)
This would mean that the UI would have to wait with an open connection until C# returns the HttpResponse. This is obviously a bad design as it forces the user to stay on the webpage until the file comes back.
I thought of different solutions to go about this:
Stream the file to the UI so the download begins right away.
Have the C# backend return a httpResponse right away after launching an async job that creates the file, uploads it to S3 and emails the file upon success/failure. (Will the async job part even work if the client server connection is closed)
I am not sure which way would be better. The first way seems like the better UX choice, but when multiple users request big files, I feel like second choice will be handled more nicely if I implement it with a Queuing mechanism (using Amazon SQS or Redis. I don't really know how this will work though.)
I have never had to design something like this and any pointers and resources/guidance would be greatly appreciated!