I built a service that monitors a folder for new files every few seconds. When someone drops a file there, my program picks it up, does some work on it, and saves the results to another folder.
Now I want to add a web interface so users can submit jobs through a browser instead of manually copying files. But I’m stuck on how to handle the waiting part.
Here’s what happens:
User uploads file through web form
File gets saved to the input folder
How do I show progress or status on the web page?
My background service processes the file
Results appear in output folder
How does the web page know when it’s done?
I thought of two approaches:
Check the output folder repeatedly using JavaScript
Create an API endpoint that the webpage can ask about job status
Are there better ways to architect this? Would TCP connections or named pipes work better here? I can’t use .NET remoting because of a COM component dependency.
nice setup! why not use websockets for real-time updates? your web page would get instant notifications when jobs finish - no more constant polling. what’s the com component processing exactly? knowing that would help me suggest the best approach for your situation.
Go with the API endpoint approach. Create a unique job ID when the file uploads and store job metadata in a simple database table or JSON file. Your background service updates the status as it processes files, and your web page polls the API every few seconds for progress updates. This scales well and handles browser refreshes or network drops. I built something similar for document conversion - polling every 2-3 seconds gives users good feedback without hammering the server. You can even return estimated completion times based on file size and your historical processing data.
i totally agree! having a db to track job status makes everything way simpler. plus, you can handle multiple jobs way better this way. also, your web ui can show more detailed info, like when each job started and ended, which is super useful!