Note: this is from the spring of 2008, thus ancient in rails land.
(The title for this probably isn't as good as it should be, I cannot think of a better one)
I am about to revisit a startup idea and my platform of choice is Ruby on Rails. I've also recently started re-reading the book "Enterprise Rails" which suggests that you do not follow the Rails default conventions but instead separate out your layers into "physical" and "logical" components. This is the only book I have yet to see where this opinion is expressed; every other Rails book seems to just follow the "convention over configuration" mantra. In short the book suggestions you divide your app/ folder into the following:
- app/models/physical (used for the actual .rb model files)
- app/models/logical (used for web service APIs I believe)
and do the same with your controllers and other areas of the app. The book also advises not to use database migrations at all but use raw SQL scripts (and later on makes use of using SQL views and functions) under a separate folder that doesn't adhere to the Rails norm.
My question is whether or not I should worry about these things if I am just beginning to develop my application. Obviously the book advises that I do to avoid possible problems down the road, and the .NET developer in me wants to agree, but the Rails developer in me (still an infant) is telling me to just follow the "Rails Way" 100% since I'm still learning the framework and the Ruby language. I wonder how many successful Rails apps actually just follow the norm with all the models in app/models, all the controllers in app/controllers without any further segregation, and how many do some kind of "enterprise-y" architecture?
Best Answer
If you're just learning Rails, I'd go with the Rails way ("When in Rome, ..."). If you're worried that your startup may falter due to scalability issues down the road, I'd suggest you revisit your decision to use RoR. Solving scalability problems is hard enough in an environment you know well, you don't want to struggle with an unfamiliar one when you're under the gun. (Note that this isn't particular to Ruby, it's just as applicable to Python, Scala, Perl, C++ or any other language you don't know...)