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
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 )
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.
21. Advantages
• Scale up only some parts of your
application.
• Isolate services based depending on their
security profiles.
• Fault tolerance.
• Cloud friendly!
25. Performance
Dropwizard is a very high performance, low latency
framework.
http://www.techempower.com/benchmarks/
26.
27.
28. Other niceties
• Testable. Every part of the system can be
tested during development.
• Deployment friendly - easy to configure,
deploy and monitor.
• Pure Java.
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
32.
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
37. Services
• Like an Application in Grails
• Central place where all the other building
blocks are connected.
38.
39.
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
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
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/
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.
63.
64.
65.
66.
67.
68.
69.
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.
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.
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
82.
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.
86.
87.
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
89.
90.
91.
92.
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/
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