Currently the frontend has to call the /api/jobs/info route periodically (every 15 seconds) for all jobs it wants to keep up-to-date. This has some problems:
Inefficient: The status of most of these jobs will not change between two of these api calls, so there is a lot of unnecessary network traffic and database reads. This may not scale well with a lot of concurrent users
Since the pulling of the clients and the heartbeats of the runners are not synchronized, the data that the client pulls can be up to 15 seconds old. This means that not only will there be a 15 second delay between when the runner reports its progress to the backend, but there is also an additional 15 seconds delay from the progress arriving at the backend and the client pulling it (in the worst-case). This also means that to the user, transcription jobs take longer than the actually do (since the client possibly only knows about finished jobs 15 seconds later)
It can't keep everything up-to-date: Currently the Frontend will only call the jobs/info route for the jobs that it currently displays. This means that progress change will not be tracked of not displayed jobs (which may be a problem depending on the filter the user used) and it will also not query the jobs/list route. So if the user adds a new job from a different device (or just a different browser tab), it will not show up automatically
Proposed solution: Add a new route (like /api/jobs/subscribe) that provides a websocket endpoint. When a client calls this route a websocket connection will be created between client and server and the server stores this connection in an array. When the server receives a progress update from a runner over the heartbeat, it will forward it to all connections in that array. This will effectively notify the clients of a progress change, there is no need anymore for the clients to periodically query the api.
The /api/jobs/info route should stay unaffected by this since it will be easier to use than a websocket and some clients (like e.g. bash or python scripts) will still prefer to use it.
Currently the frontend has to call the /api/jobs/info route periodically (every 15 seconds) for all jobs it wants to keep up-to-date. This has some problems:
Proposed solution: Add a new route (like /api/jobs/subscribe) that provides a websocket endpoint. When a client calls this route a websocket connection will be created between client and server and the server stores this connection in an array. When the server receives a progress update from a runner over the heartbeat, it will forward it to all connections in that array. This will effectively notify the clients of a progress change, there is no need anymore for the clients to periodically query the api.
The /api/jobs/info route should stay unaffected by this since it will be easier to use than a websocket and some clients (like e.g. bash or python scripts) will still prefer to use it.