Diving into Elixir and Phoenix
As part of the 2018 Codegram's Retreat™, I wanted to explore Elixir and Phoenix as an alternative to Ruby and Rails. Here's my experience of a week working on a Phoenix project: a Netflix for dev talks.
Why Elixir and Phoenix?
Elixir got my interest picked a few years ago, as it reminds me of an improved, well-thought, functional Ruby. There's a lot of posts around introducing Elixir to Ruby programmers, so I'll spare you this part, but I want to highlight pipes and guard clauses for method definitions.
I started playing with Phoenix some years ago, but stopped due to lack of time. Still, Phoenix seemed like an unbloated, re-thought Rails. Many patterns seemed familiar, and others seemed improved from what Rails offers. I particularly like plugs (which could remind you of Rails's
before_actions, but plugs can be used in other places too) and contexts, which can't be found in the usual Rails Way™. I like them!
At Codegram we take half an hour every day after lunch to watch dev talks, so we keep a continuous learning. Sometimes, though, it's hard to find interesting talks. What if there was a talk recommender? We couldn't find any, so... let's build a Netflix for dev talks!
We need a project that can keep info about YouTube videos and build a recommendation of talks from a given one. More specifically, we'll delegate the recommendation system to another service, while our specific app will only keep a list of talks and display them.
I spent half of the retreat going through tutorials to get started, and the other half working on the actual project.
We used The Pragmatic Bookshelf's Programming Elixir 1.6 and Programming Phoenix 1.4 (beta version). Both books are awesome and very well explained, although the Phoenix one was still on beta and some sections were missing (we used the first version of the book to fill those parts). Also, the Elixir Forum is a great place to get support.
Project went fine, but I didn't have time to complete it during the retreat, so I'll keep working on it in the future. Still, I got time enough to get some conclusions from it.
Coming from the Ruby world, using an FP mindset was difficult. At the beginning, not thinking in Ruby was hard, and I kept doing things in a very Ruby-esque way. At the end of the project I started identifying pieces of code that could be refactored to use the multipe definitions per method, for example. Switching the context is hard I guess.
I came to love some patterns too. As I said, I love Contexts and how they help you differentiate the persistance logic from the business logic, and it's something I've been missing in Rails for a while now.
I want to keep working on this project, and we already have some ideas on how to improve it, so expect more blogposts on the suject!
Photo by Dustin Lee.