Session Notes – Grails for the Enterprise

Presenter: Robert Fischer

What you’ll be getting for your time

What is Grails?

web app dev framework and environment leveraging java and groovy
- environment is often overlooked
- easy to do development with vi and bash–need for IDE isn’t all that huge
convention-based mvc development framework
- ruby on rails really introduced the idea of convention over configuration
- grails takes this idea and applies it in the java space
- powerful command-line tools
powered by pre-configured and pre-integrated spring, hibernate, sitemesh, junit, etc.
- all the technologies you are or should be using

How would you like your grails?

conceptually think dynamic mvc framework
- dynamic, succinct domain and controllers
- view technology works naturally with html
- run from source code check-out
- new features via extensible plugin architecture
  - even the stuff built into grails is based on plugin architecture
actually approachable best-of-breed java stack
- prepackaged java build system
- builds a war to plug into existing deployments
- hooks for existing spring and hibernate configs
- support for other enterprise technologies

How does Grails fit the Enterprise?

what is the enterprise?
- some people see this as “established, extensible, dependable”
- some people see this as “bloated”
unique qualities of enterprise dev
- large-scale apps with application ownership flux
  - people coding and gathering requirements on app will change over time
- existence of user-developers
  - people who want/need to use your code but don’t want to know how the code works internally
  - google “robert fischer free toilet” to see his rant
- out-of-control infrastructure
  - literal meaning: infrastructure I the developer don’t have control over
    - don’t have access to production databases, etc.
  - can also mean out-of-control in terms of there being a lot of different systems that the app needs to tie into

How does Grails fit in?

large-scale and ownership flux
- conventional development
  - common style so doesn’t matter who wrote the code originally
- built-in testing
  - strongly encourages writing of tests–major way to deal with ownership flux
- groovy
  - more succinct language, easier to read
existence of user-developers
- plugin architecture
  - “experts” can build plugins that “users” can leverage
- direct java lib interaction
  - don’t have to think about how grails deals with the java class you just imported–it’s java
out-of-control infrastructure
- big win here is Spring

Architecture of Grails

groovy
Model
- GORM
- Hibernate
  - can plug in other persistence mechanisms (JPA, Hadoop, CouchDB, etc.)
- JDBC
View
- GSP/Taglibs
  - taglibs are nice, straight-forward way to extend the codebase–much simpler than Java taglibs
- sitemesh
Controller
- Grails controllers
- Spring MVC
pervasive
- spring DI
- spring transactions
- servlet api
- junit
- ant (gant)
- log4j
- web.xml

Plugins

if you want other technology than listed above, there’s probably a plugin that does what you want
functional testing
- G-Func, Canoo Webtest, Selenium, Fitnesse
RIA
- Grails-UI, RichUI, GWT, Flex, YUI, IUI (for iPhone)
Database Management
- autobase — runs database migrations
- rails migrations plugin (you don’t want rails migrations!)
background tasks
- BackgroundThread, Quartz
tons more — http://grails.org/plugins
- rating system but don’t put too much credit in it

Autobase

manages database state using a non-linear collection of database change sets
- Rails migrations are a linear path
  - assumes developer who made previous changes will be making future changes
leverages existing grails database automation to minimize effort
- uses HBM -> DDL
- HBM -> DDL assumes everything will be non-destructive
- autobase handles destructive changes
- uses embedded dsl in groovy; allows for things like dropColumn(), renameColumn()

BackgroundThread

provides a spring bean that executes arbitrary closures in the background
handles some awkwardness with hibernate sessions, provides thread logging and pooling

GORM Labs

SubLog and Testing Labs

SubLog = Sublime Logging
- static ‘log’ properties
  - by default logging is available only on instances of objects
- dynamic ‘log’ properties
- strips off slf4j and gives more direct access for log4j
testing labs
- controller integration test case support

Your Grails Adoption Plan

start with a roughly green-field proof of concept web application
- grails for reporting on an existing database is a great avenue for this
replace/supplement a service with grails
- making grails an endpoint for an ESB
use GRAG on SourceForge to generate a db front-end
wrap an existing Java or PHP web app in grails and use web.xml (installed via “grails install-templates”) to map existing URLs to servlets
- use url mappings to add new functionality in grails (e.g. http://myapp/g/newStuff)
- PHP plugin gives you a PHP engine as a servlet–runs existing PHP code
do it and don’t tell anyone
- ends up as a WAR
- ask forgiveness later

Resources

live open source apps
- Grails Crowd
- grails.org
- Groovy Blogs
- Groovy Tweets
media
- Groovy, Grails, Griffon podcast
- GroovyMag

Live Coding/Q&A

Matt Woodward