Where to (not) use Phoenix LiveView
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:
Phoenix LiveView is an exciting new library which enables rich, real-time user experiences with server-rendered HTML. LiveView powered applications are stateful on the server with bidrectional communication via WebSockets, offering a vastly simplified programming model compared to JavaScript alternatives. While modern JavaScript tooling enables sophisticated client applications, it often comes at an extreme cost in complexity and maintainability. There’s a common class of applications where rich experiences are needed, but full single-page applications are otherwise overkill to achieve the bits of required rich interaction. This applies to broad use-cases, including simple real-time updates, client-side style validations with immediate feedback, autocomplete inputs; and it can go as far as real-time gaming experiences. LiveView fills this gap and challenges what’s possible with server-rendered applications.
You can read the whole article by Chris McCord on this blog post:
Positive use cases
Index pages
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.
Basic Forms
You can see a lot of demos with form validations and LiveView. It’s a great tool when you don’t want to validate JavaScript. But don’t forget it can be tricky with complicated forms. I see some issues with validation where the developer forgot to validate some value. Or even forgot to store value in validation response so the form was rendered with an empty value.
Interactive Forms
How I wrote before LiveView can be great for forms but it can create issues with complicated long forms. Mostly small issues. We had a small side project where we created a portal for some kind of regular business competition. So some administrators create competitions and business companies can fill an application and win something. At the end portal with a lot of dynamic forms, even people can create their own forms. We use LiveView everywhere and it allows us to do real-time time collaboration for filling application forms. So multiple people from a company can fill the same long form without rewriting already answered or drafted answers for questions in forms. We were thinking about using some Javascript framework before we started. We decided to use LiveView only because we didn’t have the budget to hire a frontend developer, we didn’t have time(6 weeks from start to real production release with an already tested platform with testing real user groups) to convert available Elixir developers to some JavaScript framework, we already had LiveView experience. We thought it will be very hard but in the end, it was not painful and development was very fast. Another example is our onboarding form where we use multiple tools to load data into form based on user inputs or user interaction with face recognition tools. LiveView gave us nice interaction between users, our servers, and 3rd party APIs with very easy implementation even for junior developers.
Wizards
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
Huge pages
For example I was working on a project where people edit tables and it was implemented with LiveView. So you edit one entry and it made some calculations and show some information and new numbers in some rows. It worked great until the users want to use the table with 1000 rows. I made some optimizations and it worked well. But when 3000 rows came up it was game over. Too many bindings for all rows, pure HTML file has about 3 MB, it was crazy. Yes, there is some space for optimization but the JavaScript Client-Side application would be a much better choice.
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.
Offline required
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).
Mobile views
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.
Client Applications
First of all, you have to ask yourself if you need a Client Application. Mostly the reason for choosing this approach is too many client interactions. You need modals, menus, loading or binding data and you need it fast. You don’t want to wait for loading the whole page, etc. When you need a Client Application, don’t use LiveView. LiveView is a good choice for it too. But I can imagine use cases where you can have too much Client-Side JavaScript logic where frontend frameworks can handle things better than LiveView. But still, you can use LiveView even in these use cases. For example, we have Merchant Portal where users can interact with their accounts, list transactions, invoices, make accounts, etc. Maybe Frontend JS Framework would give us more power but we don’t have frontend developers, we don’t want to work with Javascript frameworks, we want to use Elixir. It’s not a personal choice too. Also economic choice. When you use the same technology for backend and frontend and all developers which you have can work with it you can have better delivery and you don’t have to pay for contractors or external companies to fix simple form(for example). And you don’t need a frontend developer which can not fix backend stuff (no offense guys). We don’t have all pages in LiveView but we added a few where we need this power. So React, Angular, TotalJS, or another Frontend JS framework can be a great choice too.
PWA
PWA is very popular these days. It’s similar to what I wrote before. There is too much interaction and JavaScript to handle.
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.
Disclaimer
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.
Update
There is interesting forum thread as a follow-up from this article:
