This is a very interesting topic and a question that all responsible engineers should ask themselves when deciding whether to go with LV. For sure I did ask it to myself many times. It’s even more important considering that LV is a highly promoted feature in Phoenix 1.5+, backed by a homepage redesign.
If the answer is “just return static HTML” then by itself it sounds like LV won’t scale well for these cases which is also not something we should state lightly. For sure, I wouldn’t treat this question as silly one and I wouldn’t underestimate the paradigm shift for many “oldschool web dev” that come with websockets and LV statefulness.
For the “viral blog” case there may be many scenarios when LV would still be applicable & profitable even for displaying static blog entries. This includes:
- rendering entire website via LV e.g. to reduce HTTP connection times
- rendering typical blog entry interactions e.g. like button with live counter
- rendering website-wide interactions e.g. notification or search popover in navbar
From my perspective it would be great to know up front if LV scales well (and how well) out of the box, what options are there for optimizing it (like caching) and if there are cases where it obviously won’t work due to scalability limitations. I guess what we really need is a comprehensive benchmark similar to the one about reaching 2 milion connections with single Phoenix instance. I’m not an expert at doing such benchmarks (esp. concerning websockets) but even without one we could just calculate the minimal memory footprint of a single active connection without extra assigns and use that to calculate the best case scenario “users per GB of RAM”. From then on it’d be all about understanding the cost of each assign and keeping that under control with temporary assigns etc - esp. in LVs that contribute to high-traffic pages.
In the end, we may always approach to LV as to “MVP supercharger” - a solution that allows to create dynamic websites at unprecedented pace but that always ends up converted to client-side/SPA code when the scale grows. But perhaps it doesn’t have to? With regular Phoenix, there’s a great chance that (depending of a case of course) you’ll hit DB scalability issues 10 times before you outgrow the webserver (like discussed e.g. here Scaling LiveView for low latency in multiple regions), but is that still the case with LV?
