Having spent the last eight months working almost exclusively in Grails I wouldn’t hesitate to recommend it, it’s fantastic. A non-disclosure agreement I signed with the customer prevents me from giving detailed features of the project but here are some of my experiences and findings.
I recommended Grails as a development platform for the project because I wanted a platform which had all of the sturdiness of a test-driven Java project but with the speed and flexibility of a modern framework suitable for story-based, agile development. I’d been using a PHP framework based on Rails for a few months beforehand and the ‘Convention over Configuration’ paradigm was lovely to work with. The prospect of returning to configuration-heavy development usually associated with Java applications was no longer appealing.
Grails overlays the Spring Framework and Hibernate. Combining these with a Rails-like framework that provides seamless testing made it a compelling choice when I was looking for a platform at the beginning of the project.
The Groovy programming language used in Grails probably put the biggest smile on my face. Java has been my preferred development language because of the excellent testing frameworks, strict syntax and IDE integration; until now. Because Groovy is Java, libraries such as JUnit will all work. The free SpringSource Tool Suite (STS) is Eclipse with a few additions that make development in Grails simpler. Groovy’s syntax and its ‘dynamic’ features made it a pleasure to work with and unfortunately writing Java now seems very long-winded and rigid.
I initially began the project writing code in almost pure Java. It compiled and worked but it did not take long before I was using Groovy’s cleaner syntax wherever I could. Huge amounts of code began to become unnecessary and could be removed making it much clearer and manageable. Groovy automatically creates getter and setter methods behind the scenes; not needing to write these or having them cluttering up the code saves a lot of time and reduces the number of lines of code considerably.
Another powerful feature of Groovy not present in Java is the ‘Closure’. Closures provide the ability to pass ‘code blocks’ as arguments to methods. For example, to perform a dynamic operation on a list:
// Create a method which takes a 'dynamic'
// operation operating on each item of a list
// or array.
def processAllMyItems(myItems, anOperation) {
myItems.each {
anOperation(item)
}
}
// Create some items to process.
def someItems = ...
// Print items...
processAllMyItems(someItems) {
print "Calling closure for: ${item.name}"
}
// Update items...
processAllMyItems(someItems { it.update(); }
To start my Grails project I simply created a domain object; Grails then created everything I needed for an MVC application including all web pages, admin pages for CRUD operations, database and test files. When I needed to add a new field, I only had to add one line to the domain object and the database was updated automatically. Grails also provides ‘scaffolding’ which dynamically creates screens from the domain object so even the user interface updates automatically. Since the requirements were still evolving as stories, this was exactly what I needed to avoid being tied-down to an implementation too early.
The project also involved a client Android app which accessed the main application using REST. Grails provides wrappers and plugins which make it very easy to work with web services and REST. The wrappers within Grails meant that the server-side code was largely agnostic of the nature of the data being received meaning that data could be received as JSON or HTTP parameters without any code changes.
The major downside when developing in Java, when compared with PHP or JavaScript, is the overhead of restarting the application to pick-up certain changes or re-run tests. Towards the end of the project my understanding of the testing features in Groovy and Grails had improved and it became possible to test more and more inside the IDE as unit tests and avoid the need to restart servers all together. Grails plugins are also available which reduce development test time considerably too.
It has been hard to tell yet whether the ‘dynamic’ nature of Groovy and ‘Convention over Configuration’ in Grails will have any noticeable negative impact on performance and scalability. From what I have seen so far these points seem to have been addressed by the Grails developers. And, the gains in development speed will certainly make up for this and free-up funds for performance testing and tuning.
Overall, development in Grails seems quick and robust. The framework coerces you into writing well-modelled code although as my knowledge of the platform improved I still found myself unpicking anti-patterns I had inadvertently blundered into early on.
There has been a lot to learn and I will do some things differently next time around, particularly with functional testing. On balance, I don’t think I’ve used a platform that is as good overall as Grails.
Some links:
