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 that the C# backend can take upto 60 seconds to create and return so the user can download it. (the file can be as small as 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!

Thank you.

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!

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 that the C# backend can take upto 60 seconds to create and return so the user can download it. (the file can be as small as 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!

Thank you.

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 that the C# backend can take upto 60 seconds to create and return so the user can download it. (the file can be as small as 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!

Thank you.