It’s getting close to 20 years since the emergence of Ruby on Rails, and it’s still a framework that is effective for what it’s good for. What exactly is it good for? Rails has a sweet spot for building database-backed web applications where app development speed, maintenance, and the handling of fuzzy or rapidly changing requirements are important.
This is still a pretty broad description and a rule of thumb I’ve developed to gauge how suitable Rails is for any given application to measure how close or far the application is from particular benchmark applications. The benchmark applications are Basecamp, Shopify, and Github.
These are the “Big 3” of the Ruby and Rails world. All three found success by leveraging the benefits of Rails to get to market quickly, and all three remain dominant in their particular market with a track record that is also getting close to 20 years. The Big 3 have a heavy hand in setting the present and future direction of Ruby, the programming language, and Rails, the web development framework. All of them have core team members who contribute to building the fundamental building blocks of the greater Ruby community.
Basecamp is the Ruby on Rails benchmark app
The origin story of Rails begins with David Heinemeier Hansson building the first version of Basecamp at 37 Signals in 2004. He chose to use Ruby a not very well-known language and from the initial construction of Basecamp, Ruby on Rails the general web development framework written in Ruby was extracted. Not only was the programming language unusual but the creation of a web framework by extracting it from a real-world application was then and probably still is now very unusual. Most frameworks get their start from big corporate committees that build the frameworks by deciding on what a framework needs according to theory and experience rather than pulling from what already exists.
Hansson (referred to as DHH) is often described by the moniker “benevolent dictator for life” as the direction of Rails has been firmly guided by his opinions on what the framework is and just as importantly what it isn’t. Understanding where DHH is at in terms of his opinions on building software informs what direction Rails will be heading in the future.
...a good measure of how well a fit Rails is for a particular application is to compare how close it is to Basecamp
Rails to this day can probably be described as an extraction of Basecamp and so a good measure of how well a fit Rails is for a particular application is to look at Basecamp and judge how close the application is to the project management software of 37 Signals. If your application is a mostly CRUD, database-backed, web application then it’s probably a good fit. If high concurrency real-time is the core of the app, maybe not so much. Rails has a broad application because most of the web tends to be plain old CRUD apps of one sort or another.
Github is Rails at a massive scale playing nice with other technologies
The adoption of git got its start in the Ruby community and GitHub emerged from the same community as the dominant git hosting service to this day. The GitHub Ruby on Rails monolith is big: nearly two million lines of code and more than 1,000 engineers collaborating on it, to the tune of around 20 deployments every day. GitHub has become a benchmark for Rails applications that are at a massive scale. The trick to scaling Rails is to not use Rails for everything. GitHub uses Rails for what it’s good for and uses other technologies for what Rails isn’t good for. The GitHub engineering blog is a treasure trove of information on how they’ve managed to scale Rails to the size of their application, and it involves mixing in a lot of other technologies. The code search backend is a search engine they built using Rust and the front end is React embedded on top of the Rails served pages. Another interesting aspect of GitHub is that they built a Rails app on top of a file system. Git is essentially a file system with pointers and Github is a Rails app that sits on top of that file system. This is a very interesting way to think about how to build a Rails app and it’s a good example of how to use Rails for what it’s good for and use other technologies for what Rails isn’t good for.
Sources:
Github blog describing the Ruby on Rails monolith
Github blog describing the creation of the code search backend in Rust