+ Groovy, Gorm, Gradle
Presented by: Vasu Srinivasan, Texas NIC Usa
For: Austin Groovy-Grails User Group (AGGUG), 2014-06-12
Sr Tech Consultant at Texas NIC, USA
Battle of Programming Languages -https://www.youtube.com/watch?v=dKftGfU0giA
Along with Eric Kelm (@asoftwareguy, asoftwareguy.com)
Grails/Groovy, AngularJS, SharePoint, Java, MongoDB, NodeJs
about:Texas NIC, USA
NIC is in 29 states, specializing in e-government
Grails, SpringBoot, Spring, Oracle SOA, SharePoint, .Net stack
driver license renewals and reinstatements
occupational and renewal licenses
birth and death certificates
texas department of criminal justice - Inmates App
and many many more!
our work benefits and impacts Texans directly
scalability has become a key issue for enterprise applications
stateless services provide better scalability
stand-alone monolithic servlet container and cluster management has in
some cases become a specialized job (WebSphere anyone?)
a simple http server is sufficient for many small-to-medium applications
how application is deployed, forces how to write code
conceptually this will not change, but a certain level of freedom goes a long way
in maintenance and extensibility
ramp up time to create a simple starter app is pretty high
many modern web frameworks have < 5 minutes to download the libraries and
create a simple application
xml as a configuration – an idea’s time has passed (long ago)
obviously verbose, bloated and error-prone
many post-Spring web frameworks use zero xml for configuration
Rails, Grails, Play, Wicket, etc.
ramp up time is a very important criteria
Play? play install run !
Or Grails? grails create-app !
opinionated frameworks are becoming fashionable, again?
Spring had to do something to compete with fast evolving frameworks such
as DropWizard, Ratpack, Sinatra, Scalatra with the concept of “micro-
services architecture” (MSA)
With its vast supporting frameworks/libraries including a solid DI
mechanism, it needed a simple way to tie them all
frameworks that have
strong opinions about
framework by developers
who have strong opinions
about what goes in
spring booted xml out:
of course, that’s the unofficial version of the story
container project for creating new Spring based applications
embedded servlet container: Tomcat or Jetty
starter POMs for many libraries (web, jdbc, log, data etc)
actuators (health, metrics, beans, shutdown, ssh, etc.)
xml, java annotated, groovy bean configurations
xml configuration not mandatory anymore
supports many dbs via spring-data
helps blend web and non-web (eg. batch) functionality
supports many views
jsp (limited), thymeleaf, and groovy template engine too! (1.1.0)
traditional Spring apps are mostly in Java, but Groovy is a
smoother, richer language
Groovy enriches Spring Boot in many ways
Groovy in Boot How?
Using spring-cli, run Groovy
spring run app.groovy
but would anyone do this in prod? not sure.
Use groovy as the
language, instead of Java,
apply plugin: ‘groovy’
Use Groovy Bean
configuration instead of xml
Boot’s GroovyBeanDefinitionReader wires the
Just like Grails resources.groovy
Use Groovy Template
since Boot 1.1.0 and
easy to create html via markup template.
templates in src/main/resources/templates/*.tpl
practical in cases where html is an overkill (email
templates, display history data etc.)
Using Gorm Spin-off from Grails
Some immediate advantages using Groovy
Practical and time-saving annotations
@ToString, @Log, @EqualsAndHashCode
Faster Json conversions (with Groovy 2.3)
Test using Spock
Many classes can apply @CompileStatic and be as fast as
Auto-configures database for HSQL DB
Auto-configures a bunch of other beans
Adds a default Tomcat servlet container to run on port
Simple Rest Service (Get and Post)
AngularJS as client
Groovy Bean Configuration
Groovy Template Engine as View layer
Good, Baffling and the Unexpected
traditional Spring MVC (xml) developers will
surely see advantages in reduced / manual
rest made easy
deployment made easy
auto-configurations largely reduce initial
java annotated configurations provide type-
well modularized, instead of a “kitchen-sink”
gradle support is awesome
Multiple ways to setup properties
Decide on early. Go YAML.
Too many logging frameworks are
included in classpath
Strongly recommend to use logback as
standard, logback.groovy works fine
No out of the box support for profiles
Grails by default provides environment blocks in the configurations, making it
super easy to configure for different environments
In SpringBoot, some handcraft is required to create profiles (development
section in yml or application-development.properties)
Power of grailsApplication.config will be missed
Too many @configuration related annotations
@AutoConfigure, @Configuration, @EnableConfiguration,
@EnableConfigurationProperties, @ConfigurationProperties, @PropertySource,
Annotations cannot be intuitively applied, reference documentation is the main
Too many annotations in general – sometimes I wonder what is my business
logic (@Bean, @PostConstruct, @ComponentScan)
once you get past the auto-configuration magic, overriding the
configurations takes a bit of discovery time
what to wire?
what properties are required?
what are my views?
jsp (anyone still using this???!)
thymeleaf (good and clean library)
groovy template engine
gsp (stand-alone spin-off from grails)
where are my views?
recommended path is src/main/resources/static
too deep in the IDE view
IDE settings can mistake static to be a java package, resulting in undesirable refactors
(rename for eg)
UI Team may like to use bower like js dependency package tools
are webjars always current?
need build customizations if using bower, sass
no out of box support (yet) or grails plugin like asset-pipeline (opportunity to develop!)
Grails Domain objects cannot be converted to
needs a custom mapper in between
Not all xml configuration enhancements
translate to Groovy Bean DSL
eg. <ctx:annotation-config/> works
but not <batch:/>
Broke in Spring Boot 1.1.x
Gorm @Transactional is broke – throws Proxy error
Gorm methods are not available at startup time (Bootstrap/InitializingBean)
substitute with a manual restful controller initiated call to initialize records
spring-boot:ide tricks (IntelliJ)
run the main application directly, not via gradle bootRun
For debugging add VM option
then, debug the main application
sometimes port is not released (Windows)
netstat –o –a –n | findstr “8080”
Associate groovy template .tpl files with “Groovy” for
faster creation of project templates, instead of browser
groovy configuration support (like .properties, .yaml)
richer runtime evaluations, environment block support
out of the box support for common active profiles
expose entities as Rest Entities for prototypes (like Grails
tooling support for Groovy Bean DSL and GTE
Well, perhaps they are already in the making … ?
already a heavily invested traditional Spring shop?
desperately want to scale your apps now?
xml configurations giving you nightmares or headaches?
want a better deployment strategy?
want to hop on the micro-services wagon?
can’t wait for grails-boot?
all of the above?
any one of the above?
Links, References, Acknowledgements
Spring Initializr - http://start.spring.io
Demo Application (StarCatalog) - https://github.com/vasya10/spring-boot-
Testing SpringBoot with Spock -
Google Image search for cute Puss in Boots images
Disney / Dreamworks for Puss in Boots images
Images are used in good intention only to illustrate context of topic
Austin Groovy/Grails User Group
Texas NIC, Austin (Sponsor)
SpringBoot, Groovy, Grails, Gradle team!