for high performance
and reliable web
Tomas Lin @tomaslin
Goals for this talk
• Quick tour of Dropwizard functionality
written with Groovy & friends instead of
• Showcase some of the “DevOps” friendly
features in Dropwizard for easy setup,
deployment and monitoring.
This is not a talk about
• Everything I tell you about REST will
probably be a lie.
• Think JSON services over http.
REST-ful API Design - Ben Hale
Beautiful REST + JSON APIs - Les Hazlewood
• Senior Software Engineer at Netﬂix
• Grails developer since 2008
• Takes mature, well known Java frameworks
and glues them together.
• Jetty for HTTP
• Jersey for REST
• Jackson for JSON
• Metrics for metrics
• Etc. ( Logback, Hibernate, Liquibase, etc )
Who uses Dropwizard?
Fraud Detection & Gift Card
Fault Tolerant Job Scheduler
Carl Quinn : Dropwizard +
Netﬂix OSS tools
Dropwizard + Groovy?
• Bloom Health - Insurance carriers data exchange.
Spring Batch, Dropwizard and Groovy.
(25x faster than previous system)
• Sky Find and Watch - Powers the remote record /
watch now functionality
• UnderwriteMe - Watch Marcin’s talk!
Dropwizard + Groovy?
• Editorial Expansion - Time inc. subsidiary in Mexico
Gourmet Awards iPhone app backend.
• By Kyle Boon from Bloom Health
• Available via Lazybones template tool by
• You can get Lazybones via gvm
• Gradle build
• Spock tests
• Hibernate persistance layer
• Fat Jars via Shadow ( like Maven’s Shade )
• CodeNarc for clean code
• Cobertura for test coverage
• Test the application ./gradlew test
• Build a Jar ﬁle for deploy ./gradlew shadow
• Drop a database ./gradlew dropAll
• Setup database ./gradlew migrate
• You can add your own like deployToCloud
• Like an Application in Grails
• Central place where all the other building
blocks are connected.
• The Dropwizard approach to services lets
us see one place where all our other
components are bound and glued together.
• Relationships between other parts must be
explicitly declared. There is no magic
• Each service has a conﬁguration that is
passed into the run method.
• Dropwizard has default conﬁgurations for
clients, logging and Jetty that can be
Same jar ﬁle, conﬁguration is externalized.
java -jar application.jar server test.yml
java -jar application.jar server stage.yml
java -jar application.jar server prod.yml
• Conﬁgurations are vital because they allow
us to make sure we got all the details for
our service right.
• One conﬁg ﬁle instead of merged conﬂict
from many sources eliminates confusion
and makes it easy to automate / swap out.
• Represent a set of service endpoints
• Like Controllers in Grails
• They are just Jersey Resources:
• Tested not as Unit mocks, but as Jersey
components with a real Jersey server.
• Similar to the FakeServer in Grails Rest Client
• Dropwizard comes with a ResourceTest that
works with Mockito / JUnit
• I wrote a Spock equivalent available at http://
• Lets you formally describe the data ﬂowing
in and out of your REST API.
• Data Transfer Objects that can be validated.
• It gives you a way to easily map them into
your database objects either directly or via
• Recommended approach is to share
representations between servers and
• The use of representations ensure the
contract between our REST endpoints and
clients that consume this endpoint.
• You could also just skip this and go straight
to your other endpoints or JSON friendly
• They are ﬁrst class citizens within
• Very ﬂexible.You can deﬁne custom
metrics, set Gauges, etc.
• It’s about communicating the actual state of
your server back to the mothership so it
can be coordinated.
• Dropwizard has a pretty robust default
• We can use the @Slf4j annotation in Groovy
• I am lazy.
• Don’t realize logs are needed until it is too
• Logs are time machines to past
malfunctions, making them easy to set up
allows us to use them.
• Dropwizard has available both the Apache
HttpClient and the Jersey Client.
• Jersey Client can use same deserialization
available to the server
We can now use the client within the
Resource to fetch http data from other sources
• Returns a fully wrapped object that emits
metrics. This allows us to monitor how
they are used and identify bottlenecks or
• Classes that have a start and end phase
attached to the service.
• Often have their own conﬁgurations.
• Easy way to encapsulate integrations into
other services / systems.
• Runtime checks that the service is
• If an exception is thrown, this is shown on
the health monitoring screen
• Also throws a 500 error code on the
health check page for tools
• Quick diagnostics on running instance.
• Better to kill a sick service than to keep it
running and potentially corrupting your
• Also helps when you are deploying and
building out your infrastructure.
• Tasks - Like Grails Scripts
• Commands - Jobs that can be invoked via
an URL. Lots of power since you’re using
the same stack as your runtime service.
• Others - Filters, Bundles, etc.
Make Jars, not Wars
One jar ﬁle from CI to deploy
• Dropwizard Plugin by Burt Beckwith
• Health Control Plugin by Kim Betti
• Validate Conﬁg Plugin by Andy Miller
• Metrics Plugin by Jeff Ellis
• Less verbose objects. Can use map
• Nice annotations for logging.
• Gradle / Spock / Betamax / Lazybones.
• Not sure if @CompileStatic has any changes
that are signiﬁcant - 6%
[ http://kyleboon.org/blog/2013/09/26/doescompile-static-make-your-website-faster/ ]
• A lot faster since there is very little magic
and user interface to test.
• Excellent support in IntelliJ for Gradle
project and tasks.
• Think about the deployed application.
• Grails + Dropwizard. Not Grails or
• This is just mini-scale. What happens when
you have 100 services/servers? 1,000?
1,000,000? ( Come work at Netﬂix! )
• Email : firstname.lastname@example.org
• Twitter : @tomaslin
• Slides will be posted on my blog: