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

# The opponent's board
With the coordinates represented, let’s move on to the less complex of the two boards—the opponent’s board.

The opponent’s board is nothing but a group of guessed coordinates separated into those that hit an island and those that missed. There will be a large number of unguessed coordinates as well. However, if we identify all the guesses, we can assume the rest are plain “ocean” coordinates.

This sounds like two lists—one for hits and the other for misses. We could wrap these lists in a struct with `:hits` and `:misses` keys, just as we did for coordinates.

There’s something else to consider here, though. We can’t necessarily guarantee that we’ll receive any specific guess only once. Having unique lists of guessed coordinates would make it more efficient to re-create the opponent’s board from scratch.

We could write our own functions to ensure uniqueness, but there’s an easier way. We can use Elixir’s `MapSet` data structure to guarantee that each member of the `MapSet` will be unique.

# Creating the `guesses.ex` file
Let’s create a new module for guesses at `lib/islands_engine/guesses.ex`, as we did with coordinates. Following the pattern we set in the `Coordinate` module, we alias the `Guesses` module to reduce typing, enforce the `:hits` and `:misses` keys, and define the struct:

```Elixir
@enforce_keys [:hits, :misses]
defstruct [:hits, :misses]
```

Guesses

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

Guesses

The opponent’s board