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

# `mix.exs`

Any project’s `mix.exs` file has two main functions: defining a project’s metadata and managing its dependencies. Of the two, dependency management is by far the most common thing developers do, and it’s the most important for our purposes as well.

Three functions defined in `mix.exs` do all the work for us. The `project/0` function returns a keyword list of metadata about the application:


def project do 
  [
    app: :islands_engine,
    version: "0.1.0",
    elixir: "~> 1.5",
    start_permanent: Mix.env == :prod, 
    deps: deps()
  ]
end

The app name, version number, and Elixir version are pretty self-explanatory. `start_permanent:` starts the system in such a way that the BEAM will crash if the top-level supervisor crashes. This will be true for the production environment as well.

The `deps:` key holds a list of build-time dependencies on which this application depends. The value here is the return value of the `deps/0` function, also defined in `mix.exs`:

```Elixir
defp deps do 
  []
end
```

## Dependencies in `IslandsEngine`

Our `IslandsEngine` has no dependencies, so the return value here is an empty list. When we generate a new Phoenix project in the next section, we’ll see an example with a number of dependencies.

There are actually two types of dependencies for Applications: 
* Those that matter for runtime.
* Those that come into play for build/compile time.

Mix uses the dependencies listed in the `deps/0` function to build the project. Any Application in this list can have its own dependencies. This is how we can compose a larger tree of dependencies, just as we saw with supervision trees in [Process Supervision for Recovery](https://www.educative.io/courses/functional-web-development-elixir-otp-phoenix/introduction).

The last function in the `mix.exs` is `application/0`. It returns a keyword list of data related to starting the application. The value of the `:extra_applications` key is a list of application names, which are the runtime dependencies. Mix makes sure these are running before it starts `:islands_engine`. The `:mod` holds a tuple for the module name of the callback module and also holds a list of options that the `start/2` function in that module might need:
```Elixir
def application do 
  [extra_applications: [:logger],
  mod: {IslandsEngine.Application, []}] 
end
```
`IslandsEngine` depends only on the `:logger` Application at runtime. This dependency is a default for all Applications Mix generates. Elixir itself supplies this, so we don’t need to list it in the `deps/0` function.

If our Application doesn’t have a supervision tree—for example, if we omitted the `--sup` flag when we generated the project—we can omit the `mod` key completely:
```Elixir
def application do 
  [extra_applications: [:logger]]
end
```
At the outset, this might seem a little redundant. Shouldn’t Mix be able to infer the Application list from the `deps` list as long as we give it some clues? Since **Mix 1.4**, it can.

```Elixir
def application do
  [mod: {IslandsEngine.Application, []}]
end
```
If there are runtime dependencies not listed in the `deps/0` function – `:logger`, for instance – we can handle that with the `:extra_applications` key:
```Elixir
def application do 
  [extra_applications: [:logger],
  mod: {IslandsEngine.Application, []}] 
end
```
If we have compile-time dependencies that we don’t need to start when we start our application, we can mark them as `runtime: false` in the `deps/0` function:
```Elixir
defp deps do
  [{:some_new_dep, "> 0.0.0", runtime: false}]
end
```
This brings us to the end of dependency management in `mix.exs`. Once we have defined the dependencies, we need to be able to start them inside the BEAM.

Let’s take a look at the files starting with mix.exs.

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

Manage Dependencies

`mix.exs`