What I wish I knew about Grails before my first Grails Project

Introduction
A year ago, I did my first official Grails project. Since it was a short term project, I felt I had to start with both feet in; working on the actual business requirements for the project immediately. Looking back at the project, that wasn’t the right decision. In reviewing the project, I came up with a checklist of what I would have done differently.

As I put this list together, most of it seems common sense to me now; a lot of this is true for anyone adopting a new technology stack for a project. While this can be applied to other technology stacks, my goal is to list out specifics with Grails. I’m sure my list is incomplete, and would love comments from others to add to this list.

Pick an IDE suited for Groovy and Grails
I used Eclipsed Based, Spring Tool Suite (STS), and I was heavily disappointed. The Groovy support was limited. I was also on a Mac OSX and you combine the slow file system of the Mac with STS and I spent more time waiting for the please wait cursor to go away, than actually develop code. Since I was on this project part-time, I thought I couldn’t justify getting IntelliJ; that was a mistake. Being very familiar with Eclipse for my Java development, the transition to STS was super easy, however, it didn’t really help me write Groovy/Grails applications to the level I was expecting. The limited auto-complete for Groovy and the slowness of the application was unbearable; big disappointment.

The more your IDE supports Groovy, the more you will write true Groovy Syntax. With STS I stayed with static typing as much as possible, so the IDE would be able to handle code completion and compile errors. With IntelliJ, I’m sure I would have embraced more dynamic typing.

Learn Groovy w/out Grails
Take at least 2 days and learn Groovy w/out Grails, GORM, or any other addition to the technology stack. Your first Groovy classes will end up being Java written in Groovy. You will most likely fail to take advantage of all the cool features of Groovy. I have used closures with all of my functionality programming experience, but I hadn’t used them in Groovy before; and it has been a while, since I spend most of my work day using Java. Your going to want to throw away your first code anyway, so pick a simple problem and write Groovy. I would take a complex algorithm you wrote in Java, that included nested classes, anonymous classes, reading and writing a markup language (HTML or XML) and rewrite it in Groovy. Making sure you take advantage of closures, native lists or maps, groovy markup, and dynamic typing.

Follow a Difference from Java article, such as codehaus, and work through an example hitting on these concepts. Be sure to include closures, native lists & maps, safe navigation, and dynamic typing. As many that use Groovy, you will soon wish a lot of these conventions were available in Java. Something as simple as safe navigation is such a simple concept that saves a lot of typing and makes code more readable. Again, take the time to learn Groovy, so you take advantage of writing good Groovy code. Since your initial code will look more like Java than Groovy, give yourself an assignment so you can throw the code away, when you are done. You will probably want to.

Groovy Gotchas
This is a short list of Groovy features I liked, but at the same time, caused me issues. It is key areas to why I believe it is important to learn and understand Groovy as a language before you add in the concepts of Grails, GORM, and other features. Here is a list of a few things that I keep in mind, while writing Groovy code.

  • Map Constructor – The map constructor is great when it comes to code compactness. However, what happens when you mistype an argument name or you include an argument that doesn’t exist, groovy treats it as a no-op. I had to track down a lot of failed initializations because I had a typo. I am also a big fan of invariants. I like my options that require fields to be initialized, to have them initialized. Since the map-constructor just calls all of the setters for you, the instance can have an invalid state; especially if you have a typo.
  • Map Key – implied quotes. I’m not a big fan of language inconsistencies. So to have the convenience of the key being a string w/out quotes annoys me. Be sure to learn the language nuances so they don’t trip you up. I have never been a fan of Java ‘+’ for Strings. I would rather have the language be consistent and allow for operator overloading for all objects, not just for the + operator for Strings only.

Grails
Scaffolding
Just like you should spend a couple of days learning Groovy w/out Grails, you should spend a couple of days learning Grails w/out developing for your project. The automated scaffolding can be used as part of learning Grails, but I shouldn’t be used for your production code. Also, I would rather have you auto generate the scaffolding and use/tweak it when learning Grails. Once you start building your actual application, start from scratch. Or, better yet, customize the scaffolding generation and then use it to build all of your web pages. In any case, there is a lot of power with the scaffolding (dynamic and generated). Just don’t generate it and then try to tweak it to your desired state. You will end up with a lot of dead code, and code that doesn’t really fit your application — at least that is what happened to me.

