►
Description
Next Level gRPC With Kotlin and Coroutines - Marco Ferrer, OfferUp
When it comes to async programming on the JVM, Kotlin Coroutines are leading the pack in both versatility and performance. This session will cover how the usage of Coroutines improves the ergonomics of APIs from both a client and server perspective. It will also cover the key benefits gained by adopting the practice of structured concurrency. Attendees will learn how Coroutines enable clients and services to participate in cooperative cancellation across network boundaries. Improving overall resource utilization. See how Coroutine suspension maps naturally to gRPC's backpressure mechanisms. After which we will dive into the state of the gRPC ecosystem for Kotlin. Analyzing what the available options are for current users and what the future has in store for the ecosystem.
A
Hi,
my
name
is
marco
ferreira,
and
the
title
of
this
session
is
next
level
grpc,
with
kotlin
and
co-routines
in
this
session.
We're
going
to
cover
what
the
available
options
are
for
gft's
development
on
the
jvm
using
kotlin
we're
going
to
take
a
look
at
what
the
general
api
ergonomics
look
like
for
the
available
offerings
as
well
as
demonstrate
how
we
can
use
some
of
the
special
features
of
coroutines
to
improve
our
grpc
service
implementations.
A
A
What
kotlin
is
most
well
known
for
is
the
fact
that
it's
now
an
official
preferred
language
for
android
development,
and
this
fact
is
what
has
caused
it
to
gain
so
much
popularity
in
recent
years
now,
co-routines
coroutines
aren't
a
new
concept.
They've
existed
for
quite
some
time
and
appeared
in
various
flavors
of
various
names.
A
A
A
Now,
if
we
look
at
what
that
example
looks
like
using
threads,
we'll
end
up
having
to
kill
the
process
because
of
the
fact
that
threads-
and
it's
specifically
in
this
example
when
we're
performing
our
sleep,
we're
actually
blocking
that
thread
and
no
other
computations
can
be
performed.
That
thread
is
locked
until
we're
ready
or
in
our
sleep
cont
finishes,
whereas
in
the
coroutines
example
we're
not
using
thread.sleep,
but
we're
using
a
built-in
function
called
delay
and
what
delay
does
is
suspend
the
execution
of
that
method.
A
A
So
without
all
the
way
we
can
take
a
look
at
what
our
grpc
apis
look
like
in
kotlin,
we
currently
have
a
few
options:
there's
chrono,
plus
a
library
and
suite
of
protoc
plugins.
I
initially
released
a
few
years
ago,
there's
very
recently
the
google
official
binaries
or
bindings
sorry
released,
which
is
very
exciting
for
the
community.
A
A
Now,
if
we
take
a
look
at
what
that
looks
like
using
co,
routines,
you'll
see
that
first,
our
signature
no
longer
acceptance
accepts
an
instance
of
stream
observer.
We
no
longer
have
to
worry
about
the
song
and
dance
of
calling
on
next
on
complete
or
on
there.
The
method
now
has
a
return
type
defined
that
matches
our
api's
response
type.
A
When
looking
at
the
urinary
client
usage,
though
you
see
that
core
team
interface
doesn't
differ,
much
from
vanilla
java
blocking
subs,
with
the
one
exception
being
that
the
say
hello
method
in
this
example
is
actually
suspending
method,
meaning
that
we're
not
blocking
the
current
thread.
While
we
wait
for
a
response
from
the
server.
A
Concurrent
execution
is
still
made
possible,
but
there's
a
few
caveats.
One
of
the
caveats
means
that
we
want
to
adopt
co-routines
practice
of
explicit
concurrency
and
I'm
not
going
to
go
into
too
much
detail,
but
in
summary,
it
means
that
by
default,
apis
and
methods
should
behave
and
execute
sequentially
and
when
concurrency
is
needed,
you
should
explicitly
opt
into
that
so
that
there's
no
unknown
or
unexpected
behavior
or
the
risk
of
orphaning
resources
and
not
closing
out
specific
things.
A
A
Now
we're
going
to
take
a
look
at
streaming
apis
for
the
sake
of
brevity,
we're
only
going
to
cover
bi-directional
streaming
simply
because
the
client
and
server
streaming
apis
or
their
implementations
at
least
they
can
be
inferred
easily.
From
these
examples,
we'll
start
with
a
vanilla
java,
bidirectional
streaming
method,
but
written
in
kotlin,
syntax
and
its
implementation
is
very
basic
in
that
we
validate
each
request
and
we
respond
to
the
client
and
in
the
event
of
a
client
error,
we
log
the.
A
A
A
The
key
thing
to
notice
is
that,
instead
of
accepting
two
channels,
the
official
bindings
will
actually
accept
a
flow
of
requests
and
return,
a
flow
of
responses,
and
these
are
called
streams
of
data.
That's
the
main
difference,
but
other
than
that.
The
implementation
remains
largely
the
same,
we'll
go
ahead,
and
catch
and
log
our
client
errors
and
finally
consume
our
requests.
A
A
We
create
our
stub
and
when
using
proto
plus
we're
when
invoking
our
streaming
method,
we
actually
get
returned
a
pair
of
two
values.
Our
request
and
response
channel
in
this
example
you'll
see
that
we're
actually
destructing
those
two
values
into
their
own
separate
variables,
allowing
us
to
perform
operations
independently.
A
For
this
example,
we're
going
to
kick
off
our
stream
with
a
message
that
says
start
iterating
afterwards,
we
start
consuming
our
responses.
We
cancel
the
call
if
we
receive
an
invalid
response.
Otherwise
we
send
the
next
request
and
since
we're
using
the
kodo
plus
variant,
you
see
that
we're
using
the
lambda
builder
to
instantiate
our
method
to
send
our
response
or
create
an
instance
of
our
response
method
when
using
the
official
grpc
kotlin
bindings.
A
The
api
is
a
little
bit
different,
you'll
notice
that
we
actually
need
to
pass
in
a
cold
flow
and
we'll
get
a
cold
flow
and
response.
Now.
This
makes
it
difficult
when
we're
trying
to
make
changes
or
react
to
the
responses
that
we're
receiving
from
the
stream
like
sending
requests
based
off
of
responses
that
we've
already
received,
but
there's
very
easy
ways
to
get
around
this
limitation
in
this.
A
In
this
specific
example,
we
just
instantiate
a
channel
that
lets
us
have
a
reference
to
our
request
stream
and
we'll
send
that
into
our
argument
for
our
method,
the
request
channel.
We
go
ahead
and
we
start
iterating
as
well.
Only
difference
is
using
our
fluent
builders
and
we
collect
our
responses
and
close
out
our
channel
once
we've
completed,
or
we
cancel
the
call
once
we've
encountered
some
kind
of
invalid
response.
A
So
going
a
little
deeper,
we're
gonna,
look
past
syntactical
differences
and
we're
gonna
dive
into
the
behavior
of
what's
using
co-routines
with
grpc
the
behavior
of
our
apis.
Specifically
we're
going
to
look
at
how
the
concept
of
structured,
concurrency
and
cooperative
cancellation
affect
our
api
implementations.
A
These
concepts
are
first-class
citizens
in
kotlin
covered
scenes.
They
allow
us
to
write
safer,
more
efficient,
concurrent
code
at
a
high
level.
Core
routines
are
hierarchical,
their
scopes
are
their
scopes,
bear
a
parent-child
relationship
with
scopes
created
within
them
and
we'll
see
how
that
plays
out
when
we're
orchestrating
multiple
api
calls.
A
A
So
here's
our
small
example.
We
have
a
method
in
this
method,
we're
going
to
be
making
three
concurrent
requests
to
to
a
service
each
request
we're
actually
going
to
do
a
fire
off
in
an
async
block
and
the
actual
method
will
suspend
until
we
receive
the
result
from
the
service
before.
Finally,
we
await
the
results
of
all
three
of
those
and
print
the
message
to
the
console.
A
Unfortunately,
though,
look
one
of
our
calls
has
failed,
which
threw
an
exception
and
terminated
the
child
core
routine.
Now
we're
still
waiting
for
the
responses
for
the
other
two
calls
and
then,
even
though
our
method
requires
all
the
values
in
order
to
complete
successfully,
we
don't
really
need
those
values
anymore,
but
how
do
we
cancel
the
other
two
calls,
because
our
method
is
now
in
an
invalid
state.
A
A
Essentially,
the
cancellation
will
propagate
to
all
of
the
calls
being
made
to
other
resources
and
that
cancellation
will
actually
go
all
the
way
down
the
call
graph
if
there
are
other
services
that
are
implementing
the
the
co-routines
or
at
least
hooked
into
the
cancellation
hook
or
the
cancellation
callback
for
the
service
calls.
So
this
is
a
cooperative
cancellation
across
network
boundaries
and
it
helps
prevent
our
services
from
from
performing
unnecessary
operations
and
wasting
resources.
A
But
it's
not
something
that
it's
not
a
behavior
that
we
always
want
it's.
There
are
times
where
we
want
to
opt
out
of
consolation.
There
are
times
where
we
want
to
basically
ensure
that
whatever
method
or
or
logic
that
we're
running
that
we
either
complete
it
successfully
or
that
we
wrap
it
in
some
kind
of
transaction
and
make
sure
we
roll
back,
there's
hundreds
of
different
cases
where
we
actually
don't
want
to
terminate,
even
though
the
client
has
finished
something-
and
that's
very
easy
to
that-
that's
very
easy
to
implement.
A
There
are
plenty
of
ways
and
options
on
how
you
can
implement,
like
opting
out
of
cooperative
cancellation.
The
most
the
simplest
option,
though,
is
just
wrapping
your
method,
implementation
with
with
context
non-cancelable
and
still
perform
your
your
logic,
and
what
this
will
do
is
just
protect
your
that
particular
block
of
code
from
any
receiving
any
signals
that
might
try
to
cancel
its
execution.
A
A
The
google
grpc
kotlin
implementation
is
still
new,
but
it's
already
gaining
a
lot
of
traction
and
as
optimizations
and
improvements
are
made,
it'll
no
doubt
solidify
kotlin.
As
a
first
class
grpc
citizen
separately,
there's
exciting
work
being
done
to
improve
the
protobuf
message
support
so
that
we
can
get
native
first-class
features
of
kotlin
like
data
classes
when
we're
building
out
our
our
messages
and
thinking
in
the
long
term.
A
The
the
one
feature
or
the
one
like
thing
that
keeps
coming
up
in
the
community
is
multi-platform
grpc,
and
what
that
means
is
that
if
we
can
work
to
build
a
multi-platform,
grpc
implementation,
then
we're
able
to
use
and
share
our
grpc
business
logic
across
our
platforms,
even
more
specifically
ios
and
android,
letting
us
share
that
code,
letting
us
centralize
it
right.
At
once,
run
everywhere
and
actually
minimize
the
work
being
done
by
teams
that
have
to
support
multiple
platforms.
A
So
going
over.
All
of
that,
it's
it's
easy
to
see
how
we
have
not
just
evolved,
but
provided
an
api
that
is
covered
first
class
code,
routines
api
first
class
provided
by
the
actual
grpc
team,
with
all
the
exciting
things
coming,
it's
easy
to
see
how
kotlin
and
grpc
are
really
going
to
start
growing,
much
faster
now
than
they've
done
in
previous
years.