In a regular WSGI service provider implementation there is a blocking HTTP server that services clients. When a client, for example, creates an invoice, the server simply makes a CRUD operation that creates rows in necessary tables. Then there is a worker - typically a shell script that uses the same set of models the server framework (MVC) uses. This worker (applied to the example), say, runs in cron every n seconds and checks the bank account for any new transactions. When a new one is found (and it matches the account of the previously created invoice), it does the CRUD again to update the invoice rows previously created, etc..Now, when we are talking about async HTTP server implementation (for example Python Tornado), how do we approach the 'workers' part? Because there still must be some process that checks the bank account for any new transactions. Do we just run one IOLoop, which inside runs the actual HTTP server app, as well as all the necessary 'workers', which are simply several separate apps, that, again, use the same model set from the main server app? I mean, we can potentially run the workers as completely separte processes from cron, but then async doesn't make much sense, does it? Or should the 'workers' be implemented comletely differently (eliminating the 'worker' concept?) and I am not grasping all the async stuff correctly? Thanks!
Async web server and associated 'workers' implementation
architecture;async;backend;blocking function call;service workers