Choosing DropWizard to deliver content within your Grails projects

In our current project, we’re using DropWizard alongside Grails. It has become a fairly significant and useful tool for building simple content delivery layers.

In this post, I will try to share some of the rationale for choosing DropWizard to serve content and how it fits within a Groovy / Grails ecosystem.

Our Current Project Architecture

We’re working on a project that will replace significant portions of an existing website. The site will have a lot of editorial content that will be aggregated with some external services provided by a few other teams.

We have a CMS component that is written in Grails and AngularJS. This component is responsible for generating static html pages into a MongoDB database. We then use DropWizard to serve these static html pages, uploaded images and do image resizing.

We also have another DropWizard component that aggregates feeds provided by other services and serves them to the requesting browser. This layer is a pure REST beast and only talks JSON.

Going Outside of Grails

Our default architecture would have been to write the entire thing in Grails. However, we were hesitant about choosing Grails due to our past experience with the framework.

I’ve been working with Grails for about five years. While it is a tremendous framework with a lot of power, there are a few areas where it sort of falls apart, specially when delivering content. We wanted a light, simple, reliable layer to push content — and Grails simply isn’t it.

One of the main problems with Grails today is that it almost encourages you to build up a large monolithic application. This creates a lot of problems when you try to scale parts of the application. What you want to do is to break down your application into smaller, more manageable components that can be replaced or swapped out when better technologies come along. ( For a good primer on the topic, check out Chris Richardson’s talk on Decomposing Web Applications for Scalability ).

For our application, we really wanted to separate the layer that is responsible for editing and writing the data with the layer that is responsible for serving it. Grails is a perfect fit for a CMS — it has many GORM helpers for writing/validating content written to a database and has Security Plugins up the wazoo. However, Grails is very heavy and sometimes problematic for simply serving out content.

Grails, in its current form, encourages you to use server side gsp files using flaky tools like Resources or Platform core plugin. Spring also adds a lot of weight and memory requirements that is unnecessary for a light, simple REST API. Deployment is pretty heavyweight as you need to setup a tomcat instance.

Benefits of DropWizard

While searching for viable alternatives, we stumbled upon DropWizard – a toolkit created by Coda Hale based on Java, Jersey and Jackson that has as its mission the ability to serve a ton of requests. As we investigated and spiked DropWizard, I fell in love with a few of it’s features:

Java Based – means you can easily add it to your ecosystem. It also means that you can use all the Groovy tools you know and love. The core is just a Jar file.

REST / JSON – Dropwizard core comes setup with Jackson and Jersey. This encourages an approach where you end up writing REST endpoints that serve up JSON. In our current projects, our Grails apps serve out both JSON or HTML content. This then causes problems when trying to test components in isolation. By enforcing JSON only, you are able to more easily integrate with tools like Yeoman or AngularJS since you can then mock up the backend via the tools provided by the frameworks.

Simple Deployment – Dropwizard encourages you to build fat jars that are self contained. This is very useful for building small, light services that don’t need a container to be set up. It also means that adding more instances can be done fairly easily.

No Magic – The plugin mechanism in Grails is really nice. But often it introduces bugs and often does a lot of metaclass magic that adds a lot of complexity. DropWizard encourages a NoSpring approach where you have to hand wire your dependencies and add them to your services. This gives you a lot of control over how your components interact and makes it easier to test since there are no magic methods that appear out of nowhere.

Health Checks – DropWizard has a mechanism called Heath Checks. These are essentially little tests that are ran when your service is running and can be used to verify that it is working properly when in production. There is a grails plugin called Health Control that does the same thing. I think Health Checks highlight a significant difference between Grails – a general purpose framework – and DropWizard – a framework originally intended to be used to do lots of REST calls.

Configuration Validation – Another DropWizard goodie is the built in ability to quickly switch configurations and validate each field of a service configuration. This becomes pretty important as it means that all configurations are externalized and validated. Configuration values can also be overriden by system properties and on app launch. There is a grails plugin called validated-config that provides this mechanism.

Built-in Metrics – DropWizard comes bundled with the Metrics library. This allows you to annotate service calls and performance metrics will be automatically calculated. This is very useful for services and is a feature we have yet to explore further.  There is also a grails plugin.

Test Friendly – Since DropWizard is very lightweight, tests run incredibly fast. Also, the way in which different components hook into each other declaratively meant that you could easily use Spock to mock out various components. DropWizard is significantly easier to test than a full Grails app given the limited scope of its functionality. 

FYI , the name DropWizard is based on this comic strip.

Moving DropWizard to a Groovy world

The original DropWizard project is written in Java and Maven. Most of the examples and sample code in their site is in Java. However, the ideas are easily transferrable to Groovy.

We use the fatjar plugin for gradle for assembling the jar file and extended an original gradle file found on Github to support building and running our DropWizard app.

When we started the project, we migrated the DropWizard sample POM into Gradle and added support for Spock testing. I’ve outlined our changes to support Spock in this previous blog post. This was perhaps the biggest hurdle into moving the Java app into one that supported Groovy.

We did face a significant issue when trying to bring in discrete components of our end-to-end tests, as Gradle did not support running executing external processes and waiting for them to be ready. I wrote a small plugin to get around this problem.

Once these steps were done and we started writing our application, it was very productive and fast. The significant difference in the ability to test ( ~4-8 seconds vs. ~90 seconds in our Grails app ) meant that we were able to write out these services pretty quickly.

Overall, starting to write DropWizard apps with Groovy and Gradle is pretty simple and easy to learn.

Where does Grails fit in?

To reiterate, I’m a big fan of Grails. GORM is great for dealing with data and it is my preferred framework for the big complex parts.

There are things that DropWizard doesn’t do very well. Setting up security is not as straightforward as using Spring Security. There are a lot of extensions written by third parties, but the ecosystem is not as robust as Grails. In ways, Grails is much more powerful for all the other stuff around a site — DropWizard just does the content serving and REST service part better and more elegantly.

For us, there are two main weaknesses in Grails for our purpose — The UI Layer and serving content. We overcome weaknesses in UI tooling by using Yeoman and AngularJS. We make our web services more robust by using DropWizard.

What about Ratpack?

Fundamentally, I can also see an architecture where the Grails layer gets replaced by Ratpack. But DropWizard and Ratpack seem to serve slightly different goals. Where Ratpack fits as a fairly lean layer for dynamic content that is rendered server-side that is more general purpose, DropWizard finds it’s strength in very specific JSON / REST architecture. While you can probably do the same content serving layer in Ratpack, you do then lose service-friendly features like Metrics and Health Checks. 

Summary

In this post, I have outlined an architecture where we take full advantage of Grails as a CMS engine but rely on DropWizard as the means of serving and aggregating content.

There is a plugin written by Burt Beckwith that tries to integrate the entire dropwizard framework into Grails. However, to me, it feels like the wrong approach. Grails and Dropwizard are solving different problems and they both have different strengths. It feels better to keep them separated.

With DropWizard, you have a fast, easy to develop layer that is highly testable and deployment friendly. In Grails, you can do more complex things at the cost of a more cumbersome deployment and slightly more complexity. Both can co-exist in a given architecture and they complement each other rather well.