The easiest way to add WebSockets to Django
jpadilla.com
The easiest way to add WebSockets to Django
1–10 of 17 posts
Re: The easiest way to add WebSockets to Django
#2Author here. Let me know if you have any questions or feedback.
Re: The easiest way to add WebSockets to Django
#3This question is more related to websockets. I have seen that they use different protocol and doesn't work behind proxies or firewalls most of the time. How do you handle this?
Re: The easiest way to add WebSockets to Django
#4Author here. Let me know if you have any questions or feedback.
Just this last week I started working on a new project with django-socketio, and I'm pretty happy with it so far. Why is django-websocket-request better?
Re: The easiest way to add WebSockets to Django
#5Author here. Let me know if you have any questions or feedback.
Just this last week I started working on a new project with django-socketio, and I'm pretty happy with it so far. Why is django-websocket-request better?
I did look into django-socketio when doing research, but never actually used it. django-websocket-request is way more simple, because it does way less and doesn't cover as much as django-socketio. For example, django-socketio is bound to only using socket.io, but it also includes a whole channel subscription and broadcast system so you can send messages from the server to specific channels. django-websocket-request only enables you to add a WebSocket layer over your already existing REST API / Views. I'll eventually have to look into doing things that django-socketio does.
Re: The easiest way to add WebSockets to Django
#6No, it's really not that easy, sorry.
Looking at the code, you're not actually doing anything with websockets here. There's no handshake parsing, there's no open socket object to pass data back and forth on, there's nothing actually websockety about this.
Instead, you seem to have a simple ajax endpoint.
Or am I missing something?
[EDIT] Clarifying why I said it's not that easy, since that seems snarky as I read it again. To properly do websockets in Django, you have to write your own runserver, which allows processes up the stack to capture the raw socket, perform the websocket handshake methods, and do proper parsing of the incoming data to break the messages on the sentinel values.
I recently tried to do this, and the one package that did this wouldn't work with Django 1.6, and we would have to give up our flup runfcgi, which I wasn't ready to do.
Re: The easiest way to add WebSockets to Django
#7No, it's really not that easy, sorry. Looking at the code, you're not actually doing anything with websockets here. There's no handshake parsing, there's no open socket object to pass data back and forth on, there's nothing actually websockety about this. Instead, you seem to have a simple ajax endpoint. Or am I missing something? [EDIT] Clarifying why I said it's not that easy, since that seems snarky as I read it a…
I only looked at it for a second or so, but it looks like it's a simple json proxy. You put a webserver with persistent connections on one end (Tornado in the example code) and a regular django environment side by side. The web socket requests are translated in to GET/PUT/POST requests, are pushed to django, django responds and the response is pushed to the client.
So from django's point of view there are stateless JSON requests and responses, so django's happy. The python proxy code is a lightweight wrapper that doesn't have to understand any business logic, so that's pretty straightforward as well.
Re: The easiest way to add WebSockets to Django
#8No, it's really not that easy, sorry. Looking at the code, you're not actually doing anything with websockets here. There's no handshake parsing, there's no open socket object to pass data back and forth on, there's nothing actually websockety about this. Instead, you seem to have a simple ajax endpoint. Or am I missing something? [EDIT] Clarifying why I said it's not that easy, since that seems snarky as I read it a…
I only looked at it for a second or so, but it looks like it's a simple json proxy. You put a webserver with persistent connections on one end (Tornado in the example code) and a regular django environment side by side. The web socket requests are translated in to GET/PUT/POST requests, are pushed to django, django responds and the response is pushed to the client. So from django's point of view there are stateless J…
I see where I was confused; I looked at the actual code itself, not the example where tornado was living and being used.
What are the advantages of this over normal AJAX requests, given that it's all using the single request, single response mode of operation (and you can compress/cache AJAX requests/responses, which websockets doesn't support yet).
Re: The easiest way to add WebSockets to Django
#9This question is more related to websockets. I have seen that they use different protocol and doesn't work behind proxies or firewalls most of the time. How do you handle this?
Using websockets relies on a proxy that doesn't pass just the headers/body, but instead sends all packets in both directions. Nginx proxies do this, Apache requires a special proxy module.
Firewalls don't typically care, since it's effectively a long lived HTTP request, unless it digs into all of the packets and filters there.
Re: The easiest way to add WebSockets to Django
#10Author here. Let me know if you have any questions or feedback.
Does SockJSRouter do any magic to ensure that wrapped handlers won't block the Tornado event loop?