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

# Plan the next step

Spawning and initializing a new `GenServer` process is a great start. However, the default callback implementations we get by using `GenServer` don’t go very far.

In order to build real applications, we need to change the way `GenServer` behaves to fit each application’s needs.

- To do this, we’re going to follow the pattern we’ve used so far. First, write a client function that wraps a `GenServer` function. This, in turn, triggers a callback. We’ll define the new behavior in the callback.

- Each time we add a new public function, we build a new piece of the interface for the game. As we go along, we’ll expose more and more of the game’s behavior. This interface acts as a boundary between the rest of the system and the game. That makes it the right place to check any values passed into the public functions.

- We’ll need to check some conditions in each callback before determining whether the action went as planned. At a minimum, we need to check the rules for each action. Additionally, we might have to check that coordinates and islands are valid or that a player has positioned all their islands.

- We could do this with conditional logic, but that could easily turn into a mess. Instead, we rely on Elixir’s `with/1` special form. The `with/1` form was designed to test multiple conditions in the same place without nested conditionals.

- Every time we use `with/1`, we employ the same three blocks. The `with` block contains all the conditions we’re testing. The `do` block is for the actions we take when all the conditions pass, and the `else` block is where we handle errors.

Besides starting a new game, there are four behaviors we need to define:
- Adding a second player
- Positioning islands
- Setting islands
- Guessing coordinates

We’ll handle them in the same order.

Learn to customize GenServer behavior and use process registration to name individual games.

Customize GenServer Behavior

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

Customize GenServer Behavior

Plan the next step