I built a background service that monitors a folder every few seconds. When someone drops a file into this folder, my service 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 files through a browser. But I’m stuck on how to handle the waiting part. Here’s what happens:
- User uploads file via web form
- File gets saved to the input folder
- Web page shows… what exactly?
- Background service processes the file
- Results appear in output folder
- How does the web page know it’s done?
I thought of two approaches:
- Check the output folder repeatedly using JavaScript timers
- Make AJAX calls to check if the result file exists yet
Are there better ways to design this? Would something like TCP sockets or named pipes work better here? I can’t use .NET remoting because of some COM components I need to use.
Try a hybrid approach with file watchers and status tracking. Skip the constant polling - set up your background service to trigger notifications when jobs finish. Have your service write status updates to a simple text file that your web app monitors. When someone uploads a file, create a unique processing ID and matching status file. Your background service updates this file at key processing steps. The web interface checks that specific status file instead of doing broad polling - way less server load than constant database hits or directory scans. For the frontend, redirect users to a progress page right after upload. Show a processing animation while making periodic AJAX calls to check their job status. This works great with COM components since you don’t need complex inter-process communication, and users get responsive feedback.
redis pub/sub works great for this. set up a background service that publishes messages when jobs complete, then have your web interface subscribe to those channels. you’ll get instant notifications without polling or dealing with websocket complexity - updates only fire when something actually finishes.