The distributed download requester and progress tracker.

In the last part of the series, we saw how to create a singleton process across a cluster of nodes, using three different global registries. This approach is commonly used to run a unique background task that you want to keep running no matter what changes happen in the cluster’s topology. However, we can use a similar pattern to run short-time running tasks that will die once they finish their job, with the same guarantees. An excellent example of this would be an application where users can download a file. However, generating the file is an expensive task that can…

The tale of the periodic singleton process and the three different global registries.

In the last part of the series, we saw how to manually build a cluster of nodes in an Elixir application, ending up automating the process using libcluster. In this part, we will implement the first of our three real-world examples: a singleton process across the cluster that executes a periodic task and restarts in any node when it dies or starts in a new node when the current node where it is running goes down. Let’s get cracking!

A tale of a periodic singleton process and three different global registries

The tricky part of making a process unique across the cluster is registering it using a unique name in a global…

A gentle introduction to distributed Elixir.

While deploying any project to a production environment, you can either scale it vertically (adding more resources to the single instance where it is running) or horizontally (adding multiple instances). If you don’t like putting all the eggs in a single basket and choose the horizontal approach, Elixir offers all the necessary distributed features that you need out of the box without any additional dependencies, letting you build a cluster between the different instances of your application.

Clustering your service allows you to do very interesting stuff, from spawning new processes in any instance to sending messages between cluster nodes…

Adding a cache to the repository and broadcasting changes to the views.

In the previous part, we talked about Phoenix LiveView and implemented all the necessary views and templates to render all the content on our website. Each live view requests its contents to Airtable on its mount function, assigning them in its state. At first, it sounds like a proper implementation, similar to what we would have done using Ecto and a database to store the contents. However, the current solution has three main issues:

  • Using HTTP to request content against an external service adds an overhead to the initial page load.
  • If, for whatever reason, the external service is down…

Rendering content using LiveView

In the previous part, we generated the base application, and the Airtable API HTTP client to request both contents and blog articles. We also defined the Article and Content domain models, and implemented the repository pattern with two different adapters, one returning fake data for testing purposes, and the other using the Airtable HTTP client to request and convert the returned data into our domain. It's time for some front-end fun, so let's get cracking.

Content rendering using LiveView

One thing before continuing, though. I’m using Bulma, which is very good looking and easy to use CSS framework for the UI styles. To use…

The project set up and implementing the repository pattern.

In the previous part of these series, we talked about what we are going to be building and its two main parts. Today, we will focus on the Phoenix application, but you need the Airtable base to follow up on the tutorial. Therefore, if you don’t have an Airtable account, sign up, and click on the Copy base link located at the top right corner of the source base. Once you have imported it into your workspace, we can continue creating the Phoenix application.

Creating the Phoenix application

Before generating the project scaffold, let’s install the latest version of phx_new, which by the time…

Building a headless CMS around Phoenix LiveView and Airtable.


In this new tutorial, we are going to be building a headless content management system consisting of two main elements, which are an Airtable base and a Phoenix application powered by LiveView. Let’s take a more in-depth look at them:


Airtable is a really cool service based on spreadsheets grouped in bases, that act as a database. Using a very intuitive and friendly UI, it lets you design your own data structures, add attachments, handle relationships between different tables, design different data views for your tables, and much more. …

How I built a concurrent ant farm with Elixir and Phoenix LiveView.

A couple of years ago, I worked on an Elixir personal project which consisted of a virtual ant farm, where every ant was a GenServer process, simulating a basic AI behavior. What initially was going to be something straightforward; it ended up being much bigger and not working as planned, and eventually forgotten. When Chris Maccord announced Phoenix LiveView, I thought to myself that I wouldn’t use it for now, because I enjoy too much writing front-end in Elm. However, I also love Elixir and Phoenix, so I couldn’t resist giving it a try, and giving the ant farm another…

Removing Elm ports (to interact with external JS libraries) in favor of Web Components.

One of my favorite talks from Elm Europe 2018 conference was the one about When and how to use Web Components with Elm by Luke Westby, creator of the popular Elm live editor Ellie. In this fun and enlightening talk, he suggests an alternative way of using external JS libraries in Elm, rather than relying on ports. Ports, although being the standard way of communicating with external JS in Elm, might not be the right tool for some particular situations, especially when your application grows and you need to handle a significant amount of them. The alternative way he exposes…

Setting up webpack as our asset bundler and the Elm single-page application.

In the previous part of the series, we covered all the back-end logic regarding sending authentication emails and using the generated tokens to authenticate the connection of a Phoenix socket. In this part, we are going to focus on the front-end, building the Elm single page application skeleton, and using the websockect authentication to hide some parts of it to unauthenticated users. Let’s get cracking!

Front-end setup

I’ve been using Elixir and Phoenix in the back-end, and Elm in the front-end, for almost three years already, and I’m delighted with the result. I tend to use Phoenix’s default asset bundler, Brunch, but…

Ricardo García Vega

I’m Ricardo, a full-stack web developer who loves building web applications using modern technologies such as Elixir, Phoenix, and Elm.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store