An Opinionated Walking Skeleton for Rails App Development

📅 29 Jan 2021 📍 North Kuta, Bali 🖊️

Introduction

With Rails, setting up a repository for a new project couldn’t be any simpler:

rails new unicorn-app

However, deployment is another story. It is notoriously more involved than the PHP counterpart. Either you need to have a familiarity with server configuration, or you pay a fortune to Heroku or similar services.

There are also some other stuff to keep in mind: like having TDD, monitoring for site reliability, linting and code reviews, etc.

Instead of setting those up after the fact (and find some unpleasant surprises), it’d be nice if we have all of the above at the ready on day one of the sprint, so we can focus on the actual work. We need a walking skeleton:

A walking skeleton, as described by Alistair Cockburn, is:

… a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.

Teaching the skeleton how to walk

Say you want to build an API for your mobile app. The skeleton would be a simple HTTP GET route and a controller which emits 200 OK response. You might also want to add a spec for that. Or maybe you want to build a full-stack app, in that case, create an erb for the home page. Maybe add a simple CSS and JS on top of that.

We have to make deployment first priority, this means you will encounter some chores like DB migration, RSpec run, and asset precompilation. Once we taught the skeleton how to walk, we can focus on adding some organs, circulatory system, respiratory system, nervous system, muscles, and so on and so forth. This way, we have figured out how the development and deployment process looks like from end to end.

My go-to walking skeleton

I have the opportunity of starting several Rails projects during my career. I’ve used Rails omakase, the Prime stack, and everything in between. I’ve also deployed Rails to different targets: bare metal, VPS, and PaaS (Heroku, Amazon Elastic Beanstalk, Google App Engine).

Now, thanks to amazing tools like Docker, I have a skeleton from which I can start a new project regardless of which cloud provider I will use, with next to no adjustment. I call it Rangka. A short for kerangka, an Indonesian word for skeleton. And here’s what you’ll get:

Testing toolbox

I’m not a TDD zealot, but testing is one of the basic necessities in web development. For this, I use RSpec exclusively. Minitest is not bad, but everybody seem to use RSpec despite it’s not omakase. Also, FactoryBot and Faker for generating test data.

Linting

I don’t want to be that person who bitch about how to properly indent your code, nor do I want to spend my time tweaking RuboCop config to my preference. I just automate this using StandardRB.

Error reporting

Sentry integration is included. I’m a big fan because there’s a free tier and it’s open source! Plus you get a pretty good APM.

Security

The following security tools and tricks are included:

Performance

The following tools and tricks for performance optimizations are included:

Usage

Rangka is available as a Rails template. Here’s how to use it: The template is under construction, it will be available soon in February. Hehehe. Too busy, maybe later.

# To start a new Rails project
rails new the_next_unicorn -m https://raw.githubusercontent.com/ukazap/rangka/main/template.rb

# To apply to an existing Rails project
rails app:template LOCATION=https://raw.githubusercontent.com/ukazap/rangka/main/template.rb

Summary (and ToDo)

Well, yes, it doesn’t come close to the mythical Active Deployment. But it’s a good start and it covers my basic needs for now: I can write and run my spec. I have sane defaults for request rate limiting and making sure the staging environment won’t appear on search engine results, my code is linted and scanned, and my app performance is being monitored.

There are some stuff that may be included in Rangka in the future, such as:

  • Auth/auth gems. But I’m not really sure because there’s no one size fits all, but I might include it anyways because I added opinionated in the description.
  • A controller for custom error pages (404, 500) also came to mind.
  • Maybe throw in data migration as well. Or maybe not, use db/seeds.rb all the way.

I will revisit this article to keep you posted. Please leave your thoughts in the comment section and if you’re interested, the repository is here. Again, it’s under construction. Hehehe.