Some other truths about Ruby on Rails
Aron pointed me to Josh Kenzer’s interview last month with Twitter Developer Alex Payne. The newsworthy bit is that Alex states that Rails applications don’t scale well:
Running on Rails has forced us to deal with scaling issues – issues that any growing site eventually contends with – far sooner than I think we would on another framework.
We’ve actually been told this a lot by Rails folks. Hopefully, someday the demand for Spotstory will be so great that we’ll have some first hand knowledge on the matter!
Having said that, there are already a couple of areas where we’ve already bumped into issues while using Rails.
Issue 1: Fixtures break down
A single set of fixture data just breaks down after you’ve created a certain number of tests. I’ve talked about this before and it’s what caused us to create Isolated Fixtures. So, we innovated our way around that.
Issue 2: The trap of CRUD-is-King
This is an issue we’ve encountered in the past couple of months, and a lot of what we’re doing now is geared towards ameliorating this condition. But first I should probably explain what I’m talking about!
Rails lets you get a lot done quickly in the sense that you create a model, lots of code gets created generated, and you start seeing features work almost immediately. Awesome!
Now, everyone warns you that you’ll throw away a lot of this generated code, and you do. You refactor something here, change the presentation of something there, and you think you’re pretty much done.
But you’re not. Because what you’ve done (at least in our case) is expose features in a way that makes sense in terms of pure CRUD, but it has little to do with how regular people think about doing what they want to do.
I think what I’m trying to say is this: since so much of the application is automatically derived from the data model, the interface you end up exposing is tied to closely to the data model.
Maybe if we were more skilled designers we wouldn’t have gotten ourselves into this situation. Perhaps we needed a better design methodology.
Also, I concede that Rails doesn’t force you to do this, or keep you from fixing the problem. This is not the end of the world. Very likely, this is also a problem in other frameworks.
But Rails’ CRUD-is-king mindset does do a lot to steer you down this path. Again, I’m not saying this is a reason to not use Rails, just pointing out our own experience.
In closing
In closing, we’re happy with Rails and Ruby. But we also understand that they’re tools, and all tools have their limitations.
I hope we’re not excommunicated from the Ruby on Rails community for this! :)
No comments

