Learn web development with Elixir. We use GenServer Behaviour for a stateful backend. The front-end will use Phoenix Channels to communicate with the backend.

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

## Position the islands
When players move their islands around on the board, the UI will send messages back to the server. These messages include a key for the island type as well as the row and column numbers for the island's upper-left coordinate.

The `Board` module knows how to position an island with a key and a full island. The `Coordinate` module turns the row and column value into a coordinate, while the `Island` module turns the island key and the coordinate into a full island. The `Game` module coordinates between these, checks to see that all the values are valid and formulates a response.


We start with a public function for the interface as we have before. It takes the game process PID, the player, and the island key. It also takes the row and column of the island’s upper-left coordinate. We use `GenServer.call/2` so we can send a response back to the caller.


We want to make sure that the value we get for the player matches either `:player1` or `:player2`. Let's add a module attribute with both those atoms in a list:
```Elixir
@players [:player1, :player2]
```

Now we add a guard for it in the function head:
```Elixir
def position_island(game, player, key, row, col) when player in @players, do:
  GenServer.call(game, {:position_island, player, key, row, col})
```

# Position the islands
When players move their islands around on the board, the UI will send messages back to the server. These messages include a key for the island type as well as the row and column numbers for the island's upper-left coordinate.

The `Board` module knows how to position an island with a key and a full island. The `Coordinate` module turns the row and column value into a coordinate, while the `Island` module turns the island key and the coordinate into a full island. The `Game` module coordinates between these, checks to see that all the values are valid and formulates a response.


We start with a public function for the interface as we have before. It takes the game process PID, the player, and the island key. It also takes the row and column of the island’s upper-left coordinate. We use `GenServer.call/2` so we can send a response back to the caller.


We want to make sure that the value we get for the player matches either `:player1` or `:player2`. Let's add a module attribute with both those atoms in a list:
```Elixir
@players [:player1, :player2]
```

Now we add a guard for it in the function head:
```Elixir
def position_island(game, player, key, row, col) when player in @players, do:
  GenServer.call(game, {:position_island, player, key, row, col})
```

Understand how to position islands in this lesson.

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

Position the Islands

Position the islands