I'm working on a piece of code that will be able to hit multiple web APIs (hardware that has APIs telling about the machine status) not blocking when one is waiting on the other to wait for the response, once the response of one arrives it'll be emitted on a websocket. One requirement is not to kill the APIs so hit them let's say once per 5 seconds as long as the main process is running. The important part I'm struggling with is how to even approach it. What I did to this point is that the main process is spawning separate threads for different APIs and that thread is hitting the API emitting the response to the websocket time.sleep(5) and repeat. The main process is responsible to start new "workers" and kill ones that are not needed anymore also to restart ones that should be working but are not due to i.e. an exception. I have no idea if multi-threading is the way to go here - let's say I aim to "crawl" through 300 APIs. Is spawning long lived workers the right way to achieve this? Should those be processes instead? Should I maybe have the main process coordinate executing short-living threads that will do the API call and die and do that every 5 seconds per API (that seems way worse to maintain)? If the last option, then how to handle cases where a response takes more than 5 seconds to arrive? Some people are now talking about Python's asyncio like it's the golden solution for all issues but I don't understand how it could fit into my problem. Can someone guide me to the right direction? Continue reading...
