Dropwizard and Spring Boot

spring_to_dropwizardI recently accepted a position as a developer in a shop that uses Dropwizard for wiring up REST APIs, using Google’s Guice as an IoC container.  You can read more on Inversion of Control here.  So I had to take a step back and understand what I was working with, relative to what I was accustomed to using.

I have spent the majority of my Web development career working with and evangelizing the Spring Framework.  More recently, I’ve fallen in love with Spring Boot.  You can read more about Spring Boot here.  If you develop Spring applications, this is a must have for all your development projects.

Although a little dated, Josh Long gives a great introduction to the Spring Boot framework and how it works in this YouTube video. Although what isn’t dated in our world within weeks?

This post will help to convey my humble views on the Dropwizard and Spring Boot lightweight frameworks.  Both are open source and can be found here: Dropwizard and Spring Boot.  When discussing these frameworks, I will contrast them using these categories:

  • Ease of configuration
  • Module Support
  • Testing
  • Health Metrics
  • Deployment
  • Community Support

Ease of configuration

codeIn general, developers like tinkering with new libraries and understanding/configuring each to work optimally with their environment, but we sacrifice a lot of time to do that.  Time away from our significant others, time away from our kids, time playing around with code late at night, time…, time…, time.  So to get back some of that time in our lives, we look to frameworks to help us from making that initial investment.  In particular, Dropwizard and Spring Boot favor convention over configuration.

For instance, rather than understanding whether to go with pure JAX-RS or the awesome Jersey implementation/superset of JAX-RS, Dropwizard and Spring Boot make that choice for you.  And they work without you needing to tinker around with either library.  And that goes for everything else: Which version of Hibernate to use?, Which JSON library will I need?, which version of each makes nice with one another?, etc.

You can use either Spring Boot or Dropwizard to get things off the ground quicker.  Once you’re up and running, either framework doesn’t care if you tweak it here and there.  For instance, using version X of the Jersey library, or version Y of the hibernate framework, etc.  Getting it to work at that point becomes the same exercise we face with all other implementations.  But if you don’t care about specific library versions for some type of customized functionality, you’re good to go.

chariots_still_wide2_720However, based on my own experiences with both frameworks, Dropwizard takes more of an initial investment. As outlined in its get started guide, it requires the use of YAML formatted property files to define an application configuration. This file is then used in the application configuration class, which specifies environment-specific parameters. That class is then used in an application class, where the environment variables from the configuration class described are used.

In Spring Boot, you only need to create property files specific to the type of environment configuration that you need. Even then, they are simple key=value property files. Spring Boot itself does not require any specific configuration, outside of an Application class that it also requires, which is comprised of a main method to execute your application from the command line.  You can find a plethora of Spring Boot getting started guides here.  However, most of its configuration stems from annotations that you use with a Spring Java configuration, unless you want to go with the more verbose XML configuration.  Since servlet 2.5, the Java community has been configuring Spring applications via Java ckasses and annotations, like @Controller and @Service.

Moreover, property files are used by the Spring Boot framework to create proxy objects that are used within your application, without the need for you to create resource or configuration classes to make them active/work.

To truly compare, I urge you to create a mock end-to-end REST API with both frameworks to judge for yourself.  But Spring Boot generally is easier to configure, in my humble opinion.

Module support

officeSpacePrinterDropwizard only helps you to configure a RESTful project.  Spring Boot helps you to configure multiple project types, anywhere from Docker deployment to accessing social APIs.

Spring Boot has a robust set of tutorials for all of their 3rd party libraries, currently over 60, here.  There’s barely a Web technology you can name that doesn’t have Spring Boot integration.  One interesting Spring Boot project worth mentioning is JHipster, a Yeoman generator for Spring Boot and Angular.

Furthermore, if there would be only one reason to use the Spring framework, it would be for its transaction management.  Dropwizard does not support and/or actively contribute to a robust transaction management library.  Spring Boot helps configure the Spring transaction library within Spring Core.  You can read more about the Spring transaction library here.

