Reputation: 111

How do can I implement Modularization in a Rails App?

Breaking a large rails app into smaller apps?

Best practice for structuring a 'large' Rails app

I have a quick question on modularization in a large Ruby on Rails App.

Setup:

I am building a core app that stores information about people. I also have several 'modules' that use that information in very different ways. (e.g. one could display information about the people, another could figure out connections and commonalities between them, etc).

The question:

How do I modularize this app efficiently?

Potential Answers:

Since the modules share models and views with the core app (and eachother) it makes sense for me to combine them into one app. However, as the app grows this will obviously lead to problems. This to me suggests either Namespacing the controllers and models "How to organize controller in moderately large Rails application?" or using engines "Modularizing Rails applications".

Since the modules are in active development it is very helpful to use rails generators on them, which seems to make using Engines a pain in the butt. It also seems that while engines are fully supported from a Rails point of view, they still seem rather hacky with regard to lack of generator support and database migrations. Does anyone have experience with developing engines successfully? It seems like engines would be a great solution if you had a working app and wanted to port it into a plugin (i.e. copy paste code) but if you are actively developing it (changing models etc) it would be difficult.

The last thing I have seen around is using multiple apps and one database. This way seems like a royal pain with migrations and keeping models straight etc etc. But I thought I would get thoughts on that as well.

Upvotes: 11

Answers (5)

Nerian

Reputation: 16177

I wouldn't use engines. Engines are meant to be used to share functionality between apps. What you want to do is not to share functionality but to organise it.

In order to organise your code you can do a lot of things.

Use namespaces.
Keep your controllers thin.
Keep your models thin (Yes, your models; see next bullet point)
Use the Data Context Interaction (DCI) pattern.
Use a widget framework like Apotomo, or Cells.
Write tests, so you can refactor.
Consider a Service Oriented Architecture(Consider Hypermedia API design) if your app's responsability grows too much.

Andrzej has very good articles about DCI.

http://andrzejonsoftware.blogspot.com/2011/08/dci-patterns-how-to-write-dci-contexts.html

Upvotes: 1

Martin T.

Reputation: 3222

Depending on the structure of the data, and access patterns, it might be useful to separate the app into multiple apps, and possibly, additionally, provide data access by (RESTful) APIs.

In my experience, this allows for the best structures when your application(s) grow from middle to large size, and forces you to think about structures and separation of concern. Scaling up is also usually easier.

Upvotes: 0

ghr

Reputation: 647

You can also use Rack Middleware to handle specific tasks.

For the bulk of your application, Engines seem like the best solution – it's something I'm looking at doing too. Looks like you can define generators in the Engine easily enough.

Upvotes: 0