Phoenix Web Development

Mike Voloz, Brandon Richey

• Publisher: Packt Publishing
• Year: 2018
• ISBN:
  9781787284777
• Edition: 1
• Topic: Computer Science
• Subtopic: Web Programming
• Index: Computer Science

Learn to build a high-performance functional prototype of a voting web application from scratch using Elixir and Phoenix

Key Features

• Build a strong foundation in Functional-Programming techniques while learning to build compelling web applications
• Understand the Elixir Concurrency and parallelization model to build high-performing blazingly fast applications
• Learn to test, debug and deploy your web applications using Phoenix framework

Book Description

Phoenix is a modern web development framework that is used to build API's and web applications. It is built on Elixir and runs on Erlang VM which makes it much faster than other options. With Elixir and Phoenix, you build your application the right way, ready to scale and ready for the increasing demands of real-time web applications.

This book covers the basics of the Phoenix web framework, showing you how to build a community voting application, and is divided into three parts. In the first part, you will be introduced to Phoenix and Elixir and understand the core terminologies that are used to describe them. You will also learn to build controller pages, store and retrieve data, add users to your app pages and protect your database. In the second section you will be able to reinforce your knowledge of architecting real time applications in phoenix and not only debug these applications but also diagnose issues in them. In the third and final section you will have the complete understanding of deploying and running the phoenix application and should be comfortable to make your first application release

By the end of this book, you'll have a strong grasp of all of the core fundamentals of the Phoenix framework, and will have built a full production-ready web application from scratch.

What you will learn

• Learn Phoenix Framework fundamentals and v1.3's new application structure
• Build real-time applications with channels and presence
• Utilize GenServers and other OTP fundamentals to keep an application stable
• Track users as they sign in and out of chat with Phoenix's built-in presence functionality
• Write your own database interaction code that is safe, bug-free, and easy to work with
• Explore testing and debugging methodologies to understand a real software development lifecycle for a Phoenix application
• Deploy and run your Phoenix application in production

Who this book is for

This book is for people with a basic knowledge of Elixir, who want to start building web applications. Prior experience with web technologies is assumed.

Storing and Retrieving Vote Data with Ecto Pages

When we left off last, we had sat down and gained a thorough knowledge of controllers and the entire connection model. We began with the internal request, going through the router, hitting the glue of the controller, and finally wiring up data and displaying it back to the user via our views and templates. All of this is great by itself, but if we don't have somewhere to store and retrieve data, our application is largely decorative and not terribly functional. We're going to change that by implementing a means of getting our data and putting it back into a database.

Before we can dive too far into storing our data, however, we need to understand the model behind how Ecto takes the information from the database and presents it to the application at large. Ecto, the database library that we'll be using in our project, relies on the concepts of Schemas and Contexts. Through the combination of these techniques, we can safely separate out the side effects of working with a database that may be changing constantly due to interactions with our application. Let's take a few minutes first, however, to understand how contexts and schemas interact with each other and what roles they take in the data interaction layer of our application.

In this chapter, we'll take a deep dive into the topics most directly facing the backend of our application. Specifically, we'll be taking on:

• What the roles of schemas are in our application
• Creating new migrations
• How to write migrations
• Understanding the roles of contexts
• Hooking a context up to a controller
• Writing some basic unit tests to cover functionality

These are all necessary to really understand how the database side of things glues the rest of our application together over time. By the end of the chapter, you should have a thorough working knowledge of all of the database-specific parts of your application and how they all fit together!

Understanding the role of schemas

The first thing to start understanding is where and how schemas define the shape of the data in your database. Schemas help describe what tables your application uses behind the scenes and what fields exist to Ecto; the Schemas themselves do not define the overall structure to the database itself.

This helps describe the columns and define what types each of the columns are (for example, a string, an integer, or a reference to another table). The important thing to note about schemas in Ecto is what they are intended to do: separate the ideas of data from operations. By keeping our schemas very specific to understanding, describing, and translating the data, we can keep our applications largely side-effect-free when interacting with the database!

Before we can take a really deep dive into schemas, we should start by talking about what our initial voting data model should look like! Let's take a look at the code we introduced for our data model in the controller that we wrote in the last chapter:

 poll = %{
 title: "My First Poll",
 options: [
 {"Option 1", 0},
 {"Option 2", 5},
 {"Option 3", 1}
 ]
 }

