CODEWITHSUNDEEP
ruby-on-railsrubydesign-patterns
Amer
Amer

Reputation: 2017

What to do when a rails application become too big?

I'm dealing with a rails application which is growing too big. It takes long time to start and lots of memory. We are having performance issues. Tests are very slow. Managing the codebase, debugging and introducing new futures becoming harder everyday. We are thinking to split the application into smaller components (Rails engines or different Rails apps) where all components will share a single database. Considering such scenario we will need to share the models, maybe some libs, tests, and some gems, etc... It doesn't sound right for me!

Is there any pattern can be applied?

Upvotes: 2

Views: 1061

Answers (3)

Jonah
Jonah

Reputation: 17958

There are some great suggestions here about to to split up a Rails code base however I think that before you apply any of then you need to stop and seriously consider how you got into this position. All of these solutions introduce new complexities and challenges. They might be worthwhile trade offs but only if you make sure they also solve a problem you have today.

Take each of the pain points you listed (startup time is slow, memory use if high, performance is poor, rest performance is poor, development speed is slow) and run a "5 whys" exercise on them. Why are these things happening. Why did the app get into this state.

Most importantly before you commit to any plan for splitting up a large app consider if the app should be large in the first place. If your app is more complex than your product demands then switching to an equally complex cluster of services is not an improvement.

More concretely I would recommend against shared database access between apps/services/whatever. A shared database has a shared schema which becomes fragile. It also leads to tightly coupled services which lack the separation of concerns you need to see any improvement in your pace of development. Just as splitting one massive class into several tightly coupled files does not improve it nor does splitting one app into coupled services. If you must maintain a large app you need to isolate separate concerns. In order to do so you need to break the dependencies between them. Based on the efforts I have seen to repair Rails monoliths you'll have better success creating clean interface within your existing app an then splitting out components than if you split the app apart and then hope the resulting pieces can be improved independently.

Upvotes: 4

seph
seph

Reputation: 6076

Read "Practical Object Oriented Design in Ruby" by Sandi Metz. Also, watch every presentation and talk by her on the internet. Youtube is a great place to start. She's a great speaker. Rails is written in Ruby and Ruby is an object oriented language which brings with it massive benefits. But grokking the object oriented part takes a little work. Sandi will get you there.

Upvotes: 1

mvidaurre
mvidaurre

Reputation: 489

Yes, there are several ways to do it:

  1. Micro services Erin Swenson-Healey has a nice post for rails.
  2. Hexagonal Architecture GoRuCo 2012 Hexagonal Rails by Matt Wynne and Refactoring with Hexagonal Rails
  3. Rails Engines Approach. Dealing with Rails Application Complexity - A Report from MWRC
  4. Use other framework more suitable for high complexity and more PORO oriented. http://lotusrb.org/

Also see Ruby Midwest 2011 - Keynote: Architecture the Lost Years by Robert Martin

Upvotes: 2

Related Questions