Rails and Grails comparison

I have spent few years developing in Ruby on Rails. For the last half of year I have been learning Grails, too. The things described here are a summarization of the differences that I had to come over.

The comparison will be written in a simple “table based” structure. I just got used to it when preparing comparisons or product studies for tenders.

Ruby on Rails

A lightweight web framework written in Ruby scripting programming language. It contains its own application server. See the Rails home website.


A web framework written in Groovy. The source code is compiled to byte code and can be run on Java application servers. Grails home website.


Before I start comparison, it is fair to say, that Rails has been around from 2004 while Grails final version dates from 2008. So, some of the differences are caused by this time shift.

Both of the frameworks are more evolutionary than revolutionary. They just implement the right patterns and they do it right.

Ruby on Rails Grails
First release (version 1.0) July 2004 February 2008
Life cycle Mature framework with solid base of developers Young framework with a growing base of developers and a huge base of potential developers (from Java)


Ruby on Rails Grails
Framework Excellent. Uses the RDoc that contains not only list of methods, classes and files, but also source code of a method, with syntax highlighting. Very good. Contains list of classes, methods, files… but I am really missing the source code. If the code is not documented, the documentation is useless
Application Excellent. Only the application files are documented using the RDoc (including syntax highlighting) On one hand it is exhaustive, because it generates documentation for all classes in the project (including plugins). On the other hand it does not contain the source code. So, once the code is not documented, the documentation is useless. So, on average I would say it is good.


Both frameworks are based on flexible languages that allow meta programming – changing classes on the fly.

Ruby on Rails Grails
Developer audience From beginners Some experience is required
Language constructs Readable, sometimes like natural language Readable, sometimes too many brackets (but as I said, I spent some time in Ruby :o)
Mapping objects to database Excellent, all declarative Excellent, all declarative
Libraries Wide variety of libraries and plugins. Almost everything I needed was available (except for Kerberos support…) Huge amount of java libraries could be used together with Grails. This is one of Grails killer features.
Scaffold The default scaffold looks terrible, custom plugins needs to be installed. Looks nice out of the box, implements handy nice features like table sorting.
Tools rake (~make), rjs (ruby java script – library that allows to write java script functionality in ruby), migrations (tool that uses ruby syntax to change database schema – very useful) ant (~make)
Log file Very descriptive, it provides exactly the information needed: controller/action/parameters, time spent on DB, VIEW, CONTROLLER, SQL statements (including timing) Verbose… very. Exception generated 1000 lines of code in log, missing the information about SQL statements and the things that are in the Rails log. This was a disappointment.
Console Simple terminal window working in command/result mode Window based – command answer is displayed in different frame at the end of it (unfortunately it is not scrolling properly, so it is quite annoying). I take it as a temporary problem.  
Folder structure Simple, follows the MVC Following MVC, slightly more complex than RoR
Thread support Poor Native


Ruby on Rails Grails
Resource usage Medium resource usage Higher resource usage


Ruby on Rails Grails
Internet High potential. The framework allows fast development of an application with a very good performance. High potential. It alows fast development and it can utilize all of the Java frameworks.
Enterprises Just for prototyping or small applications. The support of enterprise technologies is not at the focus of the community. Could be used for prototyping and also for real applications

Last, but not least, the popularity of both frameworks:

There are many more differences that were not mentioned here. If you find a major one not mentioned here, please leave me a comment. I will appreciate it.

Visualize your Rails schema

While doing some Ruby on Rails code refactoring, I realized I’d like to visualize the database schema of the application.

An easy possibility is to print out db/schema.rb. This seems a bit too linear and little visual to me. OK, I’d better keep thinking.

An enterprise approach would be to take a CASE machinery and feed it with the create DB scripts. That is solid and reliable, but a kind of overkill. What’s more, a Rails app with convention over configuration can do well without foreign keys and so it usually does. This means that relations between tables are mostly implied by column names rather than explicitly declared as DB constraints. Thus, hardly any CASE tool can derive such relations from a DB schema.

OK, let’s try to go the Rails way and put together existing ingredients, add a little cream and see what we can get:

  • there are many UML modeling tools out there, although few of the free ones can reverse-engineer a DB schema
  • there’s the SchemaDumper in ActiveRecord, which generates the schema.rb based on DB reflection
  • there’s this standard XMI format for data interchange between modeling tools

OK, so let’s try and tweak the SchemaDumper to generate XMI, then import it into a UML modeling tool and get the schema diagram from there.

So, I morphed SchemaDumper into UmlDumper, which generates XMI in the widely adopted Rose flavor. E.g. a Typo blog database will result in schema.xml like this:


Then I import this XMI into a UML tool – StarUML in my case – to get the basic picture. Yellow boxes are DB tables, grey boxes are presumed “virtual” tables referenced by columns in other tables.


I play a little with the layout and incorporate the “virtual” tables into the hierarchy. For completeness, I also add a few model classes, which show up only in Rails code, not in the database (manual entries in blue color):


I export the diagram from the tool to print it, share it and enjoy.

Now, that’s it! The approach is quite universal (not yet true for UmlDumper), I can quickly reuse it in my further Rails projects, and so can you.

Note: for one-time use I created a rake task.

namespace :uml do
  desc "Generate an XMI db/schema.xml file describing the current DB as seen by AR. Produces XMI 1.1 for UML 1.3 Rose Extended, viewable e.g. by StarUML"
  task :schema => :environment do
    require 'lib/uml_dumper.rb'
    File.open("db/schema.xml", "w") do |file|
      ActiveRecord::UmlDumper.dump(ActiveRecord::Base.connection, file)
    puts "Done. Schema XMI created as db/schema.xml."

For frequent use (fine-tuning the export), it is better to start the Rails console and call UmlDumper from there to avoid re-loading the whole Rails stack all over again.