When the request comes in, the router takes a look at the incoming connection (referred to in the future as the conn) and determines where this request needs to get routed to. It could be something that needs to be handled in a way appropriate to the browser, a way appropriate for an API to handle, or it could also just plain and simply be a 404 error that needs to get served out (depending on what the router says exists for that particular web application).

From there, the connection is passed along through the router and into a pipeline of plugs. Plugs are constructs that can be reduced down to functions that take in the connection structure and optionally some options, and then apply some form of transformation (if appropriate) and return out a modified connection structure. The beauty of this idea is in its simplicity; each plug...

What we haven't done yet is actually create our Phoenix project, so let's do that! I'm going to call this application "Vocial" ("Social Voting" because I am incredibly creative)! We'll start off by running our mix task to create a Phoenix application:

$ mix phx.new vocial
* creating vocial/config/config.exs
* creating vocial/config/dev.exs
* creating vocial/config/prod.exs
* creating vocial/config/prod.secret.exs
* creating vocial/config/test.exs
* creating vocial/lib/vocial/application.ex
* creating vocial/lib/vocial.ex
* creating vocial/lib/vocial_web/channels/user_socket.ex
* creating vocial/lib/vocial_web/views/error_helpers.ex
* creating vocial/lib/vocial_web/views/error_view.ex
* creating vocial/lib/vocial_web/endpoint.ex
* creating vocial/lib/vocial_web/router.ex
* creating vocial/lib/vocial_web.ex
* creating...

If we want to start building out our web application, we'll need to start with some of the base structures that are used to receive our incoming connection, make decisions, pull in new data, and reformat/structure out the response to the user. We'll start with the most fundamental of these: the controllers. Our controllers act as the glue between our templates, our database, and the incoming/outgoing connections; they put everything together in a way that the end user's browser or client can understand. To understand how to effectively use controllers, however, we'll need to ensure we understand how controllers are structured and how best to use them!

We'll want to have some good tests covering all of the code that we will be writing in the course of this application, since we're all good software engineers and should follow good software engineering processes! We'll start off with our controller tests, which include a few cool tools to simulate making connection requests to various controller actions and inspecting the output of the controller functions.

When we start off creating our own controllers/views/etc, if we're not using a generator, we won't have any new logic or functionality to cover tests for the new code we’re writing. Due to this, if we just run mix test without...

We’re now at a point where we have a good baseline to work from for our Poll Controller, which means we're also at a point where we can start transitioning from here into the work for our data side of things. In the next chapter, we’ll start diving into Contexts and Schemas and try to get a good working understanding of integrating a data model into our Phoenix application (and a lot of the design decisions that influence the current structure and why those decisions were made)!

So, now that we know how to glue together the different parts of our application and we understand a few of the pieces that are getting assembled, we need to explore what is arguably one of the largest and more complex pieces of the request/response puzzle: the database! We'll take a deep dive into Ecto and, of course, write good tests to cover any new code we write!