There is absolutely no way that the process of creating a job, running it in a separate thread updating the UI to show that a job is running, calling the actual update value code, updating the UI to show the job has finished and finally transferring the result back to the GUI thread could possibly be as performant as a simply calling the update code in the same thread, no matter what you do in term of "asynchronous job dispatch". Not to mention that in python only one CPU bound thread can ever execute at a time.
The database backend already maintains a live view of the data in your sense of live. My meaning of live simply refers to the fact that unlike a GUI, HTTP is a pull, not push interface, or in other words, web pages do not typically update automatically when the underlying database updates. They only update in response to some user action.
As for not rewriting stuff, that obviously makes sense, prima facie, but in my experience shoe horning a software stack onto a problem that is a bad fit just to avoid re-writing some code ends up costing much more time in maintenance over the long term.
|