As previously mentioned, the core Tradeshift platform is built using a Grails frontend and a Java backend. Grails is one of those rapid development environments inspired by Ruby on Rails, just implemented in Groovy instead of Rails. Also, it uses the Spring framework underneath to do all the heavy lifting.
Why Grails?
We started using Grails in October 2010. Our first version of Tradeshift used Drupal (PHP) as frontend, and I might as well say it as it was: it was a mess. Drupal might be fine for a CMS, but we used absolutely no CMS functionality, so we gained just about nothing. Instead, we suffered from unmaintainable code, no proper reuse, and lots and lots of magic and weird behavior. So, we decided to move to another platform for the frontend (at that point, we also had the split between frontend and a Java-based backend). We evaluated quite a number of frameworks and platforms (like GWT, Node.js, Wicket, and many more), and in the end we settled for Grails. Now, it is 1.5 years ago, so I don’t quite remember all the reasons, but here are some of the main ones:
- No restarts required when changing code (at least for most of it)
- HTML templates can be plain HTML, pure taglibs or a mix – this makes it possible for HTML/CSS specialists to work on the layout without involving coders
- It’s light and driven by convention
- It’s extensible
- It’s written in a dynamic language, which makes it easy to add new features
- It’s based on Groovy, which is based on Java. This basically means that any proper Java developer can get running with Grails in a very short time. It’s extremely rare to find somebody with actual Grails experience, but that hasn’t been an issue because Grails is so simple. Run through a sample or two, and you basically have all the basic concepts in place.
Grails performance
The performance of Grails is ok – not great, but not all bad either. It must be said, though, that we do not use the Gorm part of Grails (that’s the OR-mapper, based on Hibernate, which is used for accessing a relational database). Instead, we fetch all data from a REST interface on the backend. That means that in our setup, the frontend is pretty slim – basically it renders HTML and pushes data to and from the backend.
The good part about using Grails is that it’s built using Groovy, which runs on the JVM, which basically means that it runs on one of the fastest VMs ever built. Of course, Groovy isn’t, and never will be, as fast as pure Java, but it’s not that bad. Of course, you shouldn’t be running heavy calculations in Groovy, but for something like Grails, it makes sense. And if you hit something where Groovy is just too slow, you can just reimplement in native Java.
For now, we’re mostly just using standard Grails/Groovy – we haven’t hit any hard performance issues yet, but they’ll probably creep up at some point.
With the setup we’re running right now, a Grails instance handles about 400.000 page view per day, which doesn’t really put any strain on the server (we’re running the frontends on Amazon large instances). In other words, we’re not too worried about the performance right now.
The biggest scaling risk right now is session size. Underneath it all, Grails uses the standard servlet API, and we place a lot of stuff in the session (mainly because we use Spring Webflow for a lot of our core functionality). This means that we have to use session affinity in the loadbalancer, but it would be nice to move to a completely (or at least more) stateless approach where any request can hit any frontend – this would also make zero downtime deployments easier.
Doing this would probably require us to rewrite our usage of Webflow – this might be a good idea no matter what, since Webflow and Ajax really don’t fit very well (mainly because the Grails bindings for Webflow are somewhat… lacking).
The downsides
Since we started using Grails, a number of frameworks have become quite popular, but we haven’t really regretted choosing Grails. Not all is good, though:
- As long as you walk the approved path, everything is good. Move too much outside, and you might end up fighting more than you thought.
- Being Groovy, there’s not much IDE support. Eclipse/STS has improved, but the codebase does show signs that we are not quite comfortable doing bigger refactorings, since it might break some little used functionality somewhere
- The templating engine (GSP) can just render HTML. We can abstract HTML generation into taglibs, but there’s no actual component structure. This makes it somewhat hard to reuse code properly in an OO fashion. One quick example: Let’s say you have a two-column layout, which is implemented using a couple of divs with some classes on. Now, it would be pretty nice if you had that as a component, where you can set the left and the right column contents. Not possible with GSPs, at least not without doing all kinds of trickery. This means that there is a lot of repetition all over the place, which again makes refactoring quite hard.
- If you don’t set some standard ways of doing common things, the codebase will become very messy. Fortunately, we haven’t really been hit by this, but that’s because we have very strict rules on how to do Javascript, how controllers/actions/views are organized, how translations are done, and so on.
Besides these points, however, we’re still quite satisfied with using Grails. Of course, somebody always want to change to Node.js, and we might even do that at some point, but right now, there’s no real reason to do that. If and when we change to something else, it will probably be because we want to move more logic into the client, which means Javascript, and which means rendering HTML in Javascript instead of GSP. We’re doing some experiments on this, but a lot of stuff is missing from Javascript: a decent rendering engine, a decent i18n framework, decent number handling, and so on. I’ll probably get into some of the details in our Grails/Javascript integration in a later post.
Crashes
Finally, a little note on stability. Our Grails installation has been running quite smoothly since the beginning. We have only had two real incidents:
- We use gettext for i18n. For the Grails integration, we use the i18n-gettext plugin. It turned out, however, that it had a quite serious memory leak, which basically meant that it would take up all memory within a couple of hours. We patched the issue and reported it to the plugin author, and we haven’t seen that issue again since then.
- We added push notifications, but it turned out that some versions of IE triggered some bad behavior in Jetty. This caused the request thread pool to fill up, causing timeouts.
None of these two incidents are really due to Grails itself, so it’s safe to say that Grails itself runs quite well.
Things we hadn’t expected
When we started using Grails, we naturally expected a lot of stuff to just work. That turned out not quite to be the case – some of it due to the fact that we don’t use Gorm, some of it because of somewhat lousy plugins, and some of it just because that’s how Grails is. No matter what, here is a short list of stuff we have been using more time on than we had expected:
- Translations. We use the i18n-gettext plugin, but it’s really not very good at scanning, so we have ended up writing our own script which modifies the GSP/Groovy files so that the xgettext scanner is better at picking up strings. Unfortunately, it’s still not perfect.
- Data binding. We use the extended-databinding plugin, but even then binding complex structures into objects isn’t always simple, and type conversion can be somewhat of a hassle.
- Forms: We have written a complete form taglib ourselves, which build on top of the built in taglibs. However, we have had to do all the EL stuff ourselves, as Grails doesn’t really understand stuff like <g:textField name=”customer.address[street]”>
- Javascript integration. We use jQuery, but not in the way Grails wants, so we don’t use any of the built in jQuery support at all. Actually, this hasn’t caused any pain, but it’s still worth mentioning.
- Error handling and error binding. Our backend emits all kinds of errors, which sometimes need to be tied to specific input fields, typically after a POST. This is tied into our own formtaglib.
- JS/CSS compression: We use the ui-performance plugin to minify and compress Javascript and CSS, but we’ve had to write our own scripts to push the compressed files into a CDN. Unfortunately, this script has a lot of duplication from the plugin.
- Jetty: We use Jetty as web container for the frontend, but the Jetty plugin is really old, so we’ve had to patch the plugin for a newer version of Jetty.
In other words: there might be a lot of Grails plugins, but don’t assume that any of them will actually satisfy all your needs. They might, but they might also not, so watch out!
