Ratpack Web Framework

http://www.ratpack.io
Dan Woods
#ratpack #learningratpack

•  Member of the Ratpack core team
•  Work at Netﬂix
•  Writing Learning Ratpack for O’Reilly
•  Follow me on Twitter: @danveloper

•  A full-stack, high throughput, non-blocking
web framework
•  Built entirely on Java 8
•  Specialized support for writing apps in Groovy

•  Groovy has come a long way over the last few
years…
•  Static compilation and (optional) compile time type
checking
•  Excellent language for writing concise DSLs
•  DSLs can be statically compiled!
Why Groovy?

•  Groovy’s three compilation modes give
applications a lot of ﬂexibility
•  Parallels Java performance using Invoke Dynamic
or Static Compilation
•  Pick-and-choose static or dynamic, depending on
the use-case!
Why Groovy?

•  Requires Groovy 2.3.6+
•  Utilize advanced static compilation and type
checking features of Groovy, like @DelegatesTo
•  Allows you to deﬁne your application structure in a
ratpack.groovy ﬁle
Why Groovy?

@GrabResolver(name='netty', root='http://clinker.netty.io/
nexus/content/repositories/snapshots')!
@Grab('io.ratpack:ratpack-groovy:0.9.13-SNAPSHOT')!
!
import static ratpack.groovy.Groovy.ratpack!
!
ratpack {!
handlers {!
handler { !
response.send ”Hello World!"!
}!
}!
}!
Simple Groovy Script*
* @GrabResolver will not be required after 4.1.0-Beta4 is published;
* Ratpack 0.9.13 will be released on Feb 1, 2014

•  There are no plugins in Ratpack, instead the
framework provides functionality through modules
•  Modules are built in Guice*
•  DI is an abstraction in Ratpack, so even though the
framework uses Guice, you don’t have to
*
h$ps://github.com/google/guice

•  A set of composable libraries for building
unopinionated, rich web applications
•  Pick-and-choose what aspects of the
framework you want
•  No lock-in to a single way of doing things

•  Emphasis on Performance and Efﬁciency in both applications
and development experience
•  Hot reloading is available during development time
•  Beautiful development-time error pages
•  Extreme emphasis on developer testing, especially functional
and integration
•  Support for mocking nearly all aspects of the framework

Example of a development-time error:

•  Convention over conﬁguration taken too far
doesn’t let you wire things together
•  Ratpack makes wiring modules a “one-liner”, so
there’s not a lot of work to get new features
integrated
•  Out of the box support for Guice and Spring
(Spring Boot) DI

•  Gradle integration makes building robust
projects easy to do
•  Simple apps can be run entirely through
the Groovy command-line

buildscript {
repositories {
jcenter()
maven { url "http://oss.jfrog.org/oss-snapshot-local" }
maven { url "http://clinker.netty.io/nexus/content/repositories/snapshots" }
}
dependencies {
classpath 'io.ratpack:ratpack-gradle:0.9.13-SNAPSHOT'
}
}
apply plugin: 'io.ratpack.ratpack-java'
Simple Gradle Build Script*
* Ratpack 0.9.13 will be released on Feb 1, 2014

•  Any non-trivial application needs build and
packaging capabilities
•  The Ratpack Gradle plugin provides all the
ﬁxtures to support building web
application projects

•  Ratpack is built on Netty, which provides
the infrastructure for highly performant,
non-blocking networking

•  Netty is an extremely mature, super low-level
networking library
•  Excellent documentation, very involved
community
•  Heavy emphasis on high throughput and
performance

•  Netty provides the infrastructure for non-
blocking networking, but doesn’t help
much in the way of web application
structure
•  Provides an asynchronous API for working
with network data (including HTTP)

•  Computers “think” very good in asynchronous
terms; humans do not…
•  Without app structure, programming toward this
paradigm is difﬁcult
•  Ratpack ensures the most performant structures of
Netty are being utilized, while providing a sensible
app structure and programming model

•  Ratpack provides applications with a Netty-based, non-
blocking HTTP client
•  Can be used to integrate with external RESTful services
•  Utilizes the same event loop as the server, so resources
are appropriately utilized
•  Provides a robust API for programmatically crafting
requests

Above all else…
Ratpack is your
GATEWAY DRUG
to non-blocking

•  The JVM doesn’t have any concept of continuations, so
the only option we have is asynchronous APIs
•  Async APIs allow callers to provide a completion
handler (or callback), which is to be invoked when some
processing has ﬁnished
•  There is no temporal relationship between the caller
and the invocation of the callback

handler { req, res ->!
... (1) do some work ...!
!
async {!
... (2) do some async work ...!
}!
async {!
... (3) do some more async ...!
}!
!
... (4) send response ...!
}!
(1)  – Definitely finishes first
(2)  – May finish before or after (3)
and (4)
(3)  – May finish before or after (2) or
(4)
(4)  – May finish before or after (2) or
(3)
Async APIs create non-determinism in control flow

•  The temporal disconnect creates non-determinism
in request processing
•  This is a big problem for web applications, because
they demand a deterministic control ﬂow
•  Ratpack provides the concept of an Execution,
which creates determinism in asynchronous
processing

handler { req, res ->!
... (1) do some work ...!
!
async {!
... (3) do some async work ...!
}!
async {!
... (4) do some more async ...!
}!
!
... (2) send response ...!
}!
(1) – Definitely finishes first
(3) – Definitely finishes third
(4) – Definitely finishes fourth
(2) – Definitely finishes second
Ratpack creates a deterministic control flow

•  Through Ratpack’s promise API, the Execution
is able to schedule async segments to be
invoked after the handler code has ﬁnished
•  Promise API ensures that developers can work
with asynchronous processing in a sensible
way

•  In non-blocking, it is of paramount importance
to not block the thread
•  Since a single thread is handling processing
for many clients, blocking one blocks all
•  Need to adopt libraries that are non-blocking
or provide async APIs
•  This is not always practical…

•  Not all interfaces are able to be non-blocking or
asynchronous
•  Most non-blocking frameworks force you to be either
entirely async or wholesale define your handlers as
blocking
•  This is limiting and makes it difficult to work with legacy
APIs or those not crafted for non-blocking work
•  Ratpack gives you a mechanism to define blocking
execution segments in your handler code

handler(r -> (ctx) -> {
ModelDAO dao = ctx.get(ModelDAO.class);
ctx.blocking(() ->
dao.load(ctx.getPathTokens().get("id")))
.then(model -> {
... do some work with the data ...
ctx.render(model);
});
})
Handler with blocking operation

•  Blocking operations are scheduled to an I/O
bound thread pool
•  Once the blocking operation is completed,
the data is then returned to the request taking
thread, where processing can ﬁnish
•  Blocking operations are invoked when they
are subscribed to in the request-taking thread

...
ctx.blocking(() -> {
... do some blocking io ...
return result;
}).then(result -> {
... subscribe to the blocking promise ...
... process in the request-taking thread ...
})
...
Blocking with a subscription

•  Data is being delivered to web consumers in
an increasingly real time way
•  Web applications must be able to support
streaming protocols like SSE and WebSockets
•  Ratpack has built-in ﬁxtures that make it easy
to develop real-time web applications

•  Because of its non-blocking nature, Ratpack can
support a high volume of concurrent real-time
streams
•  Valuable in app-to-app communication too, where
a consumer wants to be reactively informed about
some data
•  Ratpack’s HTTP client also supports reading
streams of data from external producers, making
stream processing a great integration

•  Ratpack applications are deﬁned through a
handler chain
•  Handler chain is a programmatic construct
for managing the ﬂow of request data
•  Handlers can be bound to request path
routes and HTTP verbs

import static ratpack.groovy.Groovy.ratpack!
!
ratpack {!
handlers {!
get {!
response.send "I'm the default route!"!
}!
get("route1") {!
response.send "I'm in route1"!
}!
get("route2/:param") {!
response.send "I'm in route2 and received param: ${pathTokens.param}"!
}!
}!
}!
Handler chain in a Ratpack Script-backed app

RatpackServer.start(b -> b 
.config(ServerConfig.noBaseDir()) 
.handlers(chain -> chain 
.get(ctx -> ctx.getResponse() 
.send("I'm in the default route!")) 
!
.get("route1", (ctx) -> ctx.getResponse() 
.send("I'm in route1!")) 
!
.get("route2/:param", (ctx) -> ctx.getResponse() 
.send(String 
.format(” received param: %s", 
ctx.getPathTokens().get("param")))) 
) 
);"
Handler chain in using Java 8 APIs

handlers {!
get { ... }!
get("route") { ... }!
!
post { ... }!
post("route") { ... }!
!
put { ... }!
put("route") { ... }!
!
delete { ... }!
delete("route") { ... }!
!
patch { ... }!
patch("route") { ... }!
}!
Semantic handler API for binding to HTTP verbs and routes

•  Handlers can be nested within a route…
handlers { 
prefix("api") { ModelDAO dao -> 
get { 
blocking { dao.getAll() }. 
then { models -> render JsonOutput.toJson(models) } 
} 
post { 
Model model = parse(fromJson(Model)) 
blocking { dao.save(model) }. 
then { m -> render m } 
} 
put(":id") { 
blocking { dao.load(pathTokens.id) }. 
map { model -> model.merge(parse(fromJson(Model))) }. 
blockingMap { model -> dao.save(model) }. 
then { model -> render model } 
} 
} 
}!

•  There’s a special handler type for serving
static assets from the app’s baseDir!
•  Static assets must be deﬁned as the last
handler in the chain
•  Can be scoped to routes

•  Use the assets handler to serve static content
handlers { 
prefix("api") { 
get { 
response.send "some API data" 
} 
} 
assets("public", "index.html”) 
}!

•  You can also use a handler with byMethod to perform common processing
within a route…
handlers { 
handler("api") { ModelDAO dao -> 
dao.beginTransaction() 
byMethod { 
get {} 
post {} 
put {} 
delete {} 
} 
dao.endTransaction() 
}!
}!

•  Can discriminate on content type, allowing you to build HyperMedia APIs…
handlers { 
handler { 
byContent { 
json { 
response.send(toJson([msg: "regular json"])) 
} 
xml { 
response.send(...) 
} 
type("application/vnd.app.org+json;v=1") { 
response.send(toJson([newmsg: "hypermedia json"])) 
} 
} 
} 
}!

•  Handlers deﬁne the edge of your application
•  In Servlet API terms, handlers can be thought
of as a marriage between ﬁlters and servlets
•  Allows request introspection and
programmatic injection of handler chain

•  This allows handlers to be constructed and dependency injected, etc…
class UserHandler implements Handler { 
 
private final String message 
 
UserHandler(String message) { 
this.message = message 
} 
 
@Override 
void handle(Context context) !
!throws Exception { 
context.response.send(message) 
} 
}!
ratpack { 
bindings { 
bindInstance(new UserHandler("user handler")) 
} 
handlers { 
handler { UserHandler userHandler -> 
if (request!
.headers.contains("X-Routing-Header")) { 
def routingHeader = request!
.headers.get("X-Routing-Header") 
if (routingHeader == "user") { 
insert(userHandler) 
} 
} 
next() 
} 
get { 
response.send "default system handler" 
} 
} 
}!
New
Handler
is

programma1cally
inserted

into
the
processing
chain

•  Dependency injection is an abstraction in
Ratpack, through the concept of a Registry
•  Components are bound to, and resolvable
from, a Registry instance
•  Registries can be backed in a DI framework

•  Out of the box support for Guice and Spring
Boot
•  Registries can be inherited, allowing
components to be resolved in a cascading
manner
•  Every request context gets a registry that
components can be extracted from

•  In a Groovy script that uses closures as
handlers, the variable arguments to that
closure are “injected” from the registry
•  In Java 8, they are able to be resolved from
the request context object

•  You don’t need to use a DI framework to get injection support, you can build
your own registry from objects you construct…
public static void main(String[] args) throws Exception { 
Registry registry = Registries.registry() 
.add(new ModelDAO()).add(new DB()).build(); 
 
RatpackServer.start(spec -> spec 
.config(ServerConfig.noBaseDir()) 
.handlers(chain -> { 
chain.register(registry); 
chain.handler(":id", ctx -> { 
ModelDAO dao = ctx.get(ModelDAO.class); 
ctx.blocking(() -> 
dao.load(ctx.getPathTokens().get("id"))) 
.then(ctx::render); 
}); 
}) 
); 
}!

•  Variables arguments to Groovy closure handlers are resolved from the
registry
def myRegistry = Registries.registry() 
.add(new ModelDAO()) 
.build() 
 
ratpack { 
handlers { 
register(myRegistry) 
 
prefix("api") { 
get(":id") { ModelDAO dao -> 
render dao.load(pathTokens.id) 
} 
} 
} 
}!

•  In Groovy, you get a bindings block, which you can use to bind components
to the Registry. With Guice, annotations can be used to Inject
class UserHandler implements Handler { 
 
private final ModelDAO dao 
 
@javax.inject.Inject!
UserHandler(ModelDAO dao) { 
this.message = message 
} 
 
@Override 
void handle(Context ctx) !
!throws Exception { 
ctx.blocking {!
dao.getAll()!
} then { ctx.render(it) } 
} 
}!
ratpack { 
bindings { 
binder { b -> 
b.bind(ModelDAO).in(Scopes.SINGLETON) 
b.bind(UserHandler).in(Scopes.SINGLETON) 
} 
}!
handlers { 
handler { UserHandler userHandler -> 
if (request!
.headers.contains("X-Routing-Header")) { 
def routingHeader = request!
.headers.get("X-Routing-Header") 
if (routingHeader == "user") { 
insert(userHandler) 
} 
} 
next() 
} 
get { 
response.send "default system handler" 
} 
} 
}!
Can
get
a
handle
on
a
Guice

binder
to
perform

annota1on-‐based
Injec1ng

•  Likewise, a Guice Module can be “added” to the registry…
ratpack { 
bindings {!
// Any Guice module can be added this way!
// this is how Ratpack modules are"
// introduced... "
add(new SqlModule()) 
}!
handlers { 
...!
} 
}!

•  Spring application context can be used to
back a registry using the
ratpack.spring.Spring class
h>p://www.ratpack.io/manual/0.9.13/api/ratpack/spring/Spring.html

•  Like handlers, registries can be
programmatically registered into the
handler chain based on request data
•  Can allow your app to resolve components
speciﬁc to the context of a request

•  Likewise, a Guice Module can be “added” to the registry…
def baseRegistry = Registries.registry() 
.add(new ModelDAO("jdbc:mysql://default")) 
.build() 
 
def cust1Registry = Registries.registry() 
.add(new ModelDAO("jdbc:mysql://cust1")) 
.build() 
 
ratpack { 
bindings { 
bindInstance(new DefaultDevelopmentErrorHandler()) 
} 
handlers { 
handler { 
next(get(PublicAddress).getAddress(it).host == "cust1" ? cust1Registry : baseRegistry) 
} 
prefix("api") { 
get(":id") { ModelDAO dao -> 
render blocking { dao.load(pathTokens.id) } 
} 
} 
} 
}!

•  Including framework modules in your
Gradle based project is really easy
•  Can utilize helper methods from the
Ratpack Gradle plugin to include named
modules
•  Allows framework versions to stay in sync

•  The Ratpack Gradle plugin provides the ratpack.dependency() helper
...!
!
dependencies { 
compile ratpack.dependency("jackson”) 
compile ratpack.dependency(”rxjava”)!
compile ratpack.dependency(”codahale-metrics”)!
testCompile ratpack.dependency(”remote-test”) !
}!
!
...!

•  Static fixtures for mapping a multitude of external and environmental configuration
sources to POJOs
Configuration Module: ratpack-config
// build.gradle"
dependencies {!
... 
compile ratpack.dependency(”config”)!
... 
}!
import ratpack.config.*;!
!
ConfigurationData configData =
Configurations.config() 
.yaml(Main.class.getResource("/app.yml")) 
.json(Main.class.getResource("/app.json")) 
.props("/etc/app/file.properties") 
.sysProps() 
.env() 
.build();!
!
ServerConfig config = configData!
.get("/server", ServerConfig.class); 
 
RatpackServer.start(spec -> spec 
.config(config) 
.handlers(...) 
);!
// classpath:/app.yml"
server:!
port: 8080!
!
myAppStuff:!
anyConfigData: 1234!

•  Environment-derivable conﬁguration
follows the principle of the Twelve Factor
App
Great Support for building MICROSERVICES!!

•  NetﬂixOSS Hystrix support, via the ratpack-
hystrix module
•  Calls to remote services can be made fault
tolerant
•  Ability to stream Hystrix metrics to the Hystrix
Dashboard
Great Support for building MICROSERVICES!!

•  The ratpack-hikari module uses HikariCP
to create a super fast pooled SQL DataSource
•  Can be used in conjunction with Groovy SQL
to query databases
•  Conﬁgurable using the ﬁxtures from the
ratpack-config module
Great Support for DATABASES!!

•  The ratpack-jackson module provides
request data parsing and object rendering
from and to JSON
•  Data can be worked with in free-form nodes,
or bound to command objects
•  Arbitrary models can be rendered as JSON
using simply context.render(obj)!
Great Support for DATA BINDING!!

•  Ratpack’s Promise API is an implementation of
Reactive Streams Speciﬁcation
•  The ratpack-rxjava module provides a
bridge between a Ratpack Promise and an
RxJava Observable
•  The ratpack-reactor module allows data
to be processed using Project Reactor
Great Support for REACTIVE PROGRAMMING!!

•  View templates can be rendered through a variety
of means
•  Support for server-side templating with
Handlebars, Thymeleaf, Groovy Templates, and
Groovy Markup
•  Ongoing work to integrate @davydotcom’s asset-
pipeline, which will give robust support for all types
of static content
Great Support for FULL-STACK FEATURES!!

•  Ratpack has been built from the ground-up with
testing considered at every turn
•  Even more-so – considering testing from the
perspective of the developer
•  The concept of the Registry gives the framework
control over components
•  Makes it easy to provide ﬁxtures for mocking and
stubbing data

•  The EmbeddedApp class from the ratpack-
test module supports functional and
integration testing
•  Can be used to test an application module
or a subset of handlers and functionality
•  Can be used outside of Ratpack too!

•  Spock is the choice framework, though
there’s no strict integration there
•  Functional tests are easy to bootstrap and
the TestHttpClient helper makes it easy to
programmatically craft test calls

•  Great resource for seeing Ratpack’s testing
in action is the example-books project
•  Rus Hart keeps this up to date with changes
to the framework.
•  https://github.com/ratpack/example-books

Twitter people to follow:!
!
•  @ldaley!
•  @rus_hart!
•  @varzof!
•  @Lspacewalker!
•  @marcinerdmann!
•  @ratpackweb!
•  @davydotcom!
•  @johnrengelman!
•  @rfletcherEW!
•  @beckje01!

Ratpack Web Framework

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Ratpack Web Framework

Similaire à Ratpack Web Framework (20)

Plus de Daniel Woods

Plus de Daniel Woods (8)

Dernier

Dernier (20)

Ratpack Web Framework