"...and you won't have to worry about locking your app at all." But I don't worry about locking at all. That was the point.
Yeah, building the admin in something else but connect to the same DB would make sense but it's a tonne of other problems. Now I can use the same base class for all views which means I can share a lot of functionality that I also need in the admin dashboard. E.g. the authentication.
Yeah, if the whole site was to sit on top of a slow database I wouldn't choose Tornado. But if that was the case I think I'd just use an async library and continue to use Tornado. :)
Alternatively you could host your admin app behind a WSGI server (e.g. gunicorn). You'd lose all of Tornado async capabilities (e.g. tornado.httpclient, tornado.auth modules) and you'd have to refactor your app to isolate admin code into a separate module, but I think it's worth it. WSGI will automatically fork for new requests and you won't have to worry about locking your app at all.
Nevertheless I think that using Tornado for fully sync apps (even when hosting behind WSGI) is a bit pointless. The entire point of Tornado is to be asynchronous. That's why I tend to use it only when I know the app's gonna be fully async and alongside a "regular" app written in, say, Flask.
Comment
"...and you won't have to worry about locking your app at all."
But I don't worry about locking at all. That was the point.
Yeah, building the admin in something else but connect to the same DB would make sense but it's a tonne of other problems. Now I can use the same base class for all views which means I can share a lot of functionality that I also need in the admin dashboard. E.g. the authentication.
Yeah, if the whole site was to sit on top of a slow database I wouldn't choose Tornado. But if that was the case I think I'd just use an async library and continue to use Tornado. :)
Parent comment
Alternatively you could host your admin app behind a WSGI server (e.g. gunicorn). You'd lose all of Tornado async capabilities (e.g. tornado.httpclient, tornado.auth modules) and you'd have to refactor your app to isolate admin code into a separate module, but I think it's worth it. WSGI will automatically fork for new requests and you won't have to worry about locking your app at all. Nevertheless I think that using Tornado for fully sync apps (even when hosting behind WSGI) is a bit pointless. The entire point of Tornado is to be asynchronous. That's why I tend to use it only when I know the app's gonna be fully async and alongside a "regular" app written in, say, Flask.