Based on this, we can probably decide that our model for our Vote concept in the database can be a pretty simple thing. We have the Vote itself, which has a title attached to it, and then the options that people can decide between. We're going to make an assumption here that you're using the default database choice for Phoenix applications, Postgres (but it shouldn't change much regardless of your database choice!). So, a very simple database table model would be:

Poll	Title Options (reference to another table
Option	Poll ID (reference to the poll this option is attached to) Title Votes

This creates two separate tables: Polls and Options. The Polls table will store all of the Polls themselves and then the options table will store the possible vote choices and their current scores. The Options table will store a reference back to the original poll (we'll get into this later when we start talking about associations). This is typically referred to as a "one to many" relationship between the two tables; a Poll can have many Options, but an Option can only have one Poll. This also means that the referencing of different tables only needs to take place on the Option, not on the Poll.

Creating a new migration

Given our newfound understanding of our complex object, we need to create our database table. Now, there are a few ways to do this. For example, we can use Phoenix and Ecto's built-in generators to give us a skeleton for this, but since we're trying to learn and understand the underlying systems that are needed for our application, we’ll start by NOT using generators to build our initial skeletons; later on, we’ll dive a little bit into using the generators and how to use them.

We'll get into a habit of learning what we can from the various help commands that exist in mix and IEx, so let's do the same. We can search for any of the Ecto commands that exist for mix with the following:

$ mix help | grep ecto
mix ecto # Prints Ecto help information
mix ecto.create # Creates the repository storage
mix ecto.drop # Drops the repository storage
mix ecto.dump # Dumps the repository database structure
mix ecto.gen.migration # Generates a new migration for the repo
mix ecto.gen.repo # Generates a new repository
mix ecto.load # Loads previously dumped database structure
mix ecto.migrate # Runs the repository migrations
mix ecto.migrations # Displays the repository migration status
mix ecto.rollback # Rolls back the repository migrations
mix phx.new.ecto # Creates a new Ecto project within an umbrella project

Typically any generator will have a .gen as part of the command itself. We've already run mix ecto.create to create our database, and we don't need more help information, nor do we want to drop or dump anything from our database. We don't need to load, and we have nothing to migrate yet, so that also crosses mix ecto.migrate and mix ecto.migrations off our list. Finally, we see mix phx.new.ecto, which talks about creating a new Ecto project within an umbrella project, which also doesn't fit into what we're trying to accomplish here, so that leaves us with our two generator commands.

mix ecto.gen.repo creates a new repository for our application, which we don't need, so we're going to work with mix ecto.gen.migration to create a migration for our application! One of my favorite parts of working with Elixir and Phoenix is how entirely fantastic the documentation that is built-in to almost every single command is, so let's take a look at the documentation for the migration generator and learn how to use it. To get help for anything in mix remember that we can prefix help to any of the commands; let's run mix help ecto.gen.migration:

$ mix help ecto.gen.migration

 mix ecto.gen.migration

Generates a migration.

The repository must be set under :ecto_repos in the current app configuration
or given via the -r option.

## Examples

 mix ecto.gen.migration add_posts_table
 mix ecto.gen.migration add_posts_table -r Custom.Repo

The generated migration filename will be prefixed with the current timestamp in
UTC which is used for versioning and ordering.

By default, the migration will be generated to the "priv/YOUR_REPO/migrations"
directory of the current application but it can be configured to be any
subdirectory of priv by specifying the :priv key under the repository
configuration.

This generator will automatically open the generated file if you have
ECTO_EDITOR set in your environment variable.

## Command line options

 • -r, --repo - the repo to generate migration for

Location: _build/dev/lib/ecto/ebin

Okay, this is a pretty simple command! Based on the help documentation, we can see that what we want to do is create a migration that creates a new table, which we’ve referred to previously as Polls.

Creating the Polls table migration

Based on that, let's create our new migration, add_polls_table:

$ mix ecto.gen.migration add_polls_table
* creating priv/repo/migrations
* creating priv/repo/migrations/20171005161434_add_polls_table.exs

By default, that will give us a mostly blank file consisting of:

defmodule Vocial.Repo.Migratio...