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

# Public interface 

The big picture is that we’re opening up the public interface we created for the game server to the web. The game server is a stateful system. Modern web front-ends are also stateful. We’ll build a Phoenix Channel as a stateful, persistent connection between these two stateful systems. This new channel’s public interface will become the mechanism clients will use to interact with the game.

# Here’s the plan

We build this Channel function by function and check its behavior at each step by calling JavaScript code in the browser’s developer tools console. We want the new Channel to communicate directly with an individual `GenServer` process for a game. Since Channels multiplex messages, a single channel can handle clients sending messages to many topics. This means that a single Channel can handle the communication for numerous games. To check that this communication works means, we need to be able to see what’s happening from the browser all the way down to the server.

To fully exercise this, we use two separate browser windows. This mimics two players playing the game on the web. We work with the developer tools JavaScript console in each browser window. We also have an IEx session open to check what’s happening to the state of the game server.

This setup is going to look like the following figure:

Learn how clients will interact with the game.

Let’s Build It

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

Let’s Build It

Public interface

Here’s the plan