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

# New IEx session

Now that we have all the pieces assembled, let’s see how they all work together in IEx. 

We start by aliasing the `Game` and `GameSupervisor` modules:
```IEx
alias IslandsEngine.{Game, GameSupervisor}
```
Now we can use the `GameSupervisor.start_game/1` function to start a new game:
```IEx
{:ok, game} = GameSupervisor.start_game("Hopper")
```
Note that the PID is a number. If we generate a `via` tuple for the first player’s name and check its PID with `GenServer.whereis/1`, it should be the same:
```IEx
via = Game.via_tuple("Hopper")
GenServer.whereis(via)
```

Now let’s add a second player and check the game process’s state to make sure we’ve got both players’ names:
```IEx
Game.add_player(via, "Hockney") 
state_data = :sys.get_state(via) 
state_data.player1.name 
state_data.player2.name 
```
Good—they’re both set.

# Exit the process
Now let’s force the game to exit and see what happens:
```IEx
Process.exit(game, :kaboom) 
GenServer.whereis(via)
```
The first thing we see is that the `via` tuple points to a different PID. This tells us a couple of things. Not only did the supervisor restart the process after the exit, but the `Registry` noticed and reset the new PID to the old key. That’s pretty nice.

Now let’s check the state to see which players’ names we have set:
```IEx
state_data = :sys.get_state(via) 
state_data.player1.name 
state_data.player2.name 
```

Interesting.  The first player’s name is still correct, but we don’t have the second player’s name at all.

> **Note:** Run these commands in the terminal below. Don't worry about any warnings you might get.

Find out how all the code we've written so far behaves in the Elixir console.

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

Put the Pieces Together

New IEx session