The Dropwizard Stack

Dropwizard provides some very intuitive abstractions on top of these powerful libraries to make it very easy to write productionready microservices:

• Jetty for the servlet container
• Jersey for the REST/JAX-RS implementation
• Jackson for JSON serialization/deserialization
• Hibernate Validator
• Guava
• Metrics
• Logback + SLF4J
• JDBI for dealing with databases

Dropwizard is very opinionated in favor of “just get to writing code.”

The trade-off is if you want to tinker with the underlying stack, it’s not very easy. On the other hand, getting up and running quickly so you can delivery business value is much easier than configuring the pieces yourself. Jetty, Jersey, and Jackson are well-known, production-grade libraries for writing REST-based services. Google’s Guava library is around to provide utilities and immutable programming. The Dropwizard Metrics library is a very powerful metrics library that exposes more than enough insight to manage your services in production. In fact, the Metrics library is so powerful and popular it was spun out into its own projectand can be used with Spring Boot or WildFly Swarm.

Dropwizard exposes the following abstractions with which a developer should be familiar. If you can understand these simple abstractions, you can be very productive with Dropwizard:

Application

Contains our public void main()

Environment

Where we put our servlets, resources, filters, health checks, tasks, commands, etc.

Configuration

How we inject environment- and application-specific configuration

Commands

Tells Dropwizard what action to take when starting our microservice (e.g., start a server)

Resources

REST/JAX-RS resources

Tasks

Admin tasks to be performed when managing the application (like change the log level or pause database connections)

When you run your Dropwizard application out of the box, one Jetty server gets created with two handlers: one for your application

(8080 by default) and one for the administration interface (8081 by default). Dropwizard does this so you can expose your microservice

Dropwizard for Microservices

without exposing administration details over the same port (i.e., can keep 8081 behind a firewall so it’s inaccessible). Things like metrics and health checks get exposed over the admin port, so take care to secure it properly.