Looking for “gut reactions” here, not any real analysis from anyone wishing to reply.
With the availability of packages like SSH2 in JavaScript, I’m wondering if there are any advantages / disadvantages of using this as compared to Websockets / Channels?
Use-case: Persistent connection required between browser and server.
- Server needs to asynchronously push data.
- Browser may occasionally need to push data at irregular intervals.
Concept: Instead of wedging this data traffic along the http web socket connection, the JS client opens a second connection to a dedicated socket listener.
Assumptions:
- Absolute max of 50 clients. (Having more than 50 client browsers on this is a problem that I desperately would love to have. My actual expectation is that there might be as many as 8 concurrent clients at any point in time.)
- The server-side socket listener would be a Python socket server, possibly built on something like AsyncSSH
Advantages:?
- Ability to send data in other than JSON format(?)
- More stable connection?
- Are there others?
Disadvantages?
- Yet another component to add to the stack.
- More JS work required.
- Others?
Gut reaction: stick with weebsockets. They’re built-in to browsers and a well supported technology, and Channels is an official Django project to have them work in your project. And if you don’t want to run the infrastructure for them, you can always use something like pusher.
1 Like
Thanks for the reply. I’m sure in the end you’re right.
It’s not the server-side that I’m uncomfortable with when using websockets & Channels, it’s the client-side - particularly with routing frames to functions. (Acknowledging that the problem is mine - I don’t do it often enough to ever become comfortable.)
As I’m becoming more pain-adverse, particularly as far as JS is concerned, I’m trying to find ways to reduce the “friction” I encounter with socket applications, even at the expense of some comfort on the server-side. It seems to me - and it may just be a lack of exposure in some areas - that there are more JS libraries available to handle transport when channels isn’t in the picture. (Socket.io as an example, but not the direction I really want to go either.)
(I know, no one ever said it was going to be easy… The real answer may just turn out to be biting the bullet and working through my JS difficulties.)
If by this you mean the trend to use things like socket.io which abstract away websockets, then yes there are more. Part of the reason for their popularity was the adoption of websockets-supporting browsers, but but we seem to be over that hump now.
If I were setting up something using websockets right now, I’d also consider passing HTML over the wire using e.g. htmx experimental websockets support.
1 Like
Essentially, yes.
Actually, you ended up serving as my “Rubber Duck” this morning. You got me thinking about some architectural issues. Then, while I was in the process of writing one of my long-winded replies, something clicked. You are right, websockets are much more mature than they were 3 - 4 years ago, and for my rather well-contained application, I don’t really need to rely upon fallbacks to long- or short- polling solutions.
After some more thought and some research, I find myself agreeing with you. Thanks!
Very interesting, thank you for the link! (I always like hearing about new stuff, even if it’s not something I see an immediate need for.)