Ruby on Rails

We build with Rails when a system needs per-user state: accounts, permissions, dashboards, transactions, anything where two visitors must see different pages. It is what we use once a static site is no longer enough.

Why we still choose it

In 2004 Rails bet that a single, opinionated, well-documented framework would beat an assembled stack, and twenty years on the bet has paid off. One repository holds the models, views, background jobs, mailers and migrations. A new engineer knows where things live before reading anything, because they live where Rails says they do.

What we usually replace is an architecture of six services that exist because a conference talk suggested them. That shape has real costs, including distributed transactions, six deployment pipelines and tracing to find out where a request went, and it buys nothing for an organisation serving a few hundred requests per second.

Rails has also kept up with a decade of front-end fashion without forcing its users to. Hotwire and Turbo give a responsive interface with server-side rendering, so you keep one language and one deployment and have no separate front-end build to maintain.

How we run it

On NixOS, with PostgreSQL, behind nginx, on European hosting. The Ruby version, the gems and the system dependencies are declared in the same repository as the application, so a new machine or a rollback takes one command.

Where it falls short

If you need to serve very high request volumes on a small budget, or you have a CPU-bound core, Rails is not the cheapest way to do it. It is often the cheapest way to get a correct system that a small team can still maintain in year four, which is the constraint most organisations are under.