Spring on Rails
For rapid prototyping, I’m a fan of “Ruby on Rails”:http://www.rubyonrails.org/, for its lightweight, painfree MVC model.
For large projects worked on by a number of developers, however, Ruby and other lightweight frameworks have limitations. The implicitness that makes Rails so lightweight becomes a challenge as team size increases. (I realize not everyone will agree on this point, but I’m betting there are many who will.)
For instance, there’s no file checked into the source tree that fully describes a model object– I have to browse the database to understand what the object is. There’s also no overall map of all of the pages and associated policies exposed by the application, which is implicitly represented in the filesystem and the source code.
For large scale web development, I like “Spring”:http://www.springframework.org. A single configuration file maps out the entire structure of my web application and the wiring and configuration of the components. At a glance, I can see that a given set of pages has a given security policy. Adding a single line allows me to apply additional interceptors that add new policies.
But Spring is painful for rapid prototyping and iterating because of the frequent need to modify configuration files, rebuild, and restart the application server.
Is it possible to have the best of both worlds? Can we have a rapid prototyping environment that leverages all of our existing Spring investment, and which allows a smooth transition from prototype to production quality code?
We’re currently working a project that we believe will do just this. We have a generic Spring controller, enabled only in development environments, that enables rapid prototyping of pages using the Groovy scripting language for controllers and JSP pages for the views.
I can mock up the presentation by just dropping “foo.jsp” into a directory; depending on the directory I drop it into different sets of standard interceptors are applied (e.g. to require a user login.) I can rapidly prototype a controller behind the page by dropping “foo.controller” into the same directory.
Groovy can import any Java package call into any Java object, so I can reuse all of my existing business logic. Because it’s a scripting language, I can create and modify controllers with the same speed and ease that I update JSPs. Later, I can seamlessly transition to a full fledged Java controller by updating the Spring configuration appropriately; no changes to the view are required.
We’re in the early days of this project, but it seems likely to be useful already. When this is a bit mature, we’ll release it under the GPL for others who are interested in combining rapid development and Spring.
10 Comments so far
Leave a comment
I applaud your efforts for making Java web development less painful, but the assertion that Rails doesn’t work for large scale development because of missing configuration to give the large picture is simple false.
If your domain model have grown so large as to be hard to decipher merely from looking at the code, then deal with that problem explicitly. Add Just Enough documentation to make it clear.
Why on earth would you want to rely on a verbose XML configuration to serve as your documentation when you could choose any other style in Rails (you could even do your documentation in XML, if that was where your fetish was)?
Adding documentation when needed, targeted explicitly at solving the desired communications problem, while still enjoying all the benefits of convention over configuration would seem to bring you the best of both worlds: The best documentation you could write (unconstrained by configuration formats) and the rapid style of development that’s alluring you.
Anyway, best of luck with the project.
By David Heinemeier Hansson on 09.30.05 4:29 am
We really can all get along, especially if we respect and share good ideas from different communities.
As I said, I’m a fan of Ruby on Rails. I happily acknowledge that interesting, large scale web applications have been built on Ruby on Rails.
However, there are always tradeoffs with any framework, and smart people will make different decisions about the frameworks they choose to use. It makes sense to share as many good ideas between projects as possible. It’s undeniable that Spring has a large and commited user base and that interesting apps are being built with it. I intend this project as way to share some of the benefits of Ruby on Rails with Spring’s user base, which does not in any way detract from the goodness of Ruby on Rails.
I would like to drill a bit more into the point of explictness and “do not repeat yourself” with respect to models and database schemas.
Smart people have raised legitimate issues about the approach taken by Ruby. Other projects that share Rail’s goals and assumptions have taken different approaches than Rails.
Django, for instance, allows the schema to be specified entirely in the source code of the model object. Given this specification, it can automatically create a database schema. This is handy, because my app can automatically create its schema on a new database as needed. I haven’t repeated myself or scattered the definition of my schema and model in multiple places.
Rail’s ActiveRecord uses a mixture of implicitly deriving the model from the database schema plus additional specifiers on the model itself.
In other words, I have to look in two places uses two different tools to find out what the model means. If I change the schema in the database, this change is not recorded in source control where everyone can easily see the changes.
Documentation doesn’t really solve this problem. When I write documentation, I am repeating myself, and the likelihood of that documentation staying in sync with both the database and the code base is really small.
In this instance, Django seems to be trending towards a better way of not repeating myself. There’s no reason why a similar approach could not be incorporated into Ruby on Rails, of course.
By philbo on 09.30.05 2:01 pm
There will certainly never be a one-size-fits-all framework. I was arguing against the specifics. That is to prefer configuration, when its not needed for technical reasons, to do documentation.
In regards to database-agnostic schemas, you’re right again. Which is why we introduced Migrations with the last version of Rails and with the next version you’ll get db/schema.rb auto-generated.
So this solves that the schema is not part of the application (so now its there for reference and version control), but more importantly, it still works when you start caring for your data and can’t just drop/recreate to update the schema.
In that sense, it’s significantly more DRY. Since with the schema-from-model approach, you’re left stranded when you need to migrate the schema to add or remove fields. Which makes it nothing but a static schema generator (which we now have as well).
Anyway, different approaches are certainly valid. But there’s definitely a lot of choices in Rails, like migrations, that are not just different, but made specifically to solve problems with alternative approaches (like schema from model).
By David Heinemeier Hansson on 10.02.05 4:38 pm
I will need to catch up with the migrations and auto schema generation work in progress; sounds exciting.
We use a delta tool (written in Ruby, no less) to keep our databases in sync with changes to the application schema, so we’re pretty familiar with some of the requirements of doing migration correctly.
In the case of Oracle, it’s important that the different migration scripts be capable of running either under a particular schema or as the sys user for certain operations that require extra privileges. Testing can be a challenge– it’s pretty easy to write scripts that will work from particular starting points but not from all.
By philbo on 10.03.05 1:45 am
[…] One of the big selling points of Groovy is that a Groovy class is supposed to be able to do anything a Java class can. It was for this reason that we chose Groovy for Spring on Rails. […]
By Bogle’s Blog » Spring on Rails encounters an un-Groovy limitation on 10.03.05 2:01 pm
Hey, interesting to hear what you are up to.. you may want to take a look at (and maybe contribute to) Grails (Groovy on Rails): http://grails.codehaus.org.
Its the official Groovy project to develop a Rails like framework and it is built on Spring & Hibernate.
Cheers,
Graeme
By Graeme Rocher on 10.06.05 2:24 pm
Thanks for the comment. I looked into both Grails and Trails. There are some important differences between the approach we are taking and either of those projects.
We’re not trying to create a new framework.
We’re optimizing for people (like ourselves) who have an existing traditional Spring project and who want to do RAD development at the periphery that leverages their existing core investment with minimal learning curve.
That’s all fairly abstract, I’ll post some examples that make it clear what we mean.
By philbo on 10.06.05 7:18 pm
[…] In my first Spring on Rails post from last September, I was honored to have a comment from David Heinemeier Hansen. DHH took me to task for appearing to suggest that “Rails doesn’t work for large scale development because of missing configuration to give the large picture”. […]
By Bogle’s Blog » Rails *and* Spring on 04.28.06 4:45 pm
For Java web development that doesn’t hurts I use SEAM ( seam_gen, etc ), for working with Rails I use Rails, JRuby, Groovy. Will certainly never be a one-size-fits-all framework, so we have to enjoy it!, if you choose EJB 2 and your system needed that framework, enjoy it!, thats my message.
By Roberto Carlos González Flores on 11.07.07 3:16 pm
[…] 看到辩论展开之后，Shalom表示他与 Michael O’Keefe的观点一致，该观点囊括了上面表述的几个观点。Shalom还提及，伴随诸如 Spring on Rails 和 Caucho的基于Java的PHP实现 的出现，市场出现了集中的趋势，而且开发可伸缩站点的挑战将使LAMP套件和Java在将来日趋靠拢。 […]
By 辩论：为什么多数大型网站不是用Java写的？ | gussing的八卦 on 11.30.07 6:15 am
Leave a comment