Phoenix LiveView: The IoT Front-End Solution

For instance, when our founder, Ben Wald, recently reviewed the Molekule Air Mini+, he was impressed by the quality of the device itself, but the poorly programmed mobile application (pictured below) left much to be desired and left him frustrated. As far as we’re concerned, this simply isn’t acceptable, especially after a customer shells out $500 for a smart device.

That’s one reason we’re keeping a close eye on the Phoenix LiveView framework, a new paradigm for web development. Written in Elixir and maintained as an open source project on GitHub, LiveView enables developers to easily build web front-ends with streaming, real-time data without having to worry about client-side complexities. In LiveView, the server is responsible for everything.

Since the server controls what’s rendered, we can program server-side events to trigger updates on our web pages. When we combine this with the built-in concurrency of Elixir processes and the robust publish/subscribe (pub/sub) messaging of the general Phoenix Framework, we can tie this all together to generate robust, real-time dashboards. 

Phoenix LiveView may not hold a monopoly on this pattern, but it does provide a simple programming model to enable it.

How Phoenix LiveView Works

When a client requests information from a server, LiveView begins by rendering the initial page and sending it to the user’s web browser. The LiveView client then opens an active connection back to the server, which creates a two-way connection between them. The client then holds all the static information in a browser cache, while the server keeps track of any changes and sends them to the client as diff messages. 

Essentially, this means that the server updates the front-end as data changes, and it informs the client of those changes-and only those changes. As a result, LiveView only sends the minimum amount of data that’s needed to update the client with the new information. That way, instead of resending the entire page, we only have to send a fraction of it.

Plus, since we have a two-way connection, the client can also send information back to the server. For instance, on an IoT dashboard, a client can tell the server to silence notifications from specific devices. Once the server receives this information, it knows to ignore any messages coming from the specified devices.

Benefits of Phoenix LiveView for IoT

IoT ecosystems contain a lot of data. This includes sensor data from the devices themselves, user data coming from the front-end, and back-end data that lives in the cloud. So, for example, a smart thermometer will take readings and publish the data to an MQTT broker like AWS IoT Core over a topic such as smart_fishtank1/temp.

Now let’s say you own that aquarium, and you open the mobile app to check the water temperature. With LiveView, we can tell that app to subscribe to that same smart_fishtank1/temp topic, so whenever the broker receives a message from the device, it will automatically forward it along to the front-end. This provides a smooth user experience that requires minimal effort.

The benefits of LiveView come into even clearer focus when we start to consider constrained networks like LTE. If bandwidth is a concern, LiveView is an optimal solution because it makes our data transfers as small as possible. A prime example is agriculture IoT. Our devices can collect data about growing conditions that can inform smarter decision-making. 

However, for farmers to be able to use these insights, they need to be able to access that data while they’re out in the field—and we certainly can’t expect a high throughput network. Even if the network connection occasionally drops, it’s no big deal; Phoenix LiveView will automatically reconnect when the network connection is reestablished.

Instead of wasting bandwidth on rendering the same page over and over again, LiveView keeps all the static elements in place and just sends the changes: the data itself. What would take KBs to transfer with traditional methods will now only take a few bytes.

The Cons of Phoenix LiveView

Every superhero has their kryptonite, and LiveView is no exception. In fact, the main downside is actually tied to LiveView’s greatest strength; because the server is responsible for rendering everything, the client needs to maintain an active internet connection. LiveView has mechanisms in place to seamlessly restore the connection if it goes out, but a poor cellular signal or a weak internet connection can lead to a lackluster user experience. 

Another drawback is that LiveView requires a different mindset for a developer to work effectively in its paradigm. LiveView takes a functional programming approach to front-end development, and this forces the developer to think about the way they build front-ends at a foundational level. Everything has to be done entirely within the server’s rendering system.

As a result, it can be more difficult to solve problems that we could otherwise take care of with just a small amount of JavaScript. This means that developers need to get creative in their problem-solving approach—or else find an escape hatch from LiveView, such as alpine.js.

Phoenix LiveView: A Powerful Paradigm 

Phoenix LiveView is a powerful tool that helps us to build rich, real-time user experiences. While it’s not without its drawbacks, the power of the paradigm should not be underestimated. LiveView provides a fast, low-bandwidth experience, is capable of both vertical and horizontal scaling, and doesn’t rely on client-side dependencies like JavaScript.

Especially for IoT products that already use Elixir for tools like Nerves and NervesHub, LiveView is an even more attractive option because we can leverage talent and streamline integration. That’s exactly what we do at Very.

Are you an Elixir developer? Does creative problem solving with cutting-edge technologies get you as excited as it does us? Well, we have good news for you. We’re hiring.