Phoenix LiveView: Working the 80/20 rule

We really like Elixir at GenUI. We initially used it (to great success) for an internal project, and have since used it to solve a few different and challenging customer problems. A common saying in the Elixir world is that it "makes hard problems easy", and we've found that to be true. This is in part due to the functional aspect of the language, as well as the quality and breadth of the OTP platform which provides some extremely powerful abstractions for grappling with questions of complexity, scalability, and concurrency. 

Elixir's web application framework is Phoenix, and like the rest of the ecosystem, it's mature and useful in ways that are impressive. Up until recently, like most web frameworks, it was focused on server-rendered projects and APIs.

That has changed with the introduction of LiveView. LiveView adds the ability to build responsive web applications without having to write a single line of front-end code. It does this by leveraging some of the unique features of the Elixir/Erlang ecosystem and combining it with some very clever code.

An initial HTTP request for a page will be rendered and served, along with a small chunk of Javascript that opens a WebSocket connection to a stateful process on the server. This process receives events from the browser (or other processes on the server) and sends back highly optimized diffs that the client-side code uses to patch the DOM. None of this requires expensive HTTP round-trips, which keeps latency low. The Elixir BEAM has no trouble maintaining hundreds of thousands of internal processes, so the model of "one process per connection" is both reasonable and performant.

If you want to know how LiveView works, there are some excellent introductions available from members of the community that we're not going to rehash here. What we do want to talk about is why LiveView is a game-changer.

Speed

...and I don't mean the speed that Phoenix is famous for in terms of response times. I mean the speed with which developers can launch a project and move past startup tasks into meaningful feature development and then onto an MVP.

There are a few contributing factors here:

1. Elixir is a productive language; a lot can be accomplished in a small amount of code.
2. Phoenix doesn’t require much boilerplate. The tooling generates genuinely good data access methods for database models and LiveView forms as needed.
3. There are a lot of capabilities that you get from the framework "for free". Need a pub/sub implementation for propagating events? You already have one running as part of the framework. Have a requirement to track user presence? Phoenix comes with it; you just need to add one line to your config file to enable it. A fast, distributed key/value store? Yep, that's natively part of the environment too.
4. Finally, and most importantly, there's no need for a separate front-end codebase. No tests in another environment, no coordination on deployments, no having to figure out type specs or troubleshooting breaking changes to an API across code bases. You can de-scope your effort by half (or more) with just the selection of the environment.

Completeness

Typically, building software to test a business hypothesis means coding the happy path first, then coming back and turning it into production software later. This process always incurs some tech debt. Experienced developers can minimize it, but a short schedule will mean shortcuts taken somewhere.

Elixir can substantially help with this problem. The boilerplate includes good starting tests for everything it creates. Don't have time to implement telemetry? It’s already there. Don't have any consideration for package and deployment mechanisms? It's part of Elixir's core tooling as well.

These features are so accessible that even in an initial sprint, their value outweighs their cost to implement, which translates into developers actually doing just that. This means it’s easy to include them from the beginning rather than having to come back later for a retrofit.

Sustainability

Beyond simply making sure that your initial feature-set is robust enough to support customers, the next set of questions include:

1. "How do we scale this?"
2. "How quickly can I add features?"
3. "Does it need an external API?"
4. "How do the support costs scale with user adoption or usage?"

LiveView doesn't force tradeoffs between quick progress and doing things the “right-way” or closing the door to further enhancements. For example, skipping an external API at the beginning saves time and Phoenix allows easily leveraging business logic to add this external API later, when needed.

The simplicity of the programming model also translates into a codebase that can be effectively re-factored and extended without costly effort for developers to clean it up. Elixir code tends to be clean and the functional programming paradigm encourages re-factors.

In terms of scaling and operational complexity, it's worth noting that the underlying runtime was originally developed to run telephone switches - a very demanding set of requirements, which has received continuous development and improvement since. The community, which has adopted Elixir and LiveView (including Discord, and WhatsApp), operates on a vast scale and contributes knowledge, code, and inspiration.

Wrap-up

We’re often faced with the challenge of building an MVP quickly and cheaply in order to test a hypothesis, only to find that (in order to continue) we have to start from scratch because it was under-built.

By using Elixir, Phoenix and LiveView, developers can deliver a product prototype in a few days, and production-ready code afterwards in weeks, rather than months. Because Elixir also provides so much "for free" (e.g. PubSub, clustering, presence, distributed KV store), software can be built quickly while maintaining a high degree of quality, avoiding the often-seen need to go back and clean up a pile of tech debt after MVP is shipped.