This document provides an overview of using Dropwizard, a Java framework for building production-grade RESTful web services, with Groovy. It discusses how Dropwizard combines popular Java libraries and frameworks, highlights some companies using Dropwizard with Groovy successfully, and describes key parts of a Dropwizard application like configurations, resources, representations, metrics, and deployment. The document emphasizes how Dropwizard enables service-oriented architectures and provides advantages like performance, testability, and easy deployment.

1. Groovy with
Dropwizard
for high performance
and reliable web
services
Tomas Lin @tomaslin

2. !
Goals for this talk
• Quick tour of Dropwizard functionality
written with Groovy & friends instead of
pure Java.
• Showcase some of the “DevOps” friendly
features in Dropwizard for easy setup,
deployment and monitoring.

3. This is not a talk about
REST Services
• Everything I tell you about REST will
probably be a lie.
• Think JSON services over http.

4. REST Services
REST-ful API Design - Ben Hale
https://github.com/nebhale/spring-one-2013/tree/master/
rest-ful-api-design
Beautiful REST + JSON APIs - Les Hazlewood
http://www.slideshare.net/stormpath/rest-jsonapis

5. whoami
• Senior Software Engineer at Netflix
• Grails developer since 2008

6. What is Dropwizard?

7. http://gunshowcomic.com/316

8. http://www.dropwizard.io

9. Dropwizard stack
• 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 )

10. Additional Integrations
• Scala
• Views ( Freemaker / Mustache )
• Liquibase migrations
• Authentication ( http and oAuth2 )
• Dropwizard Spring - https://github.com/
SindicatoSource/dropwizard-spring

11. Who uses Dropwizard?
Fraud Detection & Gift Card
Services
Fault Tolerant Job Scheduler
https://github.com/airbnb/chronos
Carl Quinn : Dropwizard +
Netflix OSS tools
http://tekconf.com/conferences/
codemash-2014/how-we-built-acloud-platform-at-riot-games-u

12. 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!
http://skillsmatter.com/podcast/home/moderngroovy-enterprise-stack

13. Dropwizard + Groovy?
• Editorial Expansion - Time inc. subsidiary in Mexico
Gourmet Awards iPhone app backend.

14. Why should I try
Dropwizard?

15. Enable Service
Oriented Architecture

21. Advantages
• Scale up only some parts of your
application.
• Isolate services based depending on their
security profiles.
• Fault tolerance.
• Cloud friendly!

22. vs.
—-
+

23. vs.
—-
+

24. Dropwizard with Grails at Sky Find and Watch

25. Performance
Dropwizard is a very high performance, low latency
framework.
http://www.techempower.com/benchmarks/

28. Other niceties
• Testable. Every part of the system can be
tested during development.
• Deployment friendly - easy to configure,
deploy and monitor.
• Pure Java.

29. Getting Started
with Dropwizard
and Groovy

30. Lazybones Starter
Template
• By Kyle Boon from Bloom Health
• Available via Lazybones template tool by
Peter Ledbrook
• You can get Lazybones via gvm

31. Lazybones Starter
Template
• Gradle build
• Spock tests
• Hibernate persistance layer
• Fat Jars via Shadow ( like Maven’s Shade )
• CodeNarc for clean code
• Cobertura for test coverage

33. Tasks
• Test the application ./gradlew test
• Build a Jar file for deploy ./gradlew shadow
• Drop a database ./gradlew dropAll
• Setup database ./gradlew migrate
• You can add your own like deployToCloud

34. Parts of a Dropwizard
Application

35. Banner
src/main/resources/banner.txt

37. Services
• Like an Application in Grails
• Central place where all the other building
blocks are connected.

40. Services
• 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
linking.

41. Configurations
• Each service has a configuration that is
passed into the run method.
• Dropwizard has default configurations for
clients, logging and Jetty that can be
overwritten

42. Configurations
Same jar file, configuration is externalized.
!
java -jar application.jar server test.yml
java -jar application.jar server stage.yml
java -jar application.jar server prod.yml

43. Configurations
gradleplugins/src/main/groovy/com/tomaslin/gradleplugins/
GradlePluginsConfiguration.groovy

44. Configurations

45. Configurations

46. Configurations
add to .yml file

47. Configuration
• Mapped by Jackson. Uses Hibernate Validator.
• @Max / @Min
• @NotNull
• @Size(min=0, max=50)
• @Pattern(regex=, flag=)
• @Future / @Past
• @NotEmpty
• @CreditCardNumber

