It is seemingly impossible to talk about Ruby without talking about Rails, and this article will not be the exception. This web framework has had a both terrific and terrible (some would say oversized) influence in the past 20 years, and has, against all odds, regained interest in a world of microservices, DevOps engineers, containers, and Kubernetes clusters. Rails has been able to adapt to the unknown, from the burgeoning cloud services of 2005 to the latest fads, but always gathering a chorus of frowning eyes around the “magic” it uses and enables.
Precisely, let us talk about the magic of Rails. Some would say there is not enough, many swear there is far too much. Some argue that it makes it very hard to create fast code, some argue that time-to-market is a better measure of productivity.
The jury is still out, but one thing is sure: Rails broke havoc in a world of endless Tomcat XML configuration files, boilerplate code only for infrastructure purposes, long build times, and even longer deployment cycles. It provided a valid answer to the eternal problem of the impossible dialogue between tech and business.
Twenty years ago, the possibility of a new approach for web applications was long overdue. Rails happened precisely at a time when the word “Agile” was starting to become mainstream; talk about being at the right time at the right moment. Even Apple noticed, publishing an article about it in its now-extinct “Apple Developer Connection” website; the parallels and similarities between Rails and WebObjects were too obvious to ignore (and there was a lot of cash to be made selling MacBooks to enthusiast Rails developers).
The Rails craze started one day, with a young developer conducting a live demo in Brazil, in which he crafted a rudimentary yet complete blog engine in just a few minutes (you have no idea how much uttering the previous sentence was science fiction in 2005). The recording of that session is still around (arguably, one of the oldest videos available on YouTube), and apart from the annoyingly high-pitched voice of the author and the low quality of the audio, is quite impressive even by today’s standards.
But we are not going to talk about the creator of Rails, who has been getting a (definitely this time) oversized amount of attention during the past 20 years, a fact that has irremediably altered his ego and hubris beyond repair. (However, for those still interested in the story of how Rails came to be, there is a CultRepo documentary online you might enjoy.)
Instead, this month we are going to look elsewhere for wonder. Enter Eileen Uchitelle, senior software engineer at Shopify and member of the Rails core team at the time of the video, who delivered this month’s Vidéothèque entry around 2 years ago, as a closing keynote at the first Rails World conference of 2023, titled “The Magic of Rails”, exploring the philosophy, architecture, and technical patterns at work behind the curtains of Rails.
Regarding its philosophy, Ms Uchitelle states that Rails is modular by design, yet remains cohesive by default. Once again, that old tension between coupling and cohesion, which some of you might remember from computer science classes, is more than ever of importance in these days of containers and microservices.
The current architecture of Rails allows developers to use specific components without the entire framework, something that was not entirely possible in the first releases, as those with good memory will remember. Not only that, but Rails uses a lot of agnostic interfaces, for example making swapping databases seamless. Rails’ ORM, called “Active Record” in a clear nod to Martin Fowler’s pattern of the same name, providing a simple save method to INSERT or UPDATE objects on a relational database, was quite a sight back in the day. The same idea was then extended to many other segments of the framework, like the Active Storage system, providing abstractions for various types of file systems with an identical API. In other words, by employing abstract classes, Rails creates agnostic interfaces for databases and storage services, forcing concrete adapters to implement specific behaviors.
On the technical side of things, Ms Uchitelle explains that Rails is composed of 12 distinct gems, with a component called “Railties” acting as the glue that binds them together. She detailed how the framework uses initializers and load hooks to manage boot order and lazy configuration.
But what about the magic itself? Well, it is all about metaprogramming. This big word is Latin for “dynamically generating methods at runtime”. Now that is what I call magic, like model objects suddenly getting methods that include names of other models, all linked together through foreign keys in the underlying database. “Give me all the patients of Dr. Smith” now becomes a simple call to @smith.patients, a method seemingly coming out of nowhere. Why is that? Well,
class Doctor < ApplicationRecord
has_many :patients
end
And even better, you can go from a single patient to its doctor. You get the idea. (By the way, if metaprogramming sounds appealing, Graham has written an article in this edition that you will surely find interesting.)
Ms Uchitelle concludes her talk throwing well-deserved kudos and flowers to the huge community of users and maintainers who support Rails day after day.
Speaking about the Rails community, it would be unfair to end this article without a big shoutout to all those voices that have contributed to the growth and the development of both Ruby and Rails in the past two decades. Suffice to mention Linda Liukas (creator of the awesome “Hello Ruby”) website, Sandi Metz, Nadia Odunayo, Katrina Owen (co-creator of Exercism), Aaron Patterson (who gave the closing keynote at the last Rails World conference), and Gary Bernhardt, among so many others.
Watch this month’s Vidéothèque entry, the keynote at Rails World 2023 titled “The Magic of Rails” by Eileen Uchitelle, on YouTube.
Cover snapshot chosen by the author.