Making the Impossible Easy

The other day we posted a blurb on LinkedIn that referenced a significant Ready Room feature that many of us take for granted: real time updates of the inspection synchronized across the entire team. That is, every change to an inspection, be it moving a request to a new column, uploading a file, or updating scribe notes, is instantaneously reflected in the browser of every team member. There is no need for users to continuously click the refresh button or to communicate changes out of band. Everyone knows at a glance the complete state of the inspection, eliminating meetings and handoffs while dialing down the stress.

If we had set out to build this same level of functionality only twenty years prior, we most likely would have failed. It simply wasn’t possible. Even ten years ago, the technological hurdles would have meant months of development time only to create a lackluster facsimile of the functionality we have today. But just two years ago, by leveraging a select set of technologies, we were able to have a prototype running in an afternoon.

Let’s talk about those technologies: Erlang, Elixir, Phoenix, and LiveView.

Erlang is a programming language and runtime environment created in the 1980s at Ericsson. (The name Erlang is a portmanteau of “Ericsson Language.”) Its superpower is to make it easy to create and operate distributed, low-latency, concurrent systems, In other words, Erlang enables mere mortals to build networked applications that can safely and quickly do more than one thing at a time, something, you may be surprised to learn, that is extremely difficult for computers to do. There’s only one problem with Erlang; it’s—erm—rather unfashionable. (And if you think that engineers make decisions based solely on technical merit, please take a moment to disabuse yourself of that notion.)

Enter Elixir. Elixir is also a programming language. It was initially released in 2012 and its primary benefit is to have a very approachable syntax surrounded by a suite of modern libraries and tools. It also happens to compile down to Erlang code, meaning that programmers can reap all the benefits of Erlang while working in a modern and stylish environment.

It’s one thing to have a modern development environment; it’s quite another to develop everything from scratch. For instance, if you’re building a web application, you don’t want to first spend a year poorly reimplementing common web infrastructure. What you want instead is to focus your development efforts on your problem domain, then run your code in a robust “web framework” that abstracts away most of the web’s plumbing. If you were programming in Java, you might choose Spring as that framework. In Ruby, you would likely choose Rails. But when you’re programming in Elixir, you choose Phoenix.

Phoenix is a web framework written in Elixir that saw its 1.0 release in 2014. It differs from the other frameworks in several very important ways. For one, it’s fast—very fast. It’s immediately productive, natively concurrent, has internal support for publish and subscribe messaging, and finally, it implements Ready Room’s secret weapon; LiveView.

But before we can talk about LiveView, we need to first understand a little of how the web works.

When you use a browser to request a web page, your browser makes a network connection to a web server. The web server accepts the request, sends back a response, and then—and this is the critical bit—drops the connection! That may sound weird, but if you’re looking to build something that scales world wide, that something can’t use all of its resources managing billions of long lived network connections. Of course, there’s a cost to this design decision: if the server wants to send something to the browser without first being asked, it can’t. There’s simply no connection between the two.

Over the years, there have been multiple attempts to address the need for persistent full-duplex communication between client and server, such as long polling and Server Sent Events, but none of them was particularly effective. In 2011, however, the WebSocket specification was released to address exactly this issue, and by the end of 2013 most web browsers had implemented support. Still, in order to properly leverage WebSockets, support also needed to be added to an approachable web framework that was capable of supporting millions of concurrent network connections. You see where I’m going, right?

WebSocket support has been part of Phoenix from the beginning, and by the end of 2015 Phoenix was able to manage 2,000,000 active network connections on a single, albeit very powerful, computer. Awesome! But utilizing that power to build dynamic web applications was still a bit of a slog. Then in late 2018, the Phoenix team announced LiveView, a web development technology that “provides rich, real-time user experiences with server-rendered HTML,” elegantly solving the problem of asynchronously updating a single user’s display. Combine LiveView with Phoenix’s support for interprocess messaging, Elixir’s ease of development and operation, and Erlang’s support for concurrency and distributed systems, and suddenly all of the pieces were in place to easily update a large number of browsers whenever desired.

The first pre-release of LiveView was in March 2019. The 0.1.0 release was in August (note the leading zero). Ready Room development began a month later. Talk about bleeding edge! By the time Ready Room launched in May of 2020, LiveView had been updated 21 times. Despite this rapid change, Ready Room shipped with full support for distributed real-time synchronized inspection boards. Today, 20 months later, both LiveView and Ready Room continue to improve, though, thankfully, at a much more modest pace.

More important than all of this technology, however, is how it is used to improve our customers’ ability to prepare for and manage inspections. Synchronized inspection boards allow every member of the team to have a complete and consistent view into the state of an inspection. Even remote observers, who aren’t allowed to change anything, can watch cards march across the board. Scribe notes are automatically saved and immediately updated on every display. Subject matter experts can see who else is working on a task. Reviewers know when there are responses to be QC’d. Team leads can see when people enter and leave an inspection. Everyone knows when there’s an upcoming meeting. And all of this is true no matter where in this Covid-plagued world inspection team members happen to be sitting. So relax, take a breath, and let us worry about the hard stuff.