3 ms·

For building clustered backend services, messaging is great. And Django Channels looks awesome. However, in the context of the web (the client/server boundary)

For building clustered backend services, messaging is great. And Django Channels looks awesome. However, in the context of the web (the client/server boundary), I think we need to be careful about how messaging is used. The web is made up of resources with URLs. HTTP is typically used for data transfer, and for good reason. I sometimes see webapps communicating entirely over WebSockets. I don't mean just the realtime push part, I mean everything, request/response traffic and all. I understand that HTTP is suboptimal in certain contexts, but let's not throw the baby out with the bathwater.

bliti 11y ago
yea, of course. It's a new option to build good systems not a tool to build shitty ones
zeemonkee3 11y ago
Same as with Single Page Apps - websockets have their place but shouldn't be abused. I can imagine a large Django app that uses mostly plain request/response but needs, say, a small customer service bot or occasional real time notifications. This new feature is perfect for that.
Yaggo 11y ago
> However, in the context of the web (the client/server boundary), I think we need to be careful about how messaging is used. The web is made up of resources with URLs. HTTP is typically used for data transfer, and for good reason. "Careful" == do not break urls, use pushState and make sure equivalent document is returned for GET.
- jkarneges 11y ago
  Sounds good to me. :)
karmajunkie 11y ago
Could you elaborate on specific issues you see with the use of web sockets over http/s for request response? I see this argument from time to time and I have a hard time with it when you take resource hogging out of the equation, which isn't much of a factor in many situations.
- jkarneges 11y ago
  The issues with WebSockets are more political than technical. WebSockets are the superior technical solution with wide availability. However, at present, HTTP has better tooling (e.g. debug tools, devops tools) and developers are more familiar with it. HTTP is the de-facto standard for APIs as well. If you're the sole developer of a Single Page App with no API, then this difference may not be important. But if you're working with a team, or across teams, then building a WebSocket-only app will bring pain. As another commenter mentioned, as long as equivalent actions are possible via HTTP then some of the issues are alleviated.
  - karmajunkie 11y ago
    upvoted for being a nuanced response, thanks!

bliti 11y ago

yea, of course. It's a new option to build good systems not a tool to build shitty ones

zeemonkee3 11y ago

Same as with Single Page Apps - websockets have their place but shouldn't be abused. I can imagine a large Django app that uses mostly plain request/response but needs, say, a small customer service bot or occasional real time notifications. This new feature is perfect for that.

Yaggo 11y ago

> However, in the context of the web (the client/server boundary), I think we need to be careful about how messaging is used. The web is made up of resources with URLs. HTTP is typically used for data transfer, and for good reason. "Careful" == do not break urls, use pushState and make sure equivalent document is returned for GET.

jkarneges 11y ago
Sounds good to me. :)

karmajunkie 11y ago

Could you elaborate on specific issues you see with the use of web sockets over http/s for request response? I see this argument from time to time and I have a hard time with it when you take resource hogging out of the equation, which isn't much of a factor in many situations.

jkarneges 11y ago
The issues with WebSockets are more political than technical. WebSockets are the superior technical solution with wide availability. However, at present, HTTP has better tooling (e.g. debug tools, devops tools) and developers are more familiar with it. HTTP is the de-facto standard for APIs as well. If you're the sole developer of a Single Page App with no API, then this difference may not be important. But if you're working with a team, or across teams, then building a WebSocket-only app will bring pain. As another commenter mentioned, as long as equivalent actions are possible via HTTP then some of the issues are alleviated.
- karmajunkie 11y ago
  upvoted for being a nuanced response, thanks!