Matt Raible has been building web applications for most of his adult life. He started tinkering with the web before Netscape 1.0 was even released. For the last 16 years, Matt has helped companies adopt open source technologies (Spring, Hibernate, Apache, Struts, Tapestry, Grails) and use them effectively. Matt has been a speaker at many conferences worldwide, including Devoxx, Jfokus, ÜberConf, No Fluff Just Stuff, and a host of others.

Matt is a DZone MVB and is not an employee of DZone and has posted 143 posts at DZone. You can read more from them at their website. View Full User Profile

Migrating a Rails app to Grails

01.23.2008
| 7850 views |
  • submit to reddit

There's an interesting trend I've seen happening at companies over the last year. More and more, they're experimenting with Rails and/or Grails for both prototyping and real applications. I think this is an excellent use for these frameworks as they both are very productive. The reasons for their productivity is simple: zero turnaround and less code.

For a Java-based company that's built their bread and butter applications on Java and been successful with it, both frameworks can be disruptive. Bread and butter applications tend to be large and somewhat difficult to maintain. In my experience, the biggest maintenance headache is not writing code or fixing bugs, it's the turnaround time required to make changes, run tests and build the application to test in your browser. Since Rails and Grails eliminate the turnaround, it's only natural for developers at companies with a lengthy build process to love their increased productivity.

Over the next couple weeks, I'm going to do some experimenting with porting a Rails application to Grails. Why? Because I think companies are going to have a difficult time choosing between these two frameworks for rapid prototyping and (possible) production deployments. While both frameworks are great for prototyping, the last thing most developers want to do is throw away the prototype and develop it with something else. They want to continue to enhance the prototype and eventually put it into production. With Rails and Grails (and many others), it's possible to build the real application in a matter of weeks, so why shouldn't it be put into production?

For most Java-based companies, putting a Rails application into production is unfamiliar territory. However, a Grails application is just a WAR, so they can continue to use all the Java infrastructure they know and love. So for companies with an established, tuned and successful JVM infrastructure, does it really make sense to use Rails over Grails? The only thing I can think of is language reasons - there's a lot of Ruby fanatics out there.

So again, the purpose of my experiment is simple: to see if a Grails app can do everything a Rails app can. As for language features and scalability, I'm not really concerned with that right now. I'm not looking to prove that either framework should be used for all web applications - just certain types.

Has anyone out there ported a Rails application to Grails? If so, are there any gotchas I should watch out for?

NOTE: I realize that Rails can be deployed on the JVM with JRuby. However, I think many companies have existing Java-based tools (logging, JMX, Spring backends, etc.) that more easily integrate with Grails than Rails. I could be wrong.

 

Published at DZone with permission of Matt Raible, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Rick Hightower replied on Wed, 2008/01/23 - 8:46pm

What is the Rails app? Do you have a spec? How big is it?

Matt Raible replied on Thu, 2008/01/24 - 12:55am

There's no specification for the Rails app - just existing code to look at and attempt to replicate with Groovy. It's a mobile application - serving up content for iPhone and WAP. What I've found so far is it's pretty easy to solve Rails issues because you can google for stack traces and find out the solution. Grails is pretty easy too as I recognize most of the problems (since stack traces are somewhat familiar).

There's not much of a model to the application and there's virtually no CRUD functionality, so both frameworks are somewhat out of place for the sweet spots.

Matt

Arek Stryjski replied on Thu, 2008/01/24 - 8:14am

Sorry this is not connected with topic of this post, but I don't see other option to send massage to author or "zone leader".

I think you should rethink if "Groovy Zone" should exist if you send all post to Javalobby at a same time.

Best Regards,
Arek

darryl west replied on Thu, 2008/01/24 - 12:22pm

My company is currently porting two Rails applications to Grails--an authentication (ala openid) application and time tracking application developed over the past two years. When I first started with Grails, I thought I would miss not having migrations, but I don't. I've found Grails, and Hibernate (especially GORM) has a much better design approach than Rails/Active Record.

With rails, it's all about the database driving the design, hence the need for database migrations. With grails, it's all about the data domain objects--the database is taken care of in the background. Also the added service layer makes controller logic cleaner (although you can do this with Rails helpers, but it's usually a re-factoring effort).

On the downside, I had to create data fixtures (Datasets) in Grails. But, I learned a lot from the Rails fixtures, especially the changes that DHH made for 2.0, and was able to easily re-implement in Grails. My fixtures replace YAML with pure groovy which is proving to be a better fit.

The other obvious negative is the additional startup time for anything in java as opposed to ruby. So running individual tests during development is not as snappy as I would like. Also, I miss the zen test tools, especially autotest.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.