The best of Rails in Phoenix (part 2)

SeriesPhoenix on Rails clock3 min read

Once again, I'm presenting good parts of Rails waiting in Phoenix for those that transition between the two.

« Read part 1

Data layer

Almost every app has some data to store. Without a doubt, one of reasons for Rails popularity is ActiveRecord's ease of use and the ability to just jump in and start adding models and saving records. Phoenix follows the same route and offers Ecto, an integrated and ready to use data persistence library. There are important differences between the two, so I can easily see a separate comparison article coming, but the basic principle holds.

One important thing that ActiveRecord and Ecto have in common is migrations. Just like in Rails, you get a DSL that allows to write and apply them. And they are automatically reversible, too.


Phoenix projects, like all Elixir apps, take advantage of Mix ecosystem in order to manage dependencies. It allows to list all deps in one place and to install them with just one command. Like in Gemfile, each dependency in mix.exs can be scoped to specific environment (like database factory only for use in test env).

Just like with Rails and bundler, Mix dependencies are locked to specific version after getting installed, so you can be sure that everyone in the project uses exactly the same version of each package. And that production deployment won't bring any surprises in that department.


By default, Phoenix uses EEx for view templating. This is a straight equivalent of ERb, so brace yourself for a lot of good old <%= "interpolations" %> in your templates.

If you're a fan of indented syntax instead, you can grab working template engines for HAML and Slim from Mix. I have used Slime (Elixir's flavor of Slim) and, although there are some early age issues that you may stumble upon, it's working pretty good overall.


For those in a hurry, Phoenix has generators for models, migrations and whole resources (aka. scaffolds). While scaffold generation may be something used more by newcomers, generating models and migrations is something done routinely by everyone. Look at this:

mix phoenix.gen.model Article articles title \
                                       content:text \
                                       slug:unique \

Looks familiar? That's all it takes to add a new model to the app. Run mix ecto.migrate afterwards and you're good to go. You can also see here that Phoenix, opposite to Rails, doesn't get its hands dirty with pluralization and you have to pass the table name yourself.


Phoenix includes a built-in solution for I18n just like Rails. Phoenix 1.1 however replaced the key-value locale store, similar to the one in Rails, and gettext became the default backend for translating apps. It's a well known and rich tooled solution that gets more and more popular among Rails developers these days, too.

Once again, I'm not after comparisons here, but you can learn more about Phoenix and gettext vs key-value locale store in this excellent article


Like in part 1, you can see how similar the philosophy behind Phoenix is to the one that made Rails so universal and easy to approach. The framework aims to include all essential web development pieces. It doesn't hesitate not just to borrow good ideas from Rails, but also to learn on Rails past experiences and mistakes (asset pipeline, i18n).