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

# Basic units

Now that we have some information to work with, let’s start modeling the most common entity—coordinates. Coordinates are ubiquitous in the game. They are the basic units of both players’ boards and of the islands.

We can identify individual coordinates by the combination of numbers for the row and the column. Passing around the separate row and column values to represent a coordinate, though, is a little messy. It also doesn’t capture the idea that those numbers represent a single entity. It would be better to combine them into a single data structure we can pass around.

We have choices about how we could represent that. We might choose to use a tuple like this: `{1, 1}`. However, we should be careful about tuples if we’re ever going to encode our data as JSON, since it doesn’t have a tuple type.

We might also choose a map, like this: `%{row: 1, col: 1}`. It encapsulates both numbers into a single entity and is easy to pattern match against.

A third option is to use a struct. We’ll pass coordinates around to create islands for players to guess. Structs maintain all the qualities of maps, but they offer compile-time checks on the keys, and allow us run-time checks on the struct’s type.

We’ll use coordinates and pass them around quite a bit. The extra checks make structs seem like the way to go.

# Discussing the code for `coordinate.ex`

The first thing we need is a `Coordinate` module that aliases itself. Let’s create that at `lib/islands_engine/coordinate.ex`. Initially `coordinate.ex` will look like the following. We’ll add the code step by step:





Model Coordinates

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

Model Coordinates

Basic units