Java Bootstrap: Dropwizard vs. Spring Boot
I’m not a morning person, so sometimes it takes a while for the “all systems are go” cue to kick in. This used to be true for Java applications until not too long ago, but unlike the invention of the snooze function on the alarm clock, the solution we’re going to discuss here actually makes much better sense. With modern open source frameworks like Dropwizard, Spring Boot, Groovy’s Grails and Scala’s Play! you’re able to build a production ready application from scratch in a matter of minutes. Even if you’re not a morning person. And even if you’re not fond of wizard hats. In this post we’ll discuss the similarities and differences of the lightweight Java based frameworks with Dropwizard and Spring Boot.
Psst! Whether you decide to go for Dropwizard or Spring Boot, make sure you have what you need to maintain application quality. OverOps tracks software quality and provides actionable, code-level insight for all errors and slowdowns at all stages of the software delivery lifecycle.
The Trade-off: Freedom of choice vs. The need for speed
Either framework you go with, you’re sacrificing some freedom of choice since both Dropwizard and Spring boot are highly opinionated and strongly believe in convention over configuration. How strong? You’ll discover just that in a side by side comparison we’ve done, examining the different flavors of 3rd party libraries that each of them adds to the mix. Most if not all core features a production grade application requires come out of the box or available as integrations.
The upside of this sacrifice is speed, although it’s fun at times to fiddle around with new libraries and customize your own perfect environment. When you need to get something quickly off the ground and start rolling, you’re better off delegating those decisions and getting rid of the complexity that comes with it. It’s not exactly a blue pill vs. red pill scenario: Further down the road when you’re up and running, you will most likely be able to customize and tweak it if needed. Now just direct your favorite build tool, be it Gradle or Maven, to Dropwizard & Spring Boot and you’re good to go.
Let’s dig in and discover which aspects of each framework will leave you locked-in and where you can be more flexible.
Spoiler alert: We faced a similar dilemma here at OverOps and decided to go with Dropwizard for an on-premise flavor of OverOps for enterprises. But what once could be seen as the default (and only) choice with Dropwizard, led us to break some prejudice we had with Spring boot and exhausting XML configurations.
Dropwizard vs. Spring Boot: Who’s got your backend?
A production grade application relies on many components and each framework has made its choices for us. All the weapons of choice to get a RESTful web application off the ground are laid down right here in this table with Dropwizard in the left corner with a wizard hat and Spring Boot in the right corner with the green shorts. The core out-of-the-box libraries and add-ons are separated by color with Spring’s internal dependencies marked in white.
Ok, so now that we have a better view of the land, let’s see what this actually tells us. I’d also recommend taking a closer look at each of the frameworks, since everything is open-source and available for your viewing pleasure right on GitHub: Here are the Dropwizard source files, and here’s Spring Boot.
Spring Dependencies
Like it says on the tin, Spring Boot is focused on Spring applications. So if you’d like to get into the Spring ecosystem or already familiar with it and need to set up a quick application, this would probably be the way to go. The REST support, and DevOps features which we’ll talk about soon like metrics and health checks are based on Spring Framework’s core while DropWizard puts its REST support with Jersey. It’s pretty much the only aspect where Spring Boot leaves you locked-in, although it’s more flexible on other fronts (EDIT: JAX-RS support was added to Spring on v1.2, and can also be used with Jersey. Thanks Pieter!)
HTTP Server
Here we can see just how Spring Boot can be more flexible. Dropwizard takes the convention over configuration approach a bit more extreme than Spring Boot and is completely based on Jetty, while Spring Boot takes the embeddable version of Tomcat by default but leaves you a way out if preferer Jetty or even RedHat’s Undertow.
Logging
This is another example of the same convention over configuration issue, Dropwizard switched from log4j to Logback in v0.4. I’m guessing that with log4j2’s recent GA release, this might be subject to change (EDIT: Looks like that’s not the case, check out the comments section). On Spring Boot’s front, we need to make a choice between Logback, log4j and log4j2 if we require logging. By the way, if you’re using Logback, you can check out this benchmark we ran to compare the performance of different logging methods.
Dependency Injection
A main difference between both frameworks is dependency injection support. As some of you know, Spring’s core comes with it’s built in dependency injection support while with Dropwizard this doesn’t come out of the box and you’ll have to choose one of the community integrations that support it. A popular choice would be going with Google’s Guice, and using one of the community led integrations.
Testing – Fest vs. Hamcrest
Both frameworks have a special module for testing, dropwizard-testing and spring-boot-starter-test, including JUnit and Mockito dependencies. Spring Boot naturally uses Spring Test as well and the main difference here comes in the shape of matcher objects, checking if different objects match the same pattern. Dropwizard favors FEST matchers (which are no longer developed) (EDIT: moved to AssertJ in the latest 0.8 version) and Spring Boot goes with Hamcrest.
No Dev Without Ops
To earn the title of a production grade application, each framework’s core features include support for metrics, health checks and tasks. In a nutshell, metrics allow you to keep track of stats like memory usage and timing of how long does it take to execute areas in your code. Health checks are a way of testing on the go and answering questions like, is this socket still open? Or is the database connection alive? And with tasks support you can schedule maintenance operations or periodic tasks.
The Dropwizard metrics library gained some popularity on it’s own and you can add it to any project, or even use it with Spring Boot’s metrics, to gain insight into what your code does in production. One cool feature is reporting to services like Graphite or Ganglia and some 20+ available integrations. Health checks also come with Dropwizard metrics and tasks are implemented as part of the framework. On the Spring Boot front, the framework uses Spring’s core features to support its Ops angle.
Update (3/13/2018): As of Spring Boot 2.0, Micrometer has been introduced as an application metrics facade (just like SLF4J, but for metrics).
A note on going container-less
The key driver that enabled the creation of Dropwizard, followed by Spring Boot a few years later, are container-less Java HTTP servers. Unlike a standalone container, you can simply add an HTTP server like any other library dependency in your app. Straightforward, easy to update, and you don’t have to deal with any WAR files whatsoever. XML configurations are kept to a minimum. As to the deployment end of the story, both Dropwizard and Spring Boot make use of fat JARs to pack all JARs and their dependencies in one file, making it easier to deploy using a quick one-liner.
Community and Release Cycle
Dropwizard was initially released by Coda Hale in late 2011 back in his days at Yammer. Since then it passed some 20 versions, and currently stands on 0.8, enjoying great community support as the go-to guide for modern Java applications. On the downside, new releases are slowing down, after they used to come out every couple of months. In the latest 0.8 version we mostly see 3rd party version updates and minor fixes. Dropwizard currently supports Java 7 and above, to use it on Java 8 you can check out this partial update to enjoy some of its benefits and new features (or if you just don’t like joda-time for some reason).
(EDIT: A comprehensive list of Dropwizard modules is available right here).
Today you can see mostly commits from Jochen Schalanda (EDIT: and the 0.8 team) with over 160 individual contributors and tens of community supported integrations, like dropwizard-extra from Datasift. Of the available Dropwizard integrations, Spring support is also included. One more thing you should definitely check out is the official user group right here.
With Pivotal backed Spring Boot joining the game with a 1.0 in 2014, there are over 40 official integration (Starter POMs) to pretty much any 3rd party library you can think of. This includes anything from logging to social API integrations. One new Spring Boot project worth mentioning here is JHipster, a Yeoman generator for Spring Boot and Angular.
On the bottom line you could say that Dropwizard has a larger community around it and Spring Boot enjoys better official and structured support, together with Spring’s existing user base.
Conclusion
1. If you’re looking to get into the Spring ecosystem, then choosing Spring Boot is probably a no brainer. More than a way to bootstrap a RESTful Java application, it also acts as a gateway to Spring with integrations to tens of services. Maybe the real question here is whether you should start looking / go back into Spring? Which could be a whole other subject to discuss. Otherwise, Dropwizard would suit your needs best.
2. A second issue here is how dependent are you on dependency injection? If Guice is your choice then going Dropwizard and using one of the community integrations would be an easy fix rather than doing the Spring way of dependency injection.
3. And last but not least, taking a look at the side-by-side comparison, which framework makes the choices that you would take if you were to build an application from scratch yourself? Keep in mind the default picks since spending even more time configuring this bootstrap kind of betrays its cause.
I hope you’ve found this comparison useful and I’d be happy to hear your comments about it and the factors that made you choose one over the other.