Sustainable Ruby on Rails in 2024
Reading time: 3 min.
Rubu on Rails development changes a lot every year and sometimes it's not easy to keep up with the changes.
I've recently bought Sustainable Rails Book and it's hard to overestimate how valuable is it for me.
Here are couple of thoughts after reading first chapters.
- Invest in developer friendly application bootstrap process. Running bin/setup and bin/dev should be enough to run on the new blank developer machine.
- Move business logic out of fat controllers and fat models. Extract it and move to Service Objects. Fan-in and fan-out is a fancy metrics to estimate how object relate to each other. Simply speaking the most referred dependencies should be simple enough and thoroughly tested.
- Keep routing.rb as canonical as possible. Avoid nesting routes whenever the resources don't represent tight coupling. Rely on resources instead of custom crafter routes. Tip: use :only [:create] to reduce the scope.
CI/CD process
Dare to add, invest heavily in CI/CD process, with modern GitHub offering it's just way easier then maintaining own on-prem solution.
At the moment I've shifted from own Drone.io and Jenkins to GitHub Actions and self-hosted runner for Continuous Integration and to Hashicorp Nomad for Continuous Deployment.
I'll try to carve up time to describe a bit more the process of deployment.
Security
I've added the following gems:
- brakeman
- bundle-audit
And enjoy output of the audit.
Local setup
My setup is quite complicated, Rails application requires:
- MySQL server
- Redis
- Resque + Resque Web UI
- Sphinx with Thinking Sphinx gem for full-text search
- Custom built server for server sent events (something similar to Action Cable)
bin/dev uses Procfile to bring up web server workers, search daemon and Resque UI.
bin/setup creates blank database and populates with seeds, so the app is ready to run after this step.
Devcontainers
I've also tested devcontainers and they work quite good with VSCode.
Unfortunately for Emacs I found several downsides, namely
- It's hard to integrate with rubocop
- Hard to jump into container, as it requires PATH setup, and eshell doesn't shine here
- chruby that I use instead of rbenv doesn't work
I also admit, VSCode brings some extra nifties not available or hard to implement in Emacs, like GitHub Actions integration.
It's hard to switch fully from Emacs to VSCode and I keep using both for different use cases.
IDEs
I'm mostly using Emacs, but VSCode recently is on the table as well. Both have their strong sides.
Emacs
Git in Emacs - Magit still bringe unbeatable git experience. org-mode is a thing, almost jupyther labs for the supported languages.
VSCode
Though, VSCode integration with GitHub Actions and LSP with Rubocop and Ruby makes development more joyful.
- Devcontainer support is a small miracle.
- Command pallete mimics Meta-X functionality from Emacs.
