---
title: Book review - Programming Phoenix
date: 2019-05-06
---
Book review: Programming Phoenix
** Part one: functional MVC
The first chapters really give a proper introduction to Phoenix. The first steps are to write down every line of code, from Ecto schema to view helper.

On chapter X the =mix gen.html= was introduced, but only a as shorthand way of writing some of tue setup code from the provided input. I really liked that. It used scaffolding not as a magic wa última of generating the all the code of your application, and it wasn't promoted that way. Not only that, after all the steps, I could read all of the generated code and say: "well, I could've written that!" (Which is what I imagine was the authors goal).

I missed some tests exercising the error cases. Maybe it's because the book is just an introduction, maybe I shoild Let It Crash more often, but I certainly would appreciate having more extensive test coverage.
*** On plugs:
I found the suggested example of creating an authentication plug very rich. It showed one more time how it is just a sequence of function calls, nothing else. The halt pattern however is yet another ad hoc implementation of an old friend (add link to train lanes analogy), and showed that Elixir doesn't treat this as first class. Those aren't limitations of the book though, they're from the framework and language.
*** Database:
Even though Elixir is functional and it's data structures are immutable, Phoenix itself takes the default approach to persistence used by mutable languages in the large, even generating update and delete functions that do just that. The =timestamps= function (from Ecto?) creates an illusion that you have an audit trail and know what happened when, but it only takes you a single update to a table for you to loose information: this was =created_at= X and =updated_st= Y, but what was ipdated? Is is the name, the age? If it was the name, what was previously stored there? Phoenix builds no better solution than treating the database as a global, lossy, mutable variable.
** Part 2:
On part 2 the book changes gears and leaves the traditional web developmentarea and turns to OTP patterns.

It was interesting to see how Phoenix embraces OTP and builds o  top of it. Instead of cherry-picking some OTP patterns, a Phoenix application is an OTP application itself.

From Building a simple GenServer to having authenticated channels, I felt that the Phoenix solution towards persistent connections is pretty elegant, and chapters X, Y and Z presented it very well. I noticed the same functional mindset from Plug as chaining of functions present in GenServers and channels, as an state is the previous state plus a function.
** Conclusion
Overall, I liked both the book and the framework, and would readily recommend it to someone interested in  learning Phoenix.