I just rolled off a project where I chose to use Spring Boot to create a number of microservices. I have also written a number of Dropwizard services, and wanted to compare the two while they were fresh in my mind.
They have a number of similarities, of course. Both Spring Boot and Dropwizard create standalone jarfiles that can be deployed without needing a container. Both favor convention over configuration and want to help you do the right thing out of the box. Both are java based. Both have monitoring, health checks, logging and other production nicitiies buit-in. Both are opinionated–making a lot of choices for the developer, rather than forcing the developer to choose. Both make it easy to leverage existing libraries. Both have a focus on performance.
However, there were a number of reasons I choose Spring Boot over Dropwizard for the recent project, and these highlight the differences. The first is that dependency injection is built into Spring Boot in a way that it simply isn’t with Dropwizard. Of course, there are third party solutions for bolting DI onto Dropwizard, but we also needed a java DI framework that would handle lifecycle events, which pretty much means Spring. Finally, this project wasn’t all about REST services, and while Dropwizard has some support for other types of services, it really is designed as a performant HTTP/REST layer, and certainly almost all the questions about Dropwizard online are about REST and APIs. Spring Boot, on the other hand, aims to provide support for a plethora of different types of services. Plus, you can leverage the rest of the large Spring codebase.
There are some other differences as well. Dropwizard uses shading to build fat jars while Spring Boot uses nested jars. As far as support, Spring, as usual, wins on the documentation front, with loads of accurate docs. But Dropwizard definitely has a larger community around it (compare the activity of the DW google group to the Spring Boot forums).
If you are writing a REST API in Java, Dropwizard is a great choice (here’s a review of other options I did a few months ago). If you want to build microservices that integrate with other types of components (queues, nosql, etc), Spring Boot is what I’d recommend.
Update 12/8: Per this tweet, the spring forums aren’t used because of spam, but you can find plenty of support on StackOverflow with questions tagged ‘spring-boot’.
Dropwizard 0.8 (Actually in Release Candidate) has DI with HK2 (https://hk2.java.net).
Hi — I work for Pivotal. Our forums we decomissioned a long time ago are there in read-only mode so any comparison you’ve made there is simply inaccurate.
If you are trying to compare metrics – recommend you compare DW mail list  (not google group) to metrics like # of SO questions tagged it’s clear boot is 2x-4x the user base.
DW has a few more stars in GH, but boot has more forks.
DW 1284 mail threads, SB about 2202 SO questions tagged, but sadly I don’t have time to filter out any DW emails like announcements etc that don’t originate from the community, and therefore likely aren’t an indicator of community usage. This seems to roughly correlate with Google Trends , indicating somewhere between 2x – 4x the user base.
Hopefully you’ll consider editing the article to accurately represent this.
Boot was created much more recently so keep that in mind.
Thanks for the updated numbers. It’s hard to gauge community support, but I think that Google trends and the other resources you pointed to are a good start. Plus, as I mentioned in the post, it really isn’t an apples to apples comparison except in the narrow (but prevalent) case of creating REST APIs.
Appreciate the feedback.
Thanks Remi! I hadn’t heard of HK2, definitely seems like it is worth a look.
thanks for acknowledging the apples to apples bit. In addition to wider use case landscape, I think another fact people overlook is the ubiquity of the Spring DI mechanism underpinning that wider use case landscape.
With DW you can get DI from external sources like Guice or HK2 as Remi above mentions, but if DW ever did more than just REST – the DI support would be at risk.
With Spring Boot, it’s the same DI container for Social/OAUTH, integration, batch processing, contract-first webservices, NoSQL/RDBMS access, etc etc