0👍
Let me start with your last question:
Or may be have good way to implement async socket.io in Django to avoid having to route requests?
Django is essentially a library for processing of HTTP requests into appropriate HTTP responses. It does not provide an execution context like uWSGI, Apache mod_wsgi, Tornado, Flask, gunicorn etc. So you can not really use django to serve web sockets; there will always be an execution context around django.
When you deploy a django site to Heroku, it will normally use gunicorn as an execution environment. Performance wise this is not so cool: performance of python servers. Because the poor performance of gunicorn has to do with blocking I/O, some people install nginx as a non-blocking layer in front of gunicorn. This has led to the nginx buildpack.
I don’t think this fits your needs. Nginx is an awesome web server, but does not contain a python execution environment. So you end up introducing a third server into your stack:
- nginx for HTTP
- gunicorn for django
- server #3 for the websockets
My best suggestion is to leave gunicorn and nginx and to bring everything together in Tornado: web server, WSGI execution context for django, async context for websockets.
This link shows how to run Tornado on Heroku. And the next link shows how to run django in Tornado.