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

Despite the name, **Applications** are not what we normally think of as software applications. They are reusable units of code that are bigger than modules. In fact, they most often contain multiple modules. They’re similar in scale to libraries in other ecosystems. While they can function as libraries, they can also be much more.

Applications can act as the true building blocks for our programs and a means of putting together integral pieces of business logic to build a larger whole. Working with larger building blocks like these makes us really productive.

# `IslandsEngine` Application 

Applications can also stand on their own as what we traditionally call an application. The `IslandsEngine` Application we developed in the first part of the course is one example. It is a fully functioning game, albeit with an unfriendly user interface. As complete as it is, we can still use it as a building block for something larger, as we’ll soon see.

The **`:application`** Behaviour is a specific OTP Behaviour written in Erlang, just like `:gen_server`. There is a module in OTP that defines `:application-specific` functions as well as a list of callbacks we need to implement. Elixir provides a wrapper module around the pure Erlang module called Application. We’ll use the Elixir wrapper most often.

The Application Behaviour lets us do three things. It lets us define and name Applications. It facilitates dependency management among Applications. We can define hierarchies of Application dependencies and the Behaviour will make sure they work correctly. The Behaviour also facilitates cleanly starting and stopping individual applications in a running BEAM.

**“Cleanly”**  means two things here. It makes sure to start any dependent Applications before it starts itself. It also keeps track of any processes the Application spawns during startup or while it’s running. It is sure to stop them when the Application stops.

Now that we have an idea of Applications’ significance, let’s dig a little deeper and see how they work.

# Understanding Applications

The good news is that we’ve been working with an Application all along. At the beginning of the course, when we generate the brand-new `IslandsEngine` project, Mix automatically creates it as an Application. We didn’t need to look deeply at the Application Behaviour because `IslandsEngine` stood on its own for our purposes.

Although, now we need to use it as a dependency, as a building block to create a larger project—the web interface. Understanding Application dependencies will clarify our work on this project and any other Elixir projects we work on.

We already have examples of the Application Behaviour–related files in `IslandsEngine`. We use them to understand dependency management and to start or stop individual applications inside the BEAM. We’ll see the independence of Applications firsthand that lets us solve the coupling problem so prevalent in web applications.

There are three parts to the implementation of an Application, and Mix is involved in all of them.

When we generate a project with `mix new`, we get a file named `mix.exs` at the root of our project. The **`mix.exs`** file defines key aspects of the Application, everything from its name and version number to a list of applications it depends on to build the project.

Mix also generates a Behaviour callback module in the `/lib` directory that is named after our project. In the case of our game engine, it generates `/lib/islands_engine/application.ex`. If we supply the `--sup` flag to `mix new`, the callback module will contain the `start/2` callback function necessary to start the top-level supervisor for the Application. Without `--sup`, the file will be there but will be empty.

Once we compile the project, Mix generates an application resource file, written in Erlang. The BEAM will use this file to work with our Application.

Understand what are the applications of the game IslandsEngine.

Applications

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

Applications