For the past decade, my primary tool for building web apps has been Ruby on Rails. Using such a toolset helps me rapidly build apps with a predictable structure and the means to manage the database schema.
Of course, there are trade-offs when such things are used, but discussing those is out of scope of this post. Instead, I hope to focus on some positives that they provide.
In my opinion, web frameworks show their worth in the early stages of app development and the mid term when there is some developer churn. It aids both Current Developer (present day maintainers) and Future Developer (eventual project maintainers) by providing some safe assumptions about where things are and the general app flow.
Recently, I began exploring Elixir and shared my first impressions . Developing web apps in a manner similar to Rails naturally points to the Phoenix Framework, since the core team is influenced by it .
How Did I Learn?
To get familiar with the framework, I followed the Phoenix guides provided on the main site. It hits all of the highlights for typical project management including resource generation, database management, and app testing.
Here are my take aways…
A few of my favorite things…
In Active Record with Rails, details about the schema are “hidden knowledge” from the data model; the information is available in a separate database schema file. In Ecto, defining the schema inside the model exposes valuable information for Future Developer, providing the underlying makeup of the data model in line. Awesome!
Rather than executing any activity with the database directly through the data model, Ecto uses separate Repo modules to manage that activity. This is nice since it keeps the model isolated from database connectivity concerns, and instead leaves them focused strictly on data modeling.
Baked in support for channels allows any type of client to subscribe to Phoenix apps for “real time” data. With the BEAM managing large numbers of concurrent connections, the confidence level for a stable solution should be high.
This spec provides a good way to isolate behavior for reuse elsewhere that could be painless to test. Win!
Surprisingly, I encountered one thing that bothered me, but it is a big one.
I was very disappointed to learn that I need Node.js for the default static asset manager, Brunch. To be fair, this dependency is optional, and any build tool can be used. However, from what I have seen, the default tends to be favored in the wild by frameworks.
Now I am eager to put it to work to see it in action!