Hacker News Reader

Comment by josevalim | Hacker News Reader

Each LiveView requires a persistent WebSocket connection to the server. This means it does have a different scaling profile than the usual request/response lifecycle, but the Erlang VM is greatly capable of holding millions of connections at the same time and therefore is a perfect fit for the LiveView model.

In fact, LiveView is built on top of the same Phoenix Channels we used to achieve 1 million connections on a single server. So I would say that LiveView fully leverages the Erlang VM strengths. :)

View on HN

Thank you Jose for all you do, create and how you help developers around the world.

What situations would face possible issues with the persistent-socket-per-view approach? A sprawling app with hundreds of distinct views that over-use LiveView? Would there also be multiple persistent sockets for each particular page?

I can't imagine the type of site that would need that sort of structure. Typically you'd have your highly-interactive primary subset of your app, about <10-25% of the routes/views which gets 75-90% of your traffic. While the other 75%+ of routes are just simple static-y/REST CRUD/server-rendered pages.

IIRC (don’t claim to be an expert) the main issue is gracefully handling the case where the server end goes away unexpectedly - network issues, reboots, that kind of thing.

Does that include deploys?

yes active clients reconnect automatically, if you are doing rolling traditional deploys its great. It is running on beam so you can do live in place deploys too (although it is much more work).

there are not a ton -- the pain points mostly boil down to:

Don't use it for extremely latency sensitive UI's (there is around trip and most of the time for most uis this is not an issue even using a server across the world).

Don't use it for animation heavy UIs (you can do animations with it but think things like game UI).

It does not work offline (in most cases it s the same point with standard web and offline).

All of that said, the answer to your second "question" is: There is a process (this is an erlang process and VERY light -- much lighter than a thread its not unusual to have millions of them running at a time in beam) per active page. So one per use per tab or session.

Also yeah, there is no lock in -- you can have 99% of your pages use static rendering (dead pages) and just use liveview for the ones that would benefit. The choice does not come with sharp edges.

In a situation where you hit the scaling limitations of the BEAM, you’re going to have the budget to address it.

We use LiveView extensively and one meaningful issue we have is users with intermittent connections on mobile.

On a "normal" req/resp page, their intermittent connection would manifest as a blank then slowly loading page: things that the user understands as being the result (in a way) of "bad internet".

With LiveView, the site simply becomes unresponsive. Nothing changes, and the user interprets this as the site being "broken" (which in a way it is)

Some of the 1.7 stuff has an alert banner that pops up when the connection is broken. I think that could really help.

However I haven't put that in our app as I have seen other issues of flakey connection reconnect issues, and I would hate to make any of those more visible with a flashing notice.

- https://github.com/phoenixframework/phoenix_live_view/issues...

- https://github.com/phoenixframework/phoenix/issues/5102

- https://github.com/phoenixframework/phoenix/pull/5024

> I would hate to make any of those more visible with a flashing notice.

idk I haven't used LiveView in production but an interface that offers a well designed fallback "refresh" button helps for unpredictable edge cases, more so than the negatives of added complexity, which yes implies failure but is also certainly better than failing to optimize for reality.

I ran into a similar hypothetical issues, that was really in practice an edge case, because we cached views for typical users. But I still provided a way to force reset of both server caches AND Localstorage caches because otherwise such an option was limited to advanced users/devs who either know backend or frontend.

This is win-win ultimately because the user feels taken care of even in niche failure edge cases and QA/devs doing testing aren't forced to use exceptional means to reset state.

Reply on news.ycombinator.com