4 ms·

Each LiveView requires a persistent WebSocket connection to the server. This means it does have a different scaling profile than the usual request/response life

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. :)

tiffanyh 4y ago
Thank you Jose for all you do, create and how you help developers around the world.
dmix 4y ago
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.
- brightball 4y ago
  In a situation where you hit the scaling limitations of the BEAM, you’re going to have the budget to address it.
- TylerE 4y ago
  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.
  - dmix 4y ago
    Does that include deploys?
    - wstuartcl 4y ago
      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).
- wstuartcl 4y ago
  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.
- el_nahual 4y ago
  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)
  - eclark 4y ago
    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/2276 https://github.com/phoenixframework/phoenix_live_view/issues... - https://github.com/phoenixframework/phoenix/issues/5102 https://github.com/phoenixframework/phoenix/issues/5102 - https://github.com/phoenixframework/phoenix/pull/5024 https://github.com/phoenixframework/phoenix/pull/5024
    - dmix 4y ago
      > 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.

tiffanyh 4y ago

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

dmix 4y ago

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.

brightball 4y ago
In a situation where you hit the scaling limitations of the BEAM, you’re going to have the budget to address it.
TylerE 4y ago
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.
- dmix 4y ago
  Does that include deploys?
  - wstuartcl 4y ago
    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).
wstuartcl 4y ago
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.
el_nahual 4y ago
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)
- eclark 4y ago
  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/2276 https://github.com/phoenixframework/phoenix_live_view/issues... - https://github.com/phoenixframework/phoenix/issues/5102 https://github.com/phoenixframework/phoenix/issues/5102 - https://github.com/phoenixframework/phoenix/pull/5024 https://github.com/phoenixframework/phoenix/pull/5024
  - dmix 4y ago
    > 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.