UberConf 2015 Presentation on Ratpack http://ratpack.io

1. Ratpack
Web
Framework
Dan
Woods

2. Senior
Engineer
at
The
Groundwork
@danveloper
on
Twi.er
/danveloper
on
GitHub

3. Learning
Ratpack
publica=on
Fall
2015
Shameless
Self
Promo=on…

4. Quick
Overview
• A
high-­‐throughput,
reac=ve
web
framework
for
the
JVM
• Built
on
Java
8
(required)
and
comes
with
a
Groovy
DSL
• Great
support
for
microservices
/
Twelve
Factor
apps
• Rapid
produc=vity

5. Quick
Start
• Groovy
DSL
is
the
path
of
least
resistance
• App
can
be
built
into
a
standalone,
runnable
Groovy
script
• Rapid
prototyping

6. What
is
this
doing?
• Imports
the
DSL
via
ratpack.groovy.Groovy.ratpack
• The
closure
supplied
is
the
defini3on
• Defini=on
consists
of
serverConfig,
bindings,
and
handlers
• App
defini=on
infers
reasonable
defaults
for
serverConfig
and
bindings

7. What
is
this
doing?

8. Handler
Chain
• A
pipeline
for
request
processing
• The
“edge”
of
an
applica=on
• Defines
request
flow
and
terminal
handlers
• Handlers
can
be
thought
of
in
equivalent
terms
to
servlets
and
servlet
filters

9. Handler
Chain
Diagram
courtesy
of
Andrey
Adamovich:
h_ps://twi_er.com/codingandrey

10. Handlers
• Two
types
of
handlers:
request
flow
and
terminal
• Request
flow
handlers
provide
flow
control
in
processing
• Terminal
handlers
process
and
respond
to
a
request

11. Terminal
Handlers
• Bound
to
HTTP
verb(s)
and
request
path
• Chain
API
provides
seman=c
methods
for
binding
to
verb

12. Method
Descrip.on
Usage
all
Handler
is
executed
for
all
requests
within
its
chain
all
{
render
“Hello
World!”
}
get(path)
Handler
for
HTTP
GET
requests.
Path
op=onal.
get(“foo”)
{
render
“Hello
Foo!”
}
post(path)
Handler
for
HTTP
POST
requests.
Path
op=onal.
post(“foo”)
{
def
json
=
request.body.text
…
}
put(path)
Handler
for
HTTP
PUT
requests.
Path
op=onal.
put(“foo”)
{
def
json
=
request.body.text
…
}
patch(path)
Handler
for
HTTP
PATCH
requests.
Path
op=onal.
patch(“foo”)
{
def
json
=
request.body.text
...
}
delete(path)
Handler
for
HTTP
DELETE
requests.
Path
op=onal.
delete(“:id”)
{
def
id
=
request.pathTokens.id
...
}

13. A
Caveat
to
Handlers
• Only
a
single
handler
can
be
bound
for
any
given
HTTP
request
path
• You
must
use
request
flow
mechanisms
to
bind
mul=ple
handlers
for
a
path

14. Request
Flow
Handlers
• Terminal
handlers
get
nested
• Allow
host
binding,
prefix
binding,
decision
rou=ng,
method
rou=ng,
content
type
nego=a=on
• Can
be
defined
within
the
handler
chain
or
handlers
themselves

15. Prefix
Handler
• Creates
a
sub-­‐chain
bound
to
a
prefixed
request
path
• Allows
handlers
to
be
defined
within
the
context
of
the
prefix
• Makes
it
easy
to
scope
a
handler
chain

16. The
when
Handler
• Creates
a
sub-­‐chain
bound
to
a
prefixed
request
path
• Allows
handlers
to
be
defined
within
the
context
of
the
prefix
• Makes
it
easy
to
scope
a
handler
chain

17. Method
Rou=ng
• Nested
handler
type
(handlers
within
a
handler)
• Uses
the
byMethod
call
within
a
handler
• Must
be
bound
within
an
all
handler
type

18. Content
Type
Nego=a=on
• Nested
handler
type
(handlers
within
a
handler)
• Uses
the
byContent
call
within
a
handler
• Routed-­‐to
according
to
request’s
Accept
header
• Chain
for
content
type
handlers
• Seman=cs
for
common
content
types
(json,
xml,
html,
plainText)

19. Method
Descrip.on
json
Called
when
application/json
is
specified
in
Accept
header
xml
Called
when
application/xml
is
specified
in
Accept
header
html
Called
when
text/html
is
specified
in
Accept
header
plainText
Called
when
text/plain
is
specified
in
Accept
header
type(String)
Called
when
the
provided
string
matches
the
Accept
header
noMatch
Called
when
the
Accept
header
is
specified,
but
no
handler
is
bound
for
the
given
type
• Caveat:
the
first
handler
in
the
byContent
chain
is
favored
when
no
Accept
header
is
present
Content
Type
Nego=a=on

20. Project
Structure
• OOTB
Support
for
Gradle
build
system
• App
structure
follows
Java
conven=ons
• Groovy
apps
can
s=ll
be
built
as
scripts
• Apps
can
be
defined
from
within
a
main
class

21. Gradle
Support
• Add
the
io.ratpack:ratpack-­‐gradle:<version>
to
your
buildscript
classpath
• Apply
the
io.ratpack.ratpack-­‐{groovy,java}
plugin
to
your
buildscript
• ./gradlew
run
to
see
your
app
in
ac=on!

