Advantages of Stateful Websockets?

Apart from some dabbling a while ago, I am new to web sockets.

A naive question: WebSockets / Phoenix channels /can/ be stateful - but is there any particular advantage to that?

Must they be stateful?

I suppose the option is there, mainly for performance…

Not just performance at all, but it means a lot of things:

  • No needing to re-setup and tear down a TCP connection on every access.
  • Server can push data to the client without the client needing to poll, thus no needless waiting between polling intervals.
  • Significantly smaller packets since only the ‘real’ data is sent (plus a couple of bytes of overhead, compared to a couple of kilobytes for HTTP).

Among a lot more. :slight_smile:

In essence, ‘why would you use TCP over a (imagine a very bloated form of) UDP’, similar area. :slight_smile:

3 Likes

Yes true.

I suppose, I was thinking more along the lines of -

Web sockets do statefulness, but should you necessarily store more application state in the connection?

Just because you can, doesn’t mean you necessarily should(?)

I see a lot of examples, which do this.

Obviously I understand there will be cases when this is necessary, but also I can imagine too much statefulness can lead to problems also…

In general…yes. Without state in the application/websocket you are forced to push data out to other systems to do something with it. Whether that is a database of some type or an API/relay it creates additional overhead for every bit of data sent back and forth. It also means that in order to grow an application like that, those central datastore or relays have to be grown as well.

One of the trends you see in JS frontends is a push to hold more and more state in the browser largely because doing the same thing on the server just isn’t possible/trustworthy in “most” languages without involving another datastore.

2 Likes

One of the trends you see in JS frontends is a push to hold more and more state in the browser

And also! you avoid distributing your state, and all the very hard problems that go with that…

You kinda do though.

The farther out you get from a single data store, the more you distribute state. So, just as an example:

database -> web server -> browser window
         -> web server -> browser window
                       -> browser window
                       -> browser window

It’s moved around all over the place ever since. Cookie’s weren’t secure, sessions were often file based on each web server so as soon as you grew beyond one you’d need to centralize them elsewhere. Usually that means the database or an encrypted cookie. In either case a central state point is chosen and the web server reloads it on every request/page load either from the cookie or from the db.

With JS variables the state won’t be shared across multiple windows, so you need to utilize an in browser store or relay at the server level. Frameworks like Meteor are specifically designed to handle that use case knowing that multiple windows may be open and need to stay in sync.

Generally, these all offload to something like Redis Pub/Sub to handle relaying quickly because the language won’t already do it.

When you do it with a Phoenix channel, you get the state for a user in once place between multiple websockets and across multiple servers, so that a message from one place gets a response to all of them appropriately.

Before Redis had the ability to cluster, you still had the issue of outgrowing your instance and figuring out who was on what just to use that.

In order to solve the problem, you basically have no choice but to cluster - it’s just a matter of the level of your stack where you want to do it.

2 Likes

Absinthe with subscriptions over phoenix channels. ^.^

EDIT: Or even Drab!

3 Likes