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

# Supervision

Supervisors may sound magical, but there are two simple, practical mechanisms behind their magic: linking processes and trapping exits. We’ll see how they work together to make supervisors work.

The key to process supervision is for one process to be able to link to other processes and know when those other processes crash. Beyond that, the supervising process needs to keep running if it gets crash notifications from the linked processes.

When one process in a group of linked processes crashes, it sends a special message called an **exit signal** to all its the other linked processes. Any process that receives an exit signal will also exit and send an exit signal to all its other processes, forming a chain reaction of exits.

This chain reaction makes it hard for the supervisor processes not to crash when one of the processes they're monitoring crashes.

The mechanism to fix this is called **trapping exits**. When a process traps exits, it transforms exit signals into regular messages that end up in the process’s mailbox. This process can then handle those regular messages just as it would any other. That’s the key to making supervisors work.

Those are nice words, and they help us understand supervisors from one angle, but digging in and watching processes interact in the console will deepen our understanding. This is what we’re about to do.

# Send and receive messages

We’re going to see how unlinked processes behave when they exit. Then, we do the same for linked processes and for linked processes where one is trapping exits.

Much of this work involves passing and retrieving messages directly. We’ll use `send/2` to send messages and `receive/1` to pull them from a process’s mailbox.

Let’s take a quick practice run with these functions in IEx.





Learn how to link processes in supervision.

Linking Processes in Supervision

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

Linking Processes in Supervision

Supervision