5 ms·

This seams really optimistic and kind of glosses over the subject of scaling out websocket connections apart from this. Anecdotally, the typical single Rails s

This seams really optimistic and kind of glosses over the subject of scaling out websocket connections apart from this. Anecdotally, the typical single Rails server process seems to be perfectly happy supporting nearly 4,000 active connections. And you can easily swap in the excellent AnyCable to bump that up to around 10,000+ connections per node by not relying on the built-in Ruby WebSocket server. That's not a lot of connections on it's own. If you are implementing a chat service you'll still need some form of pub/sub (or something) to glue all of that together when users connect to disparate nodes. Also How about client-side validations? Easy. On every input change, round up the form values and send ’em down the WebSocket. That's just server side validation. As a disclaimer, I haven't used any of the HTML over WS frameworks the author discusses, but I've spent a fair amount of time dealing with scaling socket connections. It definitely makes the question of scaling horizontally more challenging. I feel like this article really glosses over that aspect.

mplewis 6y ago
Sure, it's server-side validation – which is great, and works well. And now it works without a full page submit and reload. That's a huge benefit.
- the-dude 6y ago
  Which you can do already for over a decade with AJAX.
  - sago 6y ago
    Yup. And DHTML over a Java applet before XMLHttpRequest. 1999 at least, iirc.
- brod 6y ago
  Ever since xmlhttprequest (and even before that with images) we've been able to do server-side validation without a full page reload. This "solution" completely ignores the purpose of client-side validation which is to a) reduce load on server-side resources, b) validate faster without the network latency and c) validate more securely and privately by not sending the content to the server.
skullum 6y ago
Phoenix live view (anything on BEAM really) maps each ws to a BEAM process so scaling to 10000+ connections is both cheap and built-in
- nickjj 6y ago
  But LV is still in its infancy and there are very real implications of using websockets that are unrelated to open connections. Just the other day someone posted on the Elixir forums about live_redirect causing 2 network round trip connections[0]. Basically there was double the latency to transition between pages due to this "bug". I air quoted "bug" because it's working as intended, it's just not optimal. The creator of Elixir mentioned it was doable to fix the issue but when an issue was open on GitHub[1] it was shot down with a "this is a known tradeoff, you'll need the 2nd route trip for the websocket". I'm not sure what the state of the issue is but it currently stands as closed. I've pinged 80ms to servers where LV was being used and the delay was extremely noticeable (before I even knew about this double network round trip issue). It feels much worse than a Turbo Drive / Turbolinks driven site (which uses HTTP instead of websockets like LV does). In some cases LV feels slower than a regular site even with the DOM having to re-parse all of your assets. The only time LV feels like a net win to me is when you're on a local connection with 1ms of latency. I wanted to use LV a lot, but backed out because I kept running into bugs and missing features. Plus after feeling a LV site on a non-local connection I can't say that I would want to impose that experience on users. Especially folks who happen to connect from let's say Europe to the US, or even further away. The web is a global place. [0]: https://elixirforum.com/t/shortcomings-in-liveview-are-there-any-i-should-look-out-for/31831/47 https://elixirforum.com/t/shortcomings-in-liveview-are-there... [1]: https://github.com/phoenixframework/phoenix_live_view/issues/1334 https://github.com/phoenixframework/phoenix_live_view/issues...
  - benzible 6y ago
    When did you last use it? Javascript hook support wasn't there early on. The state of the art is the "PETAL StacK" [1] which uses client-side JS for interactions that don't require a roundtrip [1] https://thinkingelixir.com/petal-stack-in-elixir/ https://thinkingelixir.com/petal-stack-in-elixir/
ksec 6y ago
It is also important to note the latency in these connection. Generally speaking 4000 Active connection you are looking at 150ms+ for 98th percentile already. Which is bad to be frankly honest. ( Results were from 2016, so may be things has improved )
burlesona 6y ago
FWIW the article should have led with Phoenix LiveView, which really pioneered this approach, and is much better suited via its concurrency model for large scale streaming apps (like chat apps). Where Rails with “live view” tooling would work really well is building CRUD heavy sass apps that don’t need a persistent connection, just want really fast page refreshes and/or partial updates. The work the basecamp team did on Hey seems to be a good illustration of that.

mplewis 6y ago

Sure, it's server-side validation – which is great, and works well. And now it works without a full page submit and reload. That's a huge benefit.

the-dude 6y ago
Which you can do already for over a decade with AJAX.
- sago 6y ago
  Yup. And DHTML over a Java applet before XMLHttpRequest. 1999 at least, iirc.
brod 6y ago
Ever since xmlhttprequest (and even before that with images) we've been able to do server-side validation without a full page reload. This "solution" completely ignores the purpose of client-side validation which is to a) reduce load on server-side resources, b) validate faster without the network latency and c) validate more securely and privately by not sending the content to the server.

skullum 6y ago

Phoenix live view (anything on BEAM really) maps each ws to a BEAM process so scaling to 10000+ connections is both cheap and built-in

nickjj 6y ago
But LV is still in its infancy and there are very real implications of using websockets that are unrelated to open connections. Just the other day someone posted on the Elixir forums about live_redirect causing 2 network round trip connections[0]. Basically there was double the latency to transition between pages due to this "bug". I air quoted "bug" because it's working as intended, it's just not optimal. The creator of Elixir mentioned it was doable to fix the issue but when an issue was open on GitHub[1] it was shot down with a "this is a known tradeoff, you'll need the 2nd route trip for the websocket". I'm not sure what the state of the issue is but it currently stands as closed. I've pinged 80ms to servers where LV was being used and the delay was extremely noticeable (before I even knew about this double network round trip issue). It feels much worse than a Turbo Drive / Turbolinks driven site (which uses HTTP instead of websockets like LV does). In some cases LV feels slower than a regular site even with the DOM having to re-parse all of your assets. The only time LV feels like a net win to me is when you're on a local connection with 1ms of latency. I wanted to use LV a lot, but backed out because I kept running into bugs and missing features. Plus after feeling a LV site on a non-local connection I can't say that I would want to impose that experience on users. Especially folks who happen to connect from let's say Europe to the US, or even further away. The web is a global place. [0]: https://elixirforum.com/t/shortcomings-in-liveview-are-there-any-i-should-look-out-for/31831/47 https://elixirforum.com/t/shortcomings-in-liveview-are-there... [1]: https://github.com/phoenixframework/phoenix_live_view/issues/1334 https://github.com/phoenixframework/phoenix_live_view/issues...
- benzible 6y ago
  When did you last use it? Javascript hook support wasn't there early on. The state of the art is the "PETAL StacK" [1] which uses client-side JS for interactions that don't require a roundtrip [1] https://thinkingelixir.com/petal-stack-in-elixir/ https://thinkingelixir.com/petal-stack-in-elixir/

ksec 6y ago

It is also important to note the latency in these connection. Generally speaking 4000 Active connection you are looking at 150ms+ for 98th percentile already. Which is bad to be frankly honest. ( Results were from 2016, so may be things has improved )

burlesona 6y ago

FWIW the article should have led with Phoenix LiveView, which really pioneered this approach, and is much better suited via its concurrency model for large scale streaming apps (like chat apps). Where Rails with “live view” tooling would work really well is building CRUD heavy sass apps that don’t need a persistent connection, just want really fast page refreshes and/or partial updates. The work the basecamp team did on Hey seems to be a good illustration of that.