GORM
I have used Hibernate/JPA for 8+ years. I am a big fan of Hibernate, and appreciate all that I can do with it. I will use various different fetching strategies as needed; one of my favorite is sub-select. However, you need to know your your session life-cycle and use cases to build your application correctly. GORM is great, it does a lot of the stuff for you. The dynamic finders (up to 2 arguments) are fantastic. The amount of boiler plate code using Hibernate with GORM is so much less than writing Hibernate or JPA in Java. That being said, if you are new to Hibernate, GORM will make things easier, but it will also make it harder to understand how and why everything is working.

If you have experience with Hibernate in Java, I would recommend taking a simple object relationship you built in Hibernate/JPA in Java and apply it to GORM/Grails.

This is also where I feel the dynamic scaffolding shines. While I work on a complete technology stack, my expertise is more in the persistence tier. it is also how I think about the application; how am I going to store the data is what I want to work on first. Let Grails help you get that right, before you start working on any of our presentation. Write your GORM entities and relationships, your unit tests, and then use the default scaffolding to visualize use it to see if it “makes sense”. You can work on your transaction boundries, lazy/eager associations, fetching strategies w/out focusing on any of the UI.

This is the one area, I’m very happy with how I developed the initial application. I focused on the persistence tier and tested/used it before building any of the UI. That is because, how I think through a problem domain. Grails/GORM worked perfectly for me. I just wished I threw away the generated scaffolding I played, when I started to work on the actual UI.

Grails Plug-ins
Navigating the Grails Plug-ins can be a challenge. A) you don’t want to do something that has already been done, but B) you don’t want to adopt a plugin that is not being supported or doesn’t really fit what you are trying to do. If you are looking to add an existing technology to your stack, odds are there is a plugin for it and you want to add that in via a plugin. For example, you can add jQuery to your application by adding in the javascript to your pages. However, you should be doing this via a plugin. So, for your starter application, be sure to include the process of using a plugin.

Database Schema
GORM’s create/update schema support for Hibernate works very well. While you are getting your initial application working, you should use this functionality. Only after you need to support database migration, would I worry about maintaining your database schema. Letting GORM/Hiberante manage your database for you, forces you to work with a rich object model and letting it create your schema. When I first starting writing Hibernate applications, I was very much of the school of letting your database drive your object model. Over the past 8 years, I have changed to where I prefer the object model to drive the database schema. Grails/GORM encourages that and you will find you enjoy developing more if you can focus on a rich Object Oriented design, instead of forcing in your desired database schema.

Obviously, if you are supporting an existing schema, you cannot do this. For your first Grails application, however, try to create one where you let Grails/GORM handle this for you.

Conclusion
If you are a seasoned Java/JEE Developer, it shouldn’t take you very long to learn Groovy/Grails. Give yourself a couple of weeks of being able to use it, and you will be happy you did. Now convincing your employer to use it; that is a different story.

One thought on “What I wish I knew about Grails before my first Grails Project

  1. Dan says:

    Couldn’t agree more with using IntelliJ for a Grails project.

    Also, when just starting out, get the Grails In Action book and take those 2 days you mentioned and follow chapter 2. That will comprehensively cover your points on “Learn Groovy w/out Grails” and “Groovy Gotchas”.

    Finally, it’s generally understood that the controller code generated by the scaffolding templates is not to be considered examples of Grails best practices. But with a good IDE (i.e. IntelliJ) you can use it as a starting point and slice, dice and refactor to get you where you want it to be.

    Great tips!

    1. Nicholas Collins says:

      This is something that should change for Grails. Any scaffolded or generated code should meet current best practices.

  2. venkat says:

    Good tips for start Grails/Groovy

  3. Alberici A. says:

    Hi Neil,

    I started working with Grails 2 months ago, your page could had save me considerable time.

    After my experience I think these tips are very usfefull to a Grails Starter.

    Thank you!

  4. Thanks for sharing this helpful info.

  5. ramon says:

    Yea, yea, Grails is Great, Grails is the best… But… Someone knows how to indicate to grails that a java String attribute must be Text in the DB?

    1. Deepak says:

      use the static mapping within Domain : static mapping = {
      myTextField type: ‘text’
      }

  6. Tom Henricksen says:

    Great advice, especially the “Learn Groovy w/out Grails”. I didn’t do this right away and it caused a lot of confusion initially.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

*