48. http://docs.jboss.org/hibernate/validator/4.2/reference/enUS/html_single/#validator-defineconstraints-builtin

49. Nesting Configurations

51. vs. Java version

52. Configurations
• Configurations are vital because they allow
us to make sure we got all the details for
our service right.
• One config file instead of merged conflict
from many sources eliminates confusion
and makes it easy to automate / swap out.

53. Resources
• Represent a set of service endpoints
• Like Controllers in Grails
• They are just Jersey Resources:
https://jersey.java.net/nonav/documentation/
latest/user-guide.html#jaxrs-resources

54. Resource

55. Resources
• @GET, @POST, @PUT, @DELETE,
@HEAD, @OPTIONS, and even
@HttpMethod
• @Path("/{user}/notifications")
@PathParam("user") LongParam userId,
@QueryParam("count")
@DefaultValue("20") IntParam count

56. Resources

57. 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://
fbflex.wordpress.com/2013/01/30/dropwizardwith-spock-and-groov/

59. Resources

60. In your IDE

62. Representations
• Lets you formally describe the data flowing
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
a DAO.
• Recommended approach is to share
representations between servers and
clients.

70. Representations
• 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
database.

71. Caching

72. Metrics
• Uses Coda Hale’s own Metrics Library
• Integrates with JMX, http, Ganglia and
Graphite

73. Metrics
@Timed - duration and rate of events
@Metered - rate of events
@ExceptionMetered - rate of exceptions

74. Metrics

75. Kim Betti
Dropwizard
Dashboard with
Vert.x
https://github.com/
kimble/
dropwizarddashboard

76. Metrics
• They are first class citizens within
Dropwizard.
• Very flexible.You can define custom
metrics, set Gauges, etc.
• It’s about communicating the actual state of
your server back to the mothership so it
can be coordinated.

77. Logging
• Dropwizard has a pretty robust default
logging configuration.

78. Logging
• We can use the @Slf4j annotation in Groovy

79. Logging

80. Logging
• I am lazy.
• Don’t realize logs are needed until it is too
late.
• Logs are time machines to past
malfunctions, making them easy to set up
allows us to use them.

81. Client Support
• Dropwizard has available both the Apache
HttpClient and the Jersey Client.
• Jersey Client can use same deserialization
available to the server

83. We can now use the client within the
Resource to fetch http data from other sources

84. Clients
• Returns a fully wrapped object that emits
metrics. This allows us to monitor how
they are used and identify bottlenecks or
bugs.

85. Managed Objects
• Classes that have a start and end phase
attached to the service.
• Often have their own configurations.
• Easy way to encapsulate integrations into
other services / systems.

88. Health Checks
• Runtime checks that the service is
operating correctly
• 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

93. Health Checks
• Quick diagnostics on running instance.
• Better to kill a sick service than to keep it
running and potentially corrupting your
data.
• Also helps when you are deploying and
building out your infrastructure.

94. Other Features
• 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.
http://www.dropwizard.io/manual/

95. Deployment
Make Jars, not Wars
One jar file from CI to deploy

96. Deploying Dropwizard
java $JAVA_OPTS -Ddw.http.port=$PORT
-Ddw.http.adminPort=$PORT -jar application.jar
server prod.yml

97. Grails Equivalents
• Dropwizard Plugin by Burt Beckwith
http://grails.org/plugin/dropwizard
• Health Control Plugin by Kim Betti
http://grails.org/plugin/health-control
• Validate Config Plugin by Andy Miller
http://grails.org/plugin/validate-config
• Metrics Plugin by Jeff Ellis
http://grails.org/plugin/yammer-metrics

98. Using Groovy
• Less verbose objects. Can use map
constructors.
• Nice annotations for logging.
• Gradle / Spock / Betamax / Lazybones.
• Not sure if @CompileStatic has any changes
that are significant - 6%
[ http://kyleboon.org/blog/2013/09/26/doescompile-static-make-your-website-faster/ ]

99. Development
• A lot faster since there is very little magic
and user interface to test.
• Excellent support in IntelliJ for Gradle
project and tasks.

100. Final Thoughts
• Think about the deployed application.
• Grails + Dropwizard. Not Grails or
Dropwizard.
• This is just mini-scale. What happens when
you have 100 services/servers? 1,000?
1,000,000? ( Come work at Netflix! )

101. Thank you
• Email : tomaslin@gmail.com
• Twitter : @tomaslin
• Slides will be posted on my blog:
• http://bit.ly/tomaslin