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

# Data durability

The code we’ve written so far will work great as long as the BEAM stays up. If we restart the BEAM for any reason, though, the ETS table we created will be gone along with all its data. To handle BEAM restarts, we need more durability.

The way to get that durability is similar to the way we recover data from ETS, just taken one step further. To recover the state when a process restarts, we store it outside the process or any processes linked to it. To recover the state after the BEAM restarts, we need to store the state outside the BEAM.

The code’s shape we currently have will work for this. All the functions are in place and working the way we want them to. We need to swap out ETS for another storage mechanism.
This is where the number of available options grows enormously. There’s no way to cover them all in a single section of this chapter. We can look at some OTP options and a strategy that will apply broadly to a lot of other options.

OTP offers two options right off the bat. **DETS** is a disk-based version of ETS. DETS starts tables with `:dets.open_file/2` instead of `:ets.new/2`. However, the query API is remarkably similar to ETS. This is the durable option with the least change to the existing code.

**Mnesia** is OTP’s distributed database management system. It’s considerably more complex to set up and use than ETS or DETS. While it is likely to be an overkill for the needs of a game like Islands, it might be a great fit for other applications we might be working on. Take a look at the documentation if you’re interested.

Stepping outside  OTP, a single broad strategy will work with a large number of data stores. The idea is to convert the game state to JSON. Once the data is in JSON, the data storage world is open to us. We can store the game state as a JSON data type practically anywhere.
With any of these strategies, the game state will be stored safely out of the BEAM in case the node goes down for any reason. Using the functions and callbacks we’ve already set up, we query for it and set it back in each process’s state.


# Conclusion

What we’ve done in these lessons is pretty remarkable. We started with game processes that could crash and lose all their state at any time. We’ve ended up with games that will automatically recover from any crash and restore their state to the last good version.

Try that in any other language.

Along the way, we’ve explored linking processes and trapping exits. We’ve looked at ways to customize the way supervisors behave with restart strategies and child specifications. We’ve also seen how to start and stop supervised processes. As a bonus, we’ve got an introduction to ETS as well.

We’re headed into the last part of the course now. That’s where we’ll layer on a Phoenix interface and make Islands available on the web.

Learn what happens when the BEAM’s memory goes away or the host reboots.

Wrapping Up

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

Wrapping Up

Data durability