3 ms·

I think this conflates a very specific paradigm for using WebSockets (state synchronization with a stateful "server") with WebSockets as a technology. At the e

by bri3d 5y ago

I think this conflates a very specific paradigm for using WebSockets (state synchronization with a stateful "server") with WebSockets as a technology. At the end of the day, WebSockets are just, well, sockets, with a goofy HTTP "upgrade" handshake and some framing on top of them. You could implement the exact same request/response model as in an HTTP based service over a WebSocket if you wanted to. Stateful services are a tradeoff whether you use a WebSocket or not. Reading through here, I think what you're trying to build is a synchronized stateful distributed system where state management becomes more transparent to the engineer, not only across backend services but also between the browser and the service side - this is well tread ground and a huge problem, but an interesting one to take on nonetheless. "WebSockets" are a red herring and just an implementation detail.

mathgladiator 5y ago
You're right. The key thing is the spectrum of freedom induced by the library/framework. For example, if use something like PHP then you live in a prison of the request lifecycle. Sometimes the prison is socially enforced by not having shared state between requests within a process. There is nothing special about websockets, but they do confer a freedom and responsibility.
deleted 5y ago
[deleted]
ljm 5y ago
The article advocates that the client pulls data via polling (as I understand it), ignoring over a decade of precedence for using websockets for pushing data to a client or broadcasting it to many clients. It's up to the clients to consume that data and react to it if they even want to. There's nothing particularly bad about pub/sub there. It also talks about a 'command pattern' at that point, which sounds like they're complaining about RPC really.
bborud 5y ago
It isn't uncommon for people to get confused about layering. In fact, it is particularly hard when you have a lot of people who have used something for a long time without actually understanding the design of it. I'm not a fan of how websockets are implemented in browsers. It's a bit too "magical" for my taste. But what people seem to be complaining about is a mismatch between how they think networking works and how it actually works. This really isn't any different from the kinds of problems I'd teach beginners to get around 25 years ago when dealing with ordinary TCP sockets. What has changed is that programmers generally tend to know a lot less about the underlying technology these days (because there is so much extra complexity to worry about).

by bri3d 5y ago

mathgladiator 5y ago

You're right. The key thing is the spectrum of freedom induced by the library/framework. For example, if use something like PHP then you live in a prison of the request lifecycle. Sometimes the prison is socially enforced by not having shared state between requests within a process. There is nothing special about websockets, but they do confer a freedom and responsibility.

deleted 5y ago

[deleted]

ljm 5y ago

The article advocates that the client pulls data via polling (as I understand it), ignoring over a decade of precedence for using websockets for pushing data to a client or broadcasting it to many clients. It's up to the clients to consume that data and react to it if they even want to. There's nothing particularly bad about pub/sub there. It also talks about a 'command pattern' at that point, which sounds like they're complaining about RPC really.

bborud 5y ago

It isn't uncommon for people to get confused about layering. In fact, it is particularly hard when you have a lot of people who have used something for a long time without actually understanding the design of it. I'm not a fan of how websockets are implemented in browsers. It's a bit too "magical" for my taste. But what people seem to be complaining about is a mismatch between how they think networking works and how it actually works. This really isn't any different from the kinds of problems I'd teach beginners to get around 25 years ago when dealing with ordinary TCP sockets. What has changed is that programmers generally tend to know a lot less about the underlying technology these days (because there is so much extra complexity to worry about).