Gain insights into building scalable backend applications with Elixir, OTP, and Phoenix. Learn about persistent connections via Phoenix Channels, and explore distinct, decoupled application layers.

Functional Web Development with  Elixir, OTP and Phoenix by The Pragmatic Programmer_ .png

elixir_islands_test.tar.gz

elixir-app

pheonix-app

elixir-app-guesses

island-interface

phoenix-app-compiled

phoenix-app-iex

phoenix-app-form

phoenix-app-new-module

client-connection

presence

phoenix-app-final

without-presence

Elixir and OTP provide exceptional tools to build rock-solid backend applications that scale. In this course, you’ll build a web application in a radically different way, with a backend that holds application state. You’ll use persistent Phoenix Channel connections instead of HTTP’s request-response, and create the full application in distinct, decoupled layers.

In Part 1, you’ll start by building the business logic as a separate application, without Phoenix. You’ll model the application domain with Elixir functions and simple data structures.

In Part 2, you’ll add in the GenServer Behaviour to make managing in-memory state a breeze. 

In Part 3, you’ll build a web interface with Phoenix where you’ll use Phoenix Channels to establish persistent connections between the stateful server and a stateful front-end client.

Needless to say, you’re going to love this way of building web apps!

Functional Web Development with Elixir, OTP and Phoenix

# What is Phoenix Presence?

From the earliest days of Phoenix channels, developers have tried to figure out how to tell who is currently subscribed to a Channel. Until recently, the answer was to create a custom solution that best fits an individual application’s circumstances. However, we now have Phoenix Presence to solve that problem in a general way for all of us.

Presence has one job to do: to keep track of the clients subscribed to a topic on a Channel. For us, this means keeping track of the players in each game. Presence does this amazingly. This might sound like a trivial task, but it’s deceptively difficult.

If we were to roll our own version of Presence, our first thought might be to maintain a list of the subscribers, add clients to the list when they join, and remove them when they leave. This might work for a system with a single node.

With a single data structure on multiple nodes, though, we would have to make sure that the data is available to all nodes in the cluster. However,  nodes don’t stay up forever, and a crash could lose all the subscription data.

We could put the data in an external database to solve that data durability problem. However, then network hiccups could disrupt communication to the database, and the system would miss clients joining or leaving. This would make the data out of sync with the real state of the channel.

The scenarios only get more complex from there. Add in users subscribing to the same topic from multiple devices and flaky mobile connections, and a solid solution might seem evasive indeed.

That’s where **CRDTs (conflict-free replicated data types)** come to the rescue. They track the sequence of clients joining and leaving, across nodes and clients. They do it without relying on clock time, which varies from machine to machine. CRDTs allow Presence to reconstruct the sequence of events to accurately determine which clients are currently subscribed to a topic on a Channel.

> **Note:** In the future, this job might even be expanded to keep track of other things that can join or leave a group, like nodes, services, and processes. Stay tuned!

Phoenix Presence’s power is compounded by how easy it is to set up and use. We need a new, mostly empty Presence module and need to make sure it’s started when `IslandsInterface` is.

After this, we need a single callback function in the Channel to make it work—though we add another just to help us see Presence in action.

The plan is that as a player joins before we return `{:ok, socket}`, the Channel sends itself a message with the player’s screen name. The first callback we write will match that message and have Presence start tracking that screen name.

# Application setup

Let’s start with a clean slate by shutting the server down and reloading both players’ windows.

We need to begin with an empty Presence module in our application:

Understand the details of Phoenix's Presence in the game.

Phoenix Presence

Introduction

Mapping Our Route

Model Data and Behavior

Working of State Machines

Add OTP for Concurrency and Fault Tolerance

Process Supervision for Recovery

Generate a New Web Interface with Phoenix

Create Persistent Connections with Phoenix Channels

Appendix

Phoenix Presence

What is Phoenix Presence?