PepsiCo Grails Sites Post-Analysis

There are many in-bound links to this article that may imply that Pepsico itself is using Grails. It is important to stress that this work is performed by Enotions Ltd. on behalf of their Pepsico-owned clients, who love the work we do for their brands but wouldn't know what Grails was if it fell on their toes. Our work with Grails is very well received and we are continuing to roll out further Grails sites for these Pepsico-owned brands.

Early in 2007 we (Enotions) put together the first three in a number of commercial websites for some high profile UK food brands, using Grails.

Some background: I have previously implemented sites like this using a miminal custom app framework I wrote using Spring, WebMacro and Groovy for logic scripting. I learned a little about grails early in 2006 and have been increasingly involved in Grails itself and eventually in 2007 felt that Grails had what I need to do these new sites.

I wanted to use Grails for the following reasons:

I wanted an ORM but don't have the patience to learn Hibernate. There was just too much ugly parameterized SQL in my sites.
I wanted to increase unit testing of my apps and the components within them
Scaffolding offers an attractive way to get quick and dirty back-end admin interfaces for web-apps
I was already enchanted with Groovy
Spring rocks
The sheer simplicitly and compact code had me smitten

I started working on some features and raising issues for Grails late in 2006 to shake down what I saw were some blockers for us and launching these sites.

Our sites are not Web 2.0 - they are standard websites with form submissions, emails generated from form submissions, and some visitor tracking and user profile storage. However they do see traffic in the region of 10,000 hits per day currently.

We launched with version 0.4 of Grails just before 0.4 was publicly released, due to deadlines. During the development of 0.4 we had numerous teething troubles and some "we REALLY need this nooooooooooow!" moments. However the team came through for us, we found a few workarounds, and our sites went live and have behaved very well.

What I'm saying here is that 0.4 was a watershed Grails release, for us at least.

Now we are in maintenance/enhancement mode on some of these sites and creating new sites we can really leverage Grails' power. There is so little code to maintain, and adding new features like display of a weather feed using Quartz jobs and services was a breeze - and feels like a good clean solution.

However people really only want to hear about the bad stuff in things like this. There's nothing particularly bad but here's the "state of the nation" as far as I'm concerned:

There are still some areas where Grails needs work, but many of these have already been tackled in the 0.5 HEAD although we are not going to move to 0.5 until it hits final release.

One particular issue we have had is that for these websites, which are not typically CMS driven, we have content changes to make quite regularly. With Grails 0.4 and earlier this requires you to upload an entire new WAR file (min 14MB) and redeploy the application, unless you like making live edits to expanded WAR files on your server and the version control fun that can lead to. This is the number one complaint from the "evil boss man" (hi Rob!) that our cherished web developer cannot quickly throw up a content change to prevent our clients from being sued due to some minor typing or misrepresentation. Graeme has tackled this in 0.5 and I will be testing this out soon, and boss man will be very happy.

It should be noted, though I omitted this originally when writing this page, that this is not a problem with Grails itself. It is a problem for all Java Web applications bundled as WAR files, as the paradigm is to include your view pages + images in the .WAR. In the real world, for content based sites at least, this is not a good paradigm.

A minor issue we have is that while the convention-based URI space is convenient, it is not very SEO-friendly. We like to have "search engine friendly" URIs including meaningful words relating to the subject of the page. Again this is fixed in 0.5 with the new URL mappings artefact.

The other big issue for us currently is performance. GSP rendering/taglib invocation seems to be slower than it should be and we're working to shake down these issues. We believe some major improvements are possible, but even now our form rendering (the slowest pages to serve due to complexity + taglib usage) is running faster than my previous home-grown application which did not use GSP, and this is actually on a slower box than the home-grown solution.

I have confidence that Grails will offer us the scalability options we need to handle large traffic spikes, but we have the separate challenge of working out how to code for this and how to deploy this in hardware terms. After all if anything is "slow" we can fall back to Java classes or JSP pages (shudder).

All in all, Grails activity is high. More and more people are joining the team and becoming involved, and there is a good buzz about this. It feels like Rails but on a more proven (Java) infrastructure, with many more options for handling the things that get thrown at us.

Marc Palmer marc at anyware dot co dot uk http://www.anyware.co.uk/