I’m considering LiveView for a SaaS with a pretty big scope. I love the concept of LiveView and I see practically nothing but praise for it around here which is awesome, but would love to hear some contrarian views (if any), footguns, rough edges, or anything else worth keeping in mind for a large production app.
For example, one thing that gives me pause is the LiveComponent story as far as messaging goes - it seems like there could be some complexity there as far as getting events/data/etc. to components vs. the ease of which you can do it from LiveViews proper. I’m also going to need some pretty complex multi-step nested forms in the app, and I’m wondering how easy or difficult that will end up being to implement.
A tutorial on multi-step forms can be found here. You can probably find further resources on nested forms elsewhere to combine the teachings.
I have no experience with SaaS. However, I do like LiveView for developing large Web applications. An aspect that I would like to raise your attention on is the generated traffic. If you are not careful in the design, you may end up with a heavy implementation, traffic-wise. Of course, there are solution to improve this issue (compartmentalization, patches, JS interaction, etc.).
Another aspect might be the handling of memory at the server. However, this is an issue that I currently ignore. Certainly, it is addressable with the provided tools, e.g. streams.
Finally, I would like to mention that I have no experience with publicly deployed applications.
I guess more experienced users can provide you with further insights.
There’s an unavoidable overhead involved in LiveView, but whether it’s worth it depends on the specific needs of the content - at an extreme, it certainly wouldn’t make sense to serve static content that way but the more interactivity / real-time behavior etc you need the more sense it makes.
A related challenge that some early adopters encountered was too many round-trips to the server for things like “hide / show” buttons that manipulate the DOM. Subsequent improvements like the Phoenix.JS system help with this a lot by doing client-only things only on the client.
Usually it is easier and cheaper to just allocate a few more gigabytes of memory than to go deep into optimizing server memory usage. Of course the exception is when you are leaking memory.
