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

## Allow the players to guess coordinates
Guessing coordinates is the most important action in the game. In order to process a guess, we need to know which player is guessing. We also need to know the row and column values the player is guessing.

We start with a client function, `guess_coordinate/4`, that takes those values. This wraps a `GenServer.call/2` with a tuple representing the four arguments and the action. We can see this here:
```Elixir
def guess_coordinate(game, player, row, col) when player in @players, do:
  GenServer.call(game, {:guess_coordinate, player, row, col})
```

One of the tricky things to remember about guessing is that players guess against their opponent’s board. We've written a convenience function to get the key of a player’s opponent. From there, we get the opponent’s board with `player_board/1`.
```Elixir
defp opponent(:player1), do: :player2
defp opponent(:player2), do: :player1
```

We need to check a number of conditions. These include whether:
- The rules allow the given player to guess.
- The row and column values make a valid coordinate.
- The guess is a hit or a miss, whether it forests an island, and whether it wins the game.
- The state should transition to `:game_over`.

These checks define our `with` block:
```Elixir
with {:ok, rules} <-
       Rules.check(state_data.rules, {:guess_coordinate, player_key}),
     {:ok, coordinate} <-
       Coordinate.new(row, col),
     {hit_or_miss, forested_island, win_status, opponent_board} <-
       Board.guess(opponent_board, coordinate),
     {:ok, rules} <-
       Rules.check(rules, {:win_check, win_status})
```

In cases where all of these checks pass, we need to update the state data and the `rules` struct. We’ll have to add the current guess to the guessing player’s guesses.

We also update the opponent’s board because a hit would transform an island by adding a coordinate to the `:hit_coordinates` set.

We make a trade-off here by adding an extra operation for some cases to eliminate the complexity of checking whether the guess was a hit. This informs what we've put in the pipeline of the `do` block:
```Elixir
do
  state_data
  |> update_board(opponent_key, opponent_board)
  |> update_guesses(player_key, hit_or_miss, coordinate)
  |> update_rules(rules)
  |> reply_success({hit_or_miss, forested_island, win_status})
```

There’s one new function in this pipeline: `update_guesses/4`. The `Guesses` module provides the `add/3` function. The problem, however, is that each player’s `guesses` struct is two layers deep in the state data. We could extract that struct manually, transform it, and put it back. However, there’s an easier way. Elixir’s `Kernel.update_in/2` allows us to easily update nested data:
```Elixir
defp update_guesses(state_data, player_key, hit_or_miss, coordinate) do
  update_in(state_data[player_key].guesses, fn guesses ->
    Guesses.add(guesses, hit_or_miss, coordinate)
  end)
end
```




# Allow the players to guess coordinates
Guessing coordinates is the most important action in the game. In order to process a guess, we need to know which player is guessing. We also need to know the row and column values the player is guessing.

We start with a client function, `guess_coordinate/4`, that takes those values. This wraps a `GenServer.call/2` with a tuple representing the four arguments and the action. We can see this here:
```Elixir
def guess_coordinate(game, player, row, col) when player in @players, do:
  GenServer.call(game, {:guess_coordinate, player, row, col})
```

Understand the functionality of guessing a coordinate.

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

Visualizing Live Streaming Data with Elixir, Kafka, and Chart.js

Appendix

Guess a Coordinate

Allow the players to guess coordinates