The issue that stands out to me with this is its not using coroutines. Python developers who don't know everything about the GIL, threading, blocking v non-bloc

The issue that stands out to me with this is its not using coroutines. Python developers who don't know everything about the GIL, threading, blocking v non-blocking sockets, processes, all of that can of worms, are going to try regular blocking I/O (that they might have done fine in PHP) leading to horrible performance. I think the choice to do this with 'threads' in Python (not real threads) = very bad. I think you can have multiple processes here but if you're using just Python for the web server the overhead is going to be massive for an interpreter... The correct approach would have been to have an event loop in every process handling 1 - however many clients for the server. Then async I/O functions can be done inside the app routes without potentially impacting the performance of every other client being processed. The software here seems to use Flask for the underlying server stuff (when running from Python.) But anyone whose tried to use flask for a web project before knows that its slow AF since it loads everything one after the other. When looking that up I think you can tweak the number of processes it uses but IMO: it's not the right approach.