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

# Customize supervisor processes
Process supervision begins with the supervisor Behaviour. We’ll get an overview of it in this section. Over the next few sections, we’ll learn to customize supervisor processes. Then we’ll build a supervisor to monitor all the game processes in Islands.

Like `GenServer`, supervisor is an Elixir Behaviour that wraps an OTP Behaviour. In this case, that is **`:supervisor`**. Like `GenServer`, we can also spawn new processes from supervisor modules. These supervisor processes start, monitor, restart, and stop other processes within an application.

We call any process under supervision a **child process** of the supervisor. Child processes can be workers, like `GenServer` processes, or other supervisor processes.

Since supervisors can supervise other supervisors, we can build tree structures of the supervised processes. These supervision trees allow us to be specific about how we supervise processes. We can tailor the way a supervisor behaves for a given type of process by specifying different startup options.

When we define a new supervisor module, we describe how we want it to supervise its child processes and what restart strategy to use. We also specify the circumstances under which the supervisor should restart the process.

We can also define some circumstances under which the supervisor itself should terminate and restart. Consider the case of a process that crashes continually and doesn’t successfully restart. There’s clearly something wrong that restarts aren’t fixing, and we wouldn’t want those restarts to continue indefinitely.

Supervisors allow us to configure the maximum allowable number of restarts over a given period of time with the `:max_restarts` and `:max_seconds` options. The default value for `:max_restarts` is `3`, and the default value for `:max_seconds` is `5`.

Restart strategies are a little more involved than restart thresholds. Let’s take a closer look at those next.

# Supervision strategies

Processes often depend on one another to do their work. If a child process crashes, restarting just that process might not stabilize the application. In the event of a crash, a supervisor needs to decide whether to restart just the one crashed process or other processes as well. If it needs to restart others, it must decide which ones. Supervisors depend on restart strategies to make those decisions.

We’re going to look at all the available strategies, see how they work, and learn how to choose the right one for a given situation.

Each supervisor process can supervise a number of child processes. Those child processes might have different types of relationships with one another.

Sometimes all the child processes depend on one another, so if one of them crashes, the others will be invalid. Sometimes they are all completely independent. Therefore, if one crashes, the others will be fine.


Let's introduce the supervisor's behavior.

Introduce the Supervisor's Behavior

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

Introduce the Supervisor's Behavior

Customize supervisor processes