Recently I was watching the great conference Elixir Wizards |> Conference and someone asked a question about Phoenix LiveView. The question was about use cases and examples where to use Phoenix LiveView. I think there was no time for a proper answer so I decided to answer this question.
Our company (Payout — payment service provider) and our partner companies use it pretty often. We have a lot of experience with this “framework” and we use it almost in every project what we have in Elixir. I can count about 50 LiveView pages in our GitHub account and all of them are already in production right now. We implemented our first LiveView page on 14 May 2019 (merged into the master branch).
What is Phoenix LiveView?
You can find too many articles about Phoenix LiveView. Let’s take a description from the first introduction article from December 2018:
You can read the whole article by Chris McCord on this blog post:
Phoenix LiveView is an exciting new library which enables rich, real-time user experiences with server-rendered HTML.
Positive use cases
A lot of people would say index pages are so simple you don’t need a hammer as LiveView for it. That’s true but you can make index pages with it even faster and better. Interactions as filters, pagination, sorting, etc are very fast to implement with LiveView and it’s pretty fast from the user side too. You can even add logic to add a new entry or update an already showed entry without refreshing the whole page. This real-time implementation is really easy(literally a few lines of code) with Phoenix PubSub.
Wizards are just multiple forms merged into the logical flow from my point of view. So it’s very natural to use LiveView same as for interactive forms. See the example from our onboarding. It’s created from multiple steps where every step it’s just a form. There are multiple options for implementation. One LiveView module for all steps or multiple modules. It depends on you or the complexity of forms. It’s easy to implement functionality as interactive loading data, validation, storing draft of form, showing real-time information, etc.
Realtime data streams
A nice example of it is Phenix Live Dashboard. It’s a great choice for dashboards, indexes, or even simple pages as a counter. You just have to create a template with relevant data and LiveView will take care of it. It works pretty great when all data are not changed because LiveView on the server side already checked what is changed and what not and with the right structure only new data are sent to the user via Web Socket. This gives you nice speed and even internet traffic is not overload with big data streams. Refreshing data can be done with a regular async task which reloads data and sends only new. An even better implementation is with Phoenix PubSub. The module can subscribe to the specific topic and refresh or do specific action when a new message is received. For example reload some part of the dashboard or add/remove lines in the table, add a new notification, etc.
Negative use cases
Problematic internet connections
I worked on some projects where internet connection was a huge issue. For example mines, huge buildings without wifi, countrysides, countries with pure connections. LiveView uses WebSockets and its live connection so a good internet connection is required. I mean you don’t need a perfect super-speed connection. It has to be just stable to some point.
How I wrote before, you need an internet connection. When you lost connection, you lost control and it’s the end game for LiveView. This is the use case where Client-Side Application perfect solution(or Mobile/Desktop Application even better).
I’ve met some use cases where people had projects where 90% of users were on a mobile phone. The point is not in the size of devices but in how mobile app works. You have a mobile browser, you open a page, swipe to another app, another app, another app, some facebook distraction, etc., and your mobile browser is lost in memory. So the connection is lost too. When the user swipes it back you have to establish the connection again, mount the page again. It’s no problem with LiveView, it works pretty well. But mounting a page can be time expensive and I think it’s worth thinking about it.
Only static content
I saw people asking “Can we use LiveView in our case …?” and people described their use case which was mostly about showing some static information. It’s like let’s use a hammer to kill an ant. LiveView is (mostly) about bi-directional communication. When you don’t need to communicate with a visitor, you don’t need to have opened a connection, it’s too expensive comparing with showing simple HTML. There can be use cases where you don’t need a lot of communication from a visitor but you want to push new information/data to the page so visitors can see fresh or even real-time data. That’s the positive use case
When you know more positive or negative use cases for LiveView please let me know in the comment area or on my Twitter account @quatermain32 and I will update this list.
All pieces of information, ideas, or opinions in this article are mine. I’m pretty sure there are people outside of my bubble who have opposite opinions or experiences. Also when I say it good to use Phoenix LiveView, it doesn’t mean it will work for you and vice versa. There are too many factors that define the success of implementation.
There is interesting forum thread as a follow-up from this article: