---
title: Book review - Programming Phoenix
date: 2019-05-06
---
I've recently finished reading [[https://pragprog.com/book/phoenix/programming-phoenix][Programming Phoenix: Productive |> Reliable |> Fast]] by Chris McCord, Bruce Tate, and José Valim, and I wanted to share my impressions on it.
Overall I liked the book, and it incentivized me to keep learning about Elixir, Phoenix, Erlang and OTP. After a few years working with Clojure and using functional programming techniques daily, Elixir feels very natural, and it met many of my expectations, like having persisten immutable data structures, or have smooth interop with Erlang.
IO bound[fn:io-bound]
This is a format
https://git.sr.ht/~euandreh/songbooks
feed
** Part one: functional MVC
The first chapters really give a proper introduction to Phoenix.
The first steps are to write down, as I learned later in the book, every single line of code that the default Phoenix scaffolding tool would generate, from Ecto schema to view helper. I liked this approach of showing what task needs to be accomplished before introducing a tool that automates the task. It gave me a stronger understanding of what code was being generated, and empowered me to change the later generated code.
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.
[fn:io-bound] I'm using an oldish computer with HDD to write this piece, and it is now running with very low CPU load but stuck at writing to the disk some email indexes from [[https://notmuchmail.org/][notmuch]]. IO bound.
