ratpack for real

Ratpack for Real

@TomAkehurst

Me @TomAkehurst tomakehurst

ENERGIZED WORK / Metal Box Factory Unit 323 30 Great Guildford Street London SE1 0HS / www.energizedwork.com

!!!

Ratpack!!

Ratpack

• Fully async web toolkit • Java and Groovy • App, rather than infrastructure centric (in contrast

with vert.x) • Built with developer productivity in mind • Small, modular, composable • Builds to self-contained binaries !!

Ratpack

• Layered configuration from JSON, YAML, system props, environment etc.

• Non-blocking HTTP client • Gradle plugin • Library integrations:

• Jackson, Dropwizard Metrics, Handlebars, Hystrix + more

• Backed by Netty !!!

Why Ratpack?

• Low latency • Efficiency • Modern developer experience !!!!


!!!

A Quick Tour of Ratpack!!

Ratpack Tour

• Handler abstraction for HTTP !!!!

Ratpack Tour

• Handler abstraction for HTTP • Promises for async programming !!!!

Ratpack Tour

• Handler abstraction for HTTP • Promises for async programming • RxJava integration !!!!

Ratpack Tour

• Handler abstraction for HTTP • Promises for async programming • RxJava integration • Typesafe Groovy DSL !!!!!

Ratpack Tour

• Handler abstraction for HTTP • Promises for async programming • RxJava integration • Typesafe Groovy DSL

• Or a pretty neat Java 8 one if you prefer

!!!!


!!!

Testing!!

Testing

• ExecHarness for running async operations outside of Ratpack !!!!!

Testing

• ExecHarness for running async operations outside of Ratpack

• EmbeddedApp / GroovyEmbeddedApp for configuring apps inline !!!!

Testing


• EmbeddedApp / GroovyEmbeddedApp for configuring apps inline

• *ApplicationUnderTest for running your app from within a test class !!!!

Testing


• EmbeddedApp / GroovyEmbeddedApp for configuring apps inline

• *ApplicationUnderTest for running your app from within a test class

• RequestFixture / GroovyRequestFixture for unit testing Handlers !!


!!!

The Execution Model!!

The Execution Model

• Small number of threads compared with blocking servers • 1 compute thread per CPU core

• Synchronous I/O (e.g. JDBC) done in separate “Blocking” thread pool

• Compute threads never block (unless you’ve done it wrong!) !!!

The Execution Model

• Promises are delivered lazily on completion of the defining block

• Execution segments are always executed on the same compute thread, in the sequence they were defined

• Therefore OK to mutate local, non-threadsafe data

• But concurrency within a single request can be tricky

• Promises are not memoised by default


!!!

Adoption at Pottermore!!

Adoption at Pottermore - Context

• Official Harry Potter site - big traffic spikes • Originally assumed to be highly personalised and

therefore non-cacheable • But ended up (initially) being mostly public/

anonymous !!!!

Adoption at Pottermore - Context

• Deployed on Heroku • TDD and Continuous Delivery practiced • Majority of team from a Groovy + Grails and/or

Node background • Integration with CMS REST API !!!!

Adoption at Pottermore - Successes

• Up and running quickly with Lazybones and Gradle

• Fast builds • Tight developer workflow - fast feedback • Reduced latency via concurrent REST calls • Easy deployment to Heroku • Content editor feature with websockets !!

Adoption at Pottermore - Challenges

• Breaking changes (our fault for using < v1.0!) • Surprisingly steep learning curve

• Harder to do async programming in a language that’s usually synchronous

• Not much community to lean on yet • Promises knowledge not particularly portable from Node • Forces you all-in on NIO

• Finding the right patterns (or the wrong ones) by trial and error !!

Adoption at Pottermore - Challenges

• Breaking changes (our fault for using < v1.0!) • Surprisingly steep learning curve

• Harder to do async programming in a language that’s usually synchronous (according to the Node devs!)

• Not much community to lean on yet • Promises knowledge not particularly portable from Node

• Finding the right patterns (or the wrong ones) by trial and error

• Off-heap memory leak - yikes! • Netty ByteBuf allocates pooled, off-heap memory • Relies on reference counting to manage pooled buffers


!!!

Conclusions!!

Conclusions

• Great choice if you need high performance but don’t want to sacrifice developer experience

• Not the best choice for apps with more ordinary workloads

• Take the time to understand it properly before writing significant production code • Don’t attempt without at least some FP literacy • Don’t be tempted to write sync code and refactor to async!

!!


!!!

Ta!!!!!

@TomAkehurst!https://github.com/tomakehurst/ratpack-presentation-examples

https://github.com/tomakehurst/ratpack-presentation-examples

ratpack for real

Technology