Staying close to Rails’ conventions

Part 1 (re: Architectural Decisions) I was recently asked about the architectural decisions we’ve made in our most recent Ruby on Rails project (an e-commerce platform for sports apparel decoration).

We decided to stay close to Rails’ conventions as much as possible. This allowed the team to build out the first features quickly. This is usually not a problem for short-term projects, but it becomes a maintenance burden after a year, because after a year the team is also concerned about supporting what they’ve built despite changes to team structure or project focus.

Project-specific conventions

In some areas where Ruby on Rails has no opinion, we’ve established our conventions:

  1. Using service classes (and using LightService)
  2. Using namespaces to partition functionality (e.g., Dealers, Admin, Checkouts)
  3. Avoiding the use of JavaScript-heavy frameworks (e.g., VueJS) in favor of Stimulus and HTML-over-the-wire (this was done pre-Hotwire)
  4. Prefer application events over ActiveRecord callbacks when triggering jobs
  5. Adopting Spree as the e-commerce engine instead of building from scratch

Conventions distilled into pattern

We also wanted to make it easy for a new developer to understand how a feature was built and where to make subsequent changes. Having these patterns in place and adopted across the entire codebase also helps the maintainers to troubleshoot issues two years after a feature has been deployed to production.

Leave a Comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s