Dropwizard has many 3rd party libraries, also over 60, located here.  Anywhere from Google Guice integration, an IoC library, to MongoDB libraries.  However, they are all centered around RESTful Web services.

Any transaction management or other such library support with Dropwizard would have separate methods of implementation, whose configuration may not necessarily be consistent with one another.  So then you’re back to juggling multiple libraries and defeating the purpose of using a “bootstrap” toolkit like Dropwizard.

Testing

docFor their testing framework, the Spring Boot test library uses:

  • Sprint Test – Integration test support for Spring applications
  • JUnit – The de-facto standard for unit testing Java applications
  • Hamcrest – A library of matcher objects (also known as constraints or predicates) allowing assertThat style JUnit assertions
  • Mockito – A Java mocking framework

Dropwizard uses:

  • JUnit – The de-facto standard for unit testing Java applications
  • AssertJ – Java library that provides a fluent interface for writing assertions

Both test libraries provide the work that most Web projects need, however Spring Boot clearly has more options, out of the box, as listed above.  Although these same libraries can be added to a Dropwizard project’s dependency list, you are manually wiring up your project, defeating the point of using this type of framework.

Health metrics

houseSpring Boot has a metrics endpoint library, called the Spring Boot Actuator, providing a 16 endpoints that allow you to monitor your project in production, such as beans currently loaded/running , memory footprint metrics, and configuration properties, just to name a few.

Dropwizard provides health metrics, again allowing you to monitor your application in production.  It also integrates with over 20 services, like Graphite or Ganglia.

Both frameworks have excellent support for viewing the health of an application in production.

Deployment

indianajonesidolswapThe key driver of both frameworks have been the notion of container-less Java HTTP servers. They are straightforward and easy to update, without the need to deal with WAR files.  However, you can certainly configure and build your project as a WAR file, but it is not needed to run, with either Spring Boot or Dropwizard.

Both Dropwizard and Spring Boot make use of fat JAR files, which contain all the dependencies needed to run the application/project.  This makes projects easier to deploy, using one-line commands, i.e. java jar <jarName>.jar <parameters>.

Both frameworks do well in this category.

Community Support

Dropwizard was initially released in 2011, releasing over 65 versions. The latest version, as of the writing of this post, is 1.0.0 RC2. A comprehensive list of Dropwizard 3rd party modules can be found here.  Please also see the official Dropwizard user group here.

However, its commits seem not as active since its initial release, as evidenced by their Github contributions.

DropwizardCommits

Spring Boot’s open source project started in 2012, enjoying a much more active community, as outlined here in its library contributions, having over 55 releases since its inception in 2012.

SpringBootCommits

Conclusion

springbootIf you’re in a domain where memory or disk footprint/size is crucial, then you want to leverage Google Guice’s IoC library, which along with Dropwizard, has a small memory footprint.  Environments like an Android device or other such embedded systems would be ideal for the Dropwizard framework.

However, if you are building large-scale Web applications with the need to implement additional business logic or 3rd party modules over time, Spring Boot is a clear winner to me, due to these categories:

  • Ease of configuration
  • Module Support
  • Community Support

Both frameworks have great testing libraries, as well as health libraries to monitor applications in production.  They both also make deployment easier, with fat JAR files containing all the dependencies needed to run the application.

When determining your Web API or Web application requirements, the Spring framework has consistent configuration across multiple, 3rd party libraries, and Spring Boot allows for easy wiring of the various Spring framework modules.

dropWizardDropwizard module support is limited to RESTful API implementations, its configuration is not consistent across multiple 3rd party libraries, and it does not enjoy the community support enjoyed by Spring Boot users.

Please feel free to set me straight on anything I might have missed or misunderstood with either framework, via the comments below.

Aggregation of interesting links in this post:

 

 

About Rick

I am a father, husband and software engineer, trying to stay active, both in my personal and professional communities. I enjoy programming and building Web applications.
This entry was posted in java, REST, Spring, Web. Bookmark the permalink.

One Response to Dropwizard and Spring Boot

  1. Pingback: Aspect Oriented Programming | Rick's Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s