Dropwizard and Groovy
•
13 likes•12,380 views
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.
Report
Share
Dropwizard and Groovy
- 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
- 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?
- 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
- 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
- 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
- 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
- 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