22. Framework
Dependencies
• Use
the
plugin
helper
method
to
bring
in
framework
deps
• Framework
deps
are
resolved
by
their
unqualified
name
• As
simple
as
specifying
ratpack.dependency(name)
in
dependencies
block

23. Main
Class
Apps
• Any
project
can
build
a
main
class
and
use
that
as
the
entry
point
• Use
the
ratpack.server.RatpackServer
factory
to
define
your
applica=on
• Java
8
apps
must
use
a
main
class

24. Dependency
Injec=on
• DI
in
Ratpack
is
abstracted
through
the
Registry
• Request
handling
code
is
FP
style,
so
should
remain
stateless
• The
Context
given
to
each
handler
allows
resolu=on
of
components

25. Dependency
Injec=on
• OOTB
support
for
Guice
and
Spring
Boot
• Groovy
DSL
has
Guice
fixtures
pre-­‐baked
• The
bindings
block
allows
you
to
bind
components
in
your
app

26. Dependency
Injec=on
• Groovy
DSL:
Components
injected
into
handlers
through
varargs
• Java
API:
components
are
resolved
through
Context.get(Class)
• Note
that
non-­‐Groovy
apps
need
to
include
the
ratpack-­‐guice
framework
dependency

27. Registries
• Registries
can
be
built
on-­‐the-­‐fly
within
the
handler
chain
• Latest
binding
will
be
resolved
first
• Allows
apps
to
register
and
resolve
components
according
to
proper=es
of
a
request

28. Tes=ng
• Ratpack
provides
fixtures
for
func=onal,
integra=on,
and
unit
tes=ng
• Can
quickly
get
high
test
coverage
with
li_le
effort
• EmbeddedApp
fixture
can
be
integrated
to
ameliorate
hard-­‐to-­‐test
or
legacy
apps

29. Non-­‐Blocking
Paradigm
• Ratpack
uses
NIO
to
garner
high
throughput
• Maintains
discrete
request-­‐taking
and
blocking
thread
pools
• Request-­‐taking
threads
must
not
block
• Blocking
APIs
are
able
to
be
made
async
through
the
Context.blocking()
mechanism

30. Building
Async
APIs
• Build
your
APIs
around
Ratpack
Promise
types
• This
gives
you
flexibility
in
determining
in
processing
capacity
(blocking/computa=on)
• Promises
ensure
that
the
Ratpack
knows
when
your
app
is
async
processing

31. Reac=ve
Programming
Reac3ve
programming
is
a
technique
by
a
processing
func3on
requests
data
from
a
producing
func3on,
a
single
element
at
a
3me.
Mul3ple
elements
are
delivered
through
a
pipeline,
wherein
one
or
many
func3ons
can
affect
the
flow
and
form
of
data.

32. Reac=ve
Programming
The
request
for
data
starts
here
Transforming
func=on
Call
for
a
data
element
Call
for
a
data
element
Call
for
a
data
element
Filtering
func=on
Producing
func=on
(will
send
elements
down
the
pipeline
when
requested)

33. Reac=ve
Programming
• Data
is
not
“observed”
by
down-­‐pipeline
func=ons
un=l
the
above-­‐pipeline
func=ons
supply
it
• Push
vs.
Pull
data
element
retrieval
methodology
• Best
suited
for
async
processing,
where
data
is
gathered
on-­‐demand
(not
in
advance)

34. Reac=ve
Programming
• Promises
are
reac=ve,
in
that
they
send
data
only
when
it
is
requested
• Promises
will
only
ever
“emit”
a
single
item
into
the
processing
pipeline
(whether
it
be
a
list
of
data
elements
or
a
single
data
element
itself)

35. Reac=ve
Programming
• Ratpack
has
extensive
support
for
interopera=ng
with
RxJava
• Provides
RxJava
with
a
scheduler
for
processing
work
from
Observables
• Observables
can
emit
one
or
more
data
elements
through
the
pipeline
to
cons=tute
a
“stream”
of
data
• Ideal
for
robust
async
API
layers

36. Configura=on
• Support
for
building
typed
configura=on
models
from
a
variety
of
sources
• Configura=on
can
come
from
JSON,
YAML,
Java
Proper=es
• Microservice
and
produc=on
configs
can
pull
configura=on
from
sys
props
and
environment
variables

37. Addi=onal
Framework
Features
• Non-­‐blocking/Async
HTTP
client
• Support
for
Hystrix
for
fault
tolerance
across
microservices
• Database
connec=on
pooling
(HikariCP)
• Sessions
and
Cookies
• Security
(Pac4j)
• Content
serving
(built-­‐in
and
Asset
Pipeline)
• Metrics
(CodaHale)
• Asynchronous
health
checks

38. Packaging
• Builds
leverage
the
Gradle
applica=on
plugin
• Na=ve
support
for
crea=ng
tar
or
zip
distribu=on
packages
for
deployment
• Can
be
overlayed
with
the
Shadow
Jar
plugin
to
build
“fat
jars”
• Perfect
for
cloud-­‐na=ve
microservice
deployments

39. So
Why
Should
I
Care?
• Ratpack
is
FAST
• A
single
instance
of
Ratpack
can
support
up
to
800,000
concurrent
requests
per
second*
– h_ps://gist.github.com/danveloper/db888be3519966976368
• Provides
applica=on
structure
to
non-­‐blocking
underpinnings
• App
packages
are
standalone,
runnable,
and
small

40. Ques=ons?