3 ms·
This is one of the (many) reasons why I've started using Phoenix LiveView for all the projects, when I can, that need either partial or full client-side functio
by mercer 7y ago
This is one of the (many) reasons why I've started using Phoenix LiveView for all the projects, when I can, that need either partial or full client-side functionality.
By simply keeping all the state, logic, and rendering on the server, all sorts of issues are avoided and various optimizations are possible, and I get full server-side rendering for free!
The client-side, meanwhile, via websockets, only sends events to the server and diffs whatever chunks of markup are sent back. Most of this is via server-side provided attributes (phx-click, phx-change, etc.), but for the slightly more 'exotic' stuff I can add my own events.
Obviously there are cases where this solution isn't practical, but this hasn't been the case for the vast majority of my projects.
- sojournerc 7y agoHow does this scale? Having lots of concurrent websockets seems like it could be challenging. Any caching layers?
- namelosw 7y agoThere are diff algorithms, but no caching layer. Also Phoenix is written in Elixir which could easily handle millions of stateful connections.
- mo1ok 7y agointeresting - reminds me of what meteor attempted with its data protocol.
- dirkg 7y agoPrecisely. DDP is also based on WebSockets and does essentially the same thing - server side computation, client side optimistic UI updates, caching etc. As with any stateful solution it has problems scaling. I'm not sure LiveView is the right answer.
- mercer 7y agoFrom what I understand the number of open websocket connections is not really much of an issue, because this is one of the things Phoenix/Elixir excel at. Memory might become an issue though, I suppose. Every user's state will be in-memory in 'their' LiveView process. On the other hand, there's much less state needed than with a client-side solution like React, because it can be very quickly fetched when needed.