← All Posts

The problem with your large Rails app isn't Rails

Neat ball of string
Credit: Philip Estrada

Rails often receives the blame for the mess as codebases grow, it's quite shameful, but it's understandable, given it's easier to jump on the bandwagon, than addressing one's own technical debt and poor decisions.

We've all ended up there, but the reality is that no framework will save us from ourselves whilst providing the productivity and freedom we currently enjoy. You've got to choose:

Be mature when handling sharp knifes or stick to playing with Duplo.

My suggestion? Commit to Rails, quit your whining and deal with the technical debt – then you've only got your existing problem to solve and avoiding just repeating the same (or new) mistakes in a different language or framework all over again.

Okay, so you want some more 'practical' advice

Before we get started, I'm not going to run you through the usual spiel. I'm going to assume you know all about service objects, decorators and repositories, yet you've still experienced problems. Know this: patterns won't solve everything, but that's a discussion for another day.

An atypical suggestion

Over the past ~10 years, I've worked on a plethora of large Rails applications, many of which I'll openly admit ended up in a mess and required significant TLC. But how did we get here? It all started off so well?

We all know Rails is opinionated, as is any other framework, library or indeed developer.

At the start of a project, there are just two entities in the conversation – Rails and your team, 2 sets of opinions, and you're both willing to concede a little to some things you may not fully agree with.

The trouble is, pretty promptly, we start expanding our social group, in the guise of Ruby gems, and those opinions, assumptions and expectations start to clash. You start having to do more and more work to keep everyone happy and bridge the gaps between those not seeing eye-to-eye. This is particularly no fun if they're all wielding those sharp Rails knives!

We have to recognise, there is a huge productivity benefit from having someone else do our work for us, but at a certain point those early productivity benefits are outweighed by the hassle caused by clashes.

Am I suggesting you avoid Ruby gems altogether? Absolutely not – but each time you want to use one, just evaluate whether it's the right thing to do:

  • Is this a tiny abstraction that you could easily build yourself?
  • Does the gem do more than you need – is there going to be temptation for it to be abused for more than you intended?
  • Is the gem simply an isolated Ruby library or is it toying with the 'magic' of Rails?

If you start to take ownership over your project and reduce the more heavy-handed dependencies, you'll gain predictability, meaning productivity and maintainability will increase and work will start to feel more like fresh out-of-the-box Rails again.

Photo of Ryan

Hi, I'm Ryan.

I have been working with the web for 15 years, and I'm currently CTO of Shift Commerce, a SaaS ecommerce platform bringing agility to mid-to-enterprise businesses.

Running a conference? I'd love to speak — see my speaking page for more.