As Brian points out :
In terms of the Gartner Hype Cycle, Ruby and Rails are nearing the end of the "Peak of Inflated Expectations" and are moving into the "Trough of Disillusionment".
It's indeed true that Rails have enjoyed the limelight of being the darling of the community and a promise (or panacea) to put an end to the verbosity and *inelegance* of Java based Web development. It has been quite some time though, yet we hear people like Obie utter the following in the context of choosing Java over Rails in developing Big Enterprise Applications :
Like Gavin pointed out, you can't do an app with thousands of model classes in Rails. Okay, but I'm really not trying to say that you should try. Right now, I personally have no interest in working on those kinds of monstrosities, but to each his own. If that big enterprise application exposed web interfaces, I might be inclined to use JRuby on Rails to do those..
It's time to deliver for Rails ! How long will Rails shrug away from the enterprise applications branding them as monstrous ? It's time to take Rails out of the playful scaffolding model that delivers basic CRUD applications at lightening speed. To deliver complex enterprise applications, you need a performant application server with production quality deployment support, a real fast virtual machine and solid domain modeling capabilities. We all know the ActiveRecord model is never going to scale up for large complex domain models. The Rails community, till now, do not acknowledge how important it is to have a separate domain model, decoupled (or loosely coupled) with the persistence layer. And ActiveRecord will never take you towards that end. How much strong metaprogramming capabilities you may use to offer fancy dynamic finders in Rails, ultimately you need to have a strong decoupled domain model to deliver big enterprise applications. Till then, I guess, JRuby will be your best bet and Rails will remain just another Java library sucked up within a Java application server.
21 comments:
I just realized it: "easy to develop simple (CRUD) applications", "ActiveRecord", "(almost) no domain model"... it reminds me of VisualBasic and Datagrids... is Rails trying to compete against Microsoft? :-D
As long as you still believe that you need to build "large complex domain models" and "deliver big enterprise applications", then you aren't ready for Rails.
For some enterprise apps that have to build on legacy systems or legacy databases, those characteristics may be unavoidable. And those apps are probably not suited to Rails.
But if you can get out of the mindset that enterprise apps must be huge and complex, then you may find that you can satisfy your business requirements with a fraction of the effort and cost using Rails.
Two questions:
1. How do you define "large complex domain model"? What makes a model "large" or "complex"?
2. Why is it important to separate the persistence layer from the domain model? What is the downside to combining them, and what is the benefit of separation?
I have my ideas about these, but I'm curious what your arguments are.
"How long will Rails shrug away from the enterprise applications branding them as monstrous ?"
As long as it wants.
As much as some people are just now getting tired of what they call "Rails fanboy-ism", I'm getting tired of "enterprise" as being the be-all and end-all. There are only 500 firms in the Fortune 500, hiring a small percentage of the workforce. There are hundreds of thousands of small businesses in the US, millions more worldwide, that can't afford and probably don't need what typically gets labeled "enterprise".
If Rails never gets to the point of being considered "enterprise-worthy", so be it. All us non-enterprises will be happy for tools that meet our needs, rather than yours.
Show me an "enterprise application" that requires a thousand models and I might start to believe some of the sputum that is spewed forth from these Rails haters.
@jeremy:
1. A complex domain model is one which is big in terms of the number of entities as well as the relationships between them. Any typical enterprise application like back-office solutions for financial markets, investment bankings etc. qualify for being a complex enough domain model. I have been working on a back office trading and settlement solution, that has 600+ entities and a huge domain model.
2. Separation of concerns. The main advantage is that your data model and domain model can evolve independently with very loose coupling between them. The ActiveRecord model does not allow such separation.
@radarlistender: There are plenty of examples. Typical ones come from the financial domain - any back office solution can be as large as having thousands of entities. See my last comment.
The quantity of entities in the model doesn't make it more complex. And there are only so many types of relationships (one-to-one, one-to-many, many-to-many), and just about any domain has examples of each. It might be harder to keep 600 entities straight in your head than 10, but I wouldn't argue that it's that much more complex.
As far as separation of concerns, if you have a framework that makes one of the concerns all but transparent, why does it need to be separated? ActiveRecord is a DSL for relational models -- I would argue that an entity's relationships to other entities is part of the domain and business logic.
The important thing is that this is in the model layer -- whether you separate persistence from business logic doesn't matter, it's still in the model (or should be). Separation of concerns is much more important when you're talking about business logic in views or controllers.
ActiveRecord is a DSL for relational models -- I would argue that an entity's relationships to other entities is part of the domain and business logic.
Do u seriously think that it is possible to maintain a Rails application consisting of a large number of entities sucked up with a tightly coupled relational ActiveRecord model and laced with APIs that offer no type checking ? I think this is where a separate domain model, decoupled from the persistence layer matters with the safety net of static type checking.
Yes, it's possible. Why not? The persistence and business aspects may be tightly-coupled, but the persistence part is mostly transparent. Besides, what would be the benefit of decoupling them? In Java it's a common practice to be able to unit test business logic in isolation from CRUD, but that's not a concern with Ruby.
I believe that the complexity of a domain scales linearly in proportion to its size. What I mean is that a larger domain may be more complex in that it has more entities and more relationships, but it doesn't get exponentially or logarithmically more complicated with size.
The static vs dynamic typing argument is separate. Static typing has benefits, but so does dynamic/duck typing. In practice, dynamic typing doesn't bite you as often as you might think. To put it in a pure Java analogy, consider how often (read: rarely) you put the wrong kind of object into a Java 1.4 collection and got a ClassCastException when getting it out. It's just not that big of a deal (but we ended up with generics anyway).
The safety net is unit tests, not static type checking. You do write unit tests for Java apps, right? You would for Ruby apps too.
"But if you can get out of the mindset that enterprise apps must be huge and complex, then you may find that you can satisfy your business requirements with a fraction of the effort and cost using Rails."
Absurd.
"In practice, dynamic typing doesn't bite you as often as you might think. To put it in a pure Java analogy, consider how often (read: rarely) you put the wrong kind of object into a Java 1.4 collection and got a ClassCastException when getting it out. It's just not that big of a deal (but we ended up with generics anyway)."
Java is only statically typed to a degree; ClassCastExceptions and NullPointerExceptions are a problem, because now you have a language without strong runtime safely guarantees, but one that nevertheless has the drawbacks of static typing (more complex semantics, verbose without inference, ...)
I think modern static type systems (ML, Haskell, ...) are competitive with dynamic typing when it comes to conciseness and expressiveness, though.
@jeremy:
"The persistence and business aspects may be tightly-coupled, but the persistence part is mostly transparent."
With ActiveRecord in Rails, you are coupling a relational persistence model with an OO domain model. That way your domain model is a mere replication of the way things persist in the database. This approach is easy to implement with small models, but simply goes out of bounds with large and complex ones, where domain entities interact with each other through rich behavior, which are best modeled using OO abstractions.
And, if the Rails model of working with domain scales well, why do all the Rails evangelists still shirk away from big enterprise applications branding them as *monstrous* ? My main point of the post was that how long will Rails stay away from complex domain modeling ? Is it because they know that the technology they evangelize so much is not able to handle the monster ?
Nice blog.....thanks for the info....... Web 2.0 approach to enterprise application development is the first factor that makes our applications bring about a SEA-change.
Regards,
Rosy.
------------------
http://www.axaya.net
"why do all the Rails evangelists still shirk away from big enterprise applications branding them as *monstrous* ?"
Another generalization that just isn't true.
Sure, many Rails evangelists shirk away from enterprise apps, but how many do so because they don't want to deal with the overhead of enterprise clients, or prefer to work on shorter-term projects, or any number of other perfectly valid reasons other than "Rails can't do it"?
There are Rails evangelists who would be perfectly happy to use Rails in an enterprise project. ThoughtWorks is leading the pack -- Mingle is geared towards the enterprise. The whole JRuby movement is making it easier to integrate Rails into the enterprise. There *are* enterprise projects going on with Rails.
There are reasons not to go into the enterprise. One is legacy databases, which I admit Rails/ActiveRecord isn't set up to handle, because a legacy database probably wasn't built around the conventions that ActiveRecord largely depends on. It's possible to solve these problems with Rails -- you don't *have* to use ActiveRecord, after all -- but it's usually just not worth it. USE THE RIGHT TOOL FOR THE JOB.
"The whole JRuby movement is making it easier to integrate Rails into the enterprise."
I agree and I have mentioned in my blog also. JRuby is the best bet with Rails for the enterprise. However, the unfortunate part is, in absence of a scalable deployment process, a performant virtual machine, JRuby still is just another jar sucked up in the JVM.
The least thing you want with your rich business domain model is to tie it to a particular persistence mechanism, is shooting yourself in the foot. You are building a model hoping to reuse it across many applications and then, tying it to a particular database structure... a big no-no in my book. (of course, my book could be different than yours) :-)
@Debasish,
Funny I ran into this one right after reading Weiqi Gao's post discussing the lack of static typing in ruby - and an earlier piece, The End of The Ruby Hype. I for one agree with the points made by both of you. RoR's difficulty to scale manifests on more than one level. The completely dynamic nature of the language tends to compound the complexity of the application, and turns it into the worse nightmare in any development team of decent size and attrition rate.
"The completely dynamic nature of the language tends to compound the complexity of the application, and turns it into the worse nightmare in any development team of decent size and attrition rate."
+1. It is very difficult to scale up a development team programming in dynamic language. I have mentioned this earlier also and has been dismissed as the strawman argument by Ruby fanboys.
However, in this post, my main argument is NOT Ruby. It is Rails and the main issue which I have is that the Rails community always dismiss enterprise apps as something not worth their consideration in their forte. But they do not admit that the basic design of Rails along with Active Record model and a coupled domain-persistence paradigm never enable them to go beyond a handful of entities. Some of them point to JRuby as the solution, which unfortunately is nothing for than a jar in a Java app server, given the pathetic state of Rails deployment.
I really don't understand why you think it's harder to scale up a development team in a dynamic language. Do you have any evidence, or even any anecdotal experience, to back this up? I understand that concern that explicit typing provides a certain amount of documentation-in-code, but that has its own costs, and doesn't always tell the whole story, and I just don't think it's as significant as you seem to.
I'm someone who worked with statically-typed languages for over 10 years and switched to a Rails project consisting of tens of thousands of lines of code (plus tests), and I didn't have much trouble getting up to speed on the code.
You also continue to claim that ActiveRecord is not capable of handling more than a "handful" of entities. What constitutes a handful? What is it about ActiveRecord, or Rails in general, that is limiting in this regard?
Rails wasn't designed to be the be-all-end-all framework for every business environment. It doesn't fit in a lot of enterprise applications for a variety of reasons -- other languages and frameworks don't fit either, for the same and different reasons. It also doesn't fit in many non-enterprise projects. This doesn't mean ANYTHING.
That said, Rails IS being used (successfully) in the enterprise, apparently increasingly so, and likely for the forseeable future. However, as others have already pointed out here, most software projects are NOT enterprise projects. Lots of people don't WANT to work on enterprise projects (it's hard to think of a good reason to want to), and it just so happens that a large cross-section of those people like a lot of Rails is selling. Concepts like convention over configuration, do the simplest thing that could possibly work, AJAX, REST, and the pure (admittedly subjective) elegance of the Ruby language are all very good reasons to like Rails.
It's funny that people who use and support Rails are labeled "fanboys", when something close to 99% of Rails developers have more experience with other platforms than you do with Rails, and probably more experience with said other platforms.
for jeremy: I really don't understand why you think it's harder to scale up a development team in a dynamic language.
Lack of static type safety in API design - I may be biased, but still feel that it is extremely difficult to scale up in a development team without the safety net. You have the unit tests, but, I don't think unit tests are an alternative to type safety. I usually do not put forward a straw man argument, but here, I have to, since at least in my part of the world we do not often get the ideal team composition of quality members who can live up to the dynamics of a dynamically typed language in a big project.
You also continue to claim that ActiveRecord is not capable of handling more than a "handful" of entities.
ActiveRecord mixes up the two concerns - the domain and the persistence. This is difficult to scale in a domain rich application, since ur domain model is now tightly coupled with the persistence model.
Cheers.
Post a Comment