►
From YouTube: Intro to gRPC - Jayant Kolhe & Eric Anderson, Google
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Intro to gRPC - Jayant Kolhe & Eric Anderson, Google
gRPC is a modern, open source remote procedure call (RPC) framework that can run anywhere. It enables client and server applications to communicate transparently, and makes it easier to build connected systems. Join us for this session to hear about the gRPC project, how you can use it in your applications, and how to get involved with contributing!
https://sched.co/Uahn
A
Sabby
all
right,
I'm,
so
yellow
here
for
gypsy
and
introduction,
I'm
Eric
Anderson
and
a
giant
coal.
He
is
here
too,
but
he's
he's.
Gonna
reduce
a
little
bit
of
much
she's
talking
so
he'll
be
around
for
a
QA
and
he
might
jump
in
if
he
really
doesn't
like
something
I
say
or
something
like
that,
but
so
a
quick
audience
poll
raise
your
hand.
If
you
have
some
idea
of
what
GRP
is
all
right.
A
A
There
are
some
other
talks
during
the
day
this
slot.
These
slides
are
on
the
schedule,
so
you
can
go
and
download
them.
I'm
not
gonna
spend
too
much
time
on
the
slide,
but
there
are
some
talks
during
the
day
like
today,
like
there's
another
one
I'll
be
doing
later
today.
So
gypsy
stands
for
gypsy
remote
procedure.
Calls
we've
got
the
nice
recursive
acronym
going
there.
We
have
fun
with
the
G
and
that's
like
our
code
name
for
various
releases
and
stuff.
A
It's
a
high-performance
standards-based
open-source,
general-purpose
feature-rich
RPC
framework,
all
those
things
we
are
part
of
CN
CF
as
an
incubating
project,
and
it's
pretty
nice
for
making
native
cloud
apps
and
it's
it's
come
came
out
of
the
the
it's
the
next
generation
of
what
we
had
a
stubby
inside
of
GRP,
sorry
inside
of
Google,
which
stubby
had
proven
itself
very,
very
strongly
as
being
able
to
scale
and
basically
satisfy
all
of
our
needs
at
Google.
So
it's
still
actively
developed.
There's
lots
of
PR
still
coming
in.
It
is
production
ready,
please
go
and
use
it.
A
There's
you
know,
risk
there
and
we're
currently
a
version.
1.25
we've
got
a
six-week
release
cadence,
so
the
GRC
itself
can
work
with
things
other
than
protocol
buffers,
but
I'm
gonna
emphasize
protocol
buffers
just
because
that's
what
is
typically
used
and
that's
sort
of
the
normal
getting
started
process
and
stuff
and
the
ecosystem
overall
typically
uses
protocol
buffers
so
protocol
buffers
the
general
process.
A
Is
you
make
a
proto
file
which
has
the
IDL,
which
is
that's
the
interface
definition
language,
it
sort
of
defines
the
contract
between
a
client
and
a
server,
and
that
will
have
both
the
messages
that
you
all
are
going
to
send
back
and
forth,
but
also
these
services
and
our
pcs
that
all
be.
But
then
using
that
proto
file.
A
A
So
there
there's
sort
of
a
nice
mixing
of
the
the
two
projects
so
we'll
all
sort
of
go
through
an
example.
This
is
the
route
guide
example,
which
is
sort
of
the
second
example
in
if
you're,
looking
at
a
repo
that
has
the
hello
world
and
things
like
that,
and
so
there's
a
couple
different
things:
that's
a
little
small
over
there
on
the
right,
but
basically
we're
gonna
need
to
define
some
messages.
This
is
talking
about
like
a
geographical
route,
where
you're
moving
from
point
A
to
point
B.
A
What's
at
this
place
and
the
route
chat,
where
people
can
sort
of
send
notes
back
and
forth
if
you're
geographically
located
near
each
other,
and
so
the
first
thing
you
you
will
do,
is
you
go
ahead
and
define?
And
you
start
with
your
proto
as
I
said,
and
you
go
ahead
and
define
the
messages
you're
working
with.
So
here
we've
got
a
point
and
it's
got
a
latitude
and
longitude,
and
these
messages
are
basically
like
structures
very
similar
to
that.
And
then
we've
got
a
feature
which
has
inside
a
bit
a
nested
point.
A
Is
sort
of
acts
like
a
pointer
where
you
can
know
whether
or
not
it's
set
so
it's
and
then
we've
got
this
route
note,
which
also
contains
a
point,
and
it
has
some
sort
of
arbitrary
message
that
one
user
is
wanting
to
send
another
so
now
we're
finally
getting
into
G
RPC.
So
we've
got
some
messages
which
we're
wanting
to
communicate
between
a
client
and
a
server
and
we're
gonna
define
some
services
down
here
at
the
bottom.
So
every
service
is
just
a
collection
of
RPC
methods
or
RPC
functions.
A
They
are
a
service
itself
is
basically
just
a
namespace
where
all
these
sorts
of
things
go
within
and
within
this
we
went
ahead
and
if
I'd
into
to
our
pcs,
RBC's
in
gypsy
and
in
part
about
have
one
exactly
one
request
and
exactly
one
response:
if
you
need
multiple
arguments
or
things
like
that,
you
just
put
those
inside
of
a
message
and
that
allows
you
to
add
things
in
the
future.
It's
not
fun.
A
If
you
only
have
two
arguments,
you
need
to
add
a
third
and
you
can't,
because
that
would
break
all
of
your
existing
clients,
but
then
there's
something
a
little
bit
interesting
over
here.
Gypsy
does
not
just
do
this
normal
request
response.
That's
typical!
For
our
pcs.
It
also
supports
streaming
and
streaming
is
a
series
of
ordered
messages,
one
after
the
other
and
the
client
can
do
streaming.
A
The
server
can
do
streaming,
they
can
both
do
streaming,
and
so
that's
where
we
get
a
client
streaming
service
streaming
by
die
and
by
Die
streaming
is
the
most
advanced.
It
basically
lets
you
do
whatever
the
heck
you
want
at
that
point,
it's
your
own
sort
of
TCP
but
based
on
messages,
and
you
get
some
levels
of
routing
some
other
things.
A
Nicety
you
narrow
RPC
is
by
far
the
most
common
that
we
would
hope
that
that's
most
cases,
because
it's
much
simpler,
much
faster
to
your
head
around
and
it
doesn't
require
as
much
telling
people
how
to
use
it.
But
whenever
there's,
let's
say
you
want
to
do
a
watch
service
where
you
were
gonna,
do
notifications
or
something
like
that
which
we
have
in
this
route
chat.
We
can
go
ahead
and
do
streaming,
and
so
this
streaming
allows
someone
it's
this
little
chat
it
can.
A
They
can
send
a
new
message
whenever
they
want
it's
just
an
open
stream
so
that
it's
the
spy
die
streaming
here
and
they
can
send
a
message
whenever
they
want
and
then,
whenever
something
happens,
they
can
receive
a
message
whenever
they
want
it.
So
it's
just
an
open
channel
that
can
do
whatever
they
need.
At
that
moment,
there's
no
waiting
for
another
request
to
come
in
or
needing
to
to
create
new
are
PCs
whenever
the
old
ones
finish
for
each
and
every
single
message,
so
we
define
it
the
proto.
A
It
happens
that
that
by
itself
does
not
do
anything
like
we
actually
need
code
apparently
to
implement
to
clients
and
servers.
This
is
still
there.
We
live
in
where
we
actually
have
to
be
developers,
and
so
the
code
generators
will
take
that
proto
and
then
give
you
something.
That's
that's
good,
nice
and
usable.
So
the
messages
get
turned
into
idiomatic
objects
for
the
various
languages,
and
then
the
service
gets
integrated
into
like
an
abstract
class.
If
that's
the
language
paradigm,
and
then
you
get
a
client
sort
of,
we
call
them
client
stubs.
A
You
get
a
client
B
to
be
able
to
send
those
messages
and
receive
the
messages,
and
so,
for
example,
here's
a
what
a
rough
sort
of
view
of
what
it
would
look
like
in
C++.
Again,
these
slides
are
on
the
schedule,
so
the
the
very
top
is
the
the
stub
that
the
client
went
end
up
using
and
it
looks
mostly
like
a
normal
feature.
Function
call
except
you're.
Gonna.
A
A
A
If
you're
wanting
a
language
and
it's
reasonably
mainstream,
it's
probably
in
this
list,
and
so
that's
not
a
problem
for
you.
You
can
use
a
GRB
service
wherever
whatever
the
clients
and
servers.
Sorry,
if
you,
if
the
clients
and
servers
are
mix-and-match
which
languages
if
you've
got
a
very
heterogeneous
set
of
clients,
you
can
make
all
that
happen.
Also,
it's
working
pretty
well
for
the
various
platforms
if
you're
on
mobile.
A
The
I
cannot
overstate
truly
how
important
this
is
for
bringing
some
sort
of
semblance
to
the
wild
world
that
is
AP
is,
but
it
provides.
You
can
do
semantic
versioning
with
it,
because
there's
a
package
system,
you
can
do
things
that
are
like
stateless
restful
api
is.
There
are
some
options
that
you
can
annotate
on
our
pcs
and
there's
some
translators
in
the
ecosystem,
which
will
give
it
a
G.
A
A
A
A
So,
there's
plenty
of
extension
points
where
you
can
do
your
own
integrations
or
where
there's
plenty
of
integrations
in
the
community
for
the
various
services,
whether
that's
going
to
be
some
sort
of
service
discovery,
in
order
to
find
your
your
servers
and
do
load
balancing,
whether
that's
stats
and
tracing
or
security,
or
just
doing
something-
that's
very,
very
application
specific.
That
is
just
you
know.
A
Rpc
yeah,
maybe
that's
not
gonna,
work
out
too
well
so
you're
able
to
know
that
before
you
get
started,
I
also
talked
already
some
about
the
streaming.
The
streaming
is
an
escape
hatch
in
some
ways.
It's
again
something
that
we
majority
of
our
pcs
don't
need
or
shouldn't
use,
but
in
a
given
application,
it's
likely
that
you're
gonna
need
it
at
some
point,
like
you
know,
there's
that
one
thing
that
you
needed
to
do,
and
so
you
don't
have
to
ditch
everything
and
then
go
find
another
service.
A
Another
way
to
communicate,
or
you
know,
do
something
on
top
of
TCP
yourself
or
anything
like
that.
You
can
ended
up
just
continuing
to
use
Jerry
PC
and
you
are
able
to
use
the
streaming
streaming,
is
very
nice
for
the
the
notification
systems
and
things
like
that.
But
with
the
buy
die
you
can
basically
do
whatever
you
need.
The
the
client
streaming
and
service
streaming
are
yes,
especially
server
streaming.
That's
a
thing
that
lots
of
people
like
because
of
like
the
notifications
that
the
server
can
just
push.
Sometimes
the
client
stream.
A
You
can
do
the
same
thing
if
you've
got
to
sort
of
reversed,
a
role
between
the
client
and
server
and
those
those
aren't
really
all
that
complicated
the
buy
die
streaming
is
where
you
get
into
the
most
of
the
complexity
and
that
buy
die
streaming
is
full
duplex,
and
so
you
can
have
basically
whatever
protocol
you
want.
There's
not
any
of
this.
You
have
to
send
all
the
requests
before
you
receive
all
the
responses.
A
A
There
is
a
an
RFC
like
process
for
a
design
changes
if
you'd
like
to
propose
your
own,
but
there's
also
plenty
of
things
that
are.
You
can
just
commit
to
the
repo
for
for
small
things,
and
it's
it's.
Oh,
this
slide
didn't
get.
We
didn't
add
the
logos
here,
but
it
is
being
used
by
many
companies
in
production.
The
Gypsy
I/o
website
does
list
off
some
of
them.
We
are
very
concerned
with
backward
compatibility
and
cross
language
compatibility
because
you
saw
the
list
of
languages.
A
That
means
that
there's
quite
a
big
matrix
of
things
to
test,
and
we
do
have
interrupt
tests
between
old
versions
of
those
languages
and
across
the
various
languages
to
make
sure
that
they
do
work
and
those
those
do
fine
things
occasionally
we're
very
happy
to
have
them.
There's
also
things
like
fuzz
testing
and
things
like
that
for
for
security.
A
A
B
A
The
question
is:
what
is
the
recommendation
for
doing
load
balancing
of
GRDC,
so
GRC
itself
comes
with
a
few
basic
strategies,
so
pick
first
is
the
default
that
is
sort
of
what
people
expect
if
you're
used
to-
let's
say
HDPE,
it's
just
you
there's
a
bunch
of
addresses.
You
know
come
across
the
first
one
that
works
and
use
that
for
all
of
your
communication.
So
that's
common
across
the
wide
internet
and
it's
relatively
safe,
as
in
it's
not
going
to
have
a
big
explosion
of
connections.
So
that's
the
default.
A
A
It
would
be
very
normal
to
plug
in
your
service
discovery
mechanism,
which
we
call
name
resolvers.
If
that's
just
DNS
and
that's
that's
there,
but
there's
also
plenty
of
integrations
with
the
various
service
discovery
mechanisms
and
they'll
just
return
multiple
addresses
and
we
will
just
connect
to
each
and
that's
that's
very,
very
common.
There
are
some
more
advanced
strategies
like
there
was
gypsy
Elbe,
which
is
right
now
deprecated
in
the
new
things
coming.
A
Both
and
the
new
thing
is,
is
the
XDS
load
balancer
both
of
those
are
meant
to
be
look
sideload
load
balancers,
where
the
client
is
told
in
sort
of
a
partially
rich
form
of
how
it
should
connect
what
it
should
connect
to,
and
so
then
this
there's
a
centralized
load
balancer,
which
then
makes
certain
decisions
about
what
the
clients
should
do.
So
that
allows
doing
things
like
sub
setting
where
you've
got.
A
A
See
I
see
suppose
mentioned
that
that
in
sort
of
sidecar
environments,
hb2
still
has
a
lot,
has
some
overheads.
Whenever
you're
talking
to
side
cars
and
there's
mention
things
like
UNIX
domain
sockets
and
things
like
that,
many
of
the
languages
support
UNIX
domain
sockets,
some
of
them
you
get
to
fiddle
with
it
a
little
bit.
A
Depending
on
how
big
of
a
difference
it
is
so
that
was
just
sort
of
a
low-level
transport
difference.
Those
are
pretty
easy
to
add
and
are
generally
fine
if
it
was
something
more
complex
like
choosing
something
other
than
each
should
be,
that
we
would
probably
look
at
ETV
is
very
useful
because
it
provides
a
lot
of
benefit
and
it's
all
the
languages
support
it.
So
you
you
can
mix
and
match
pretty.
A
Is
not
any
public
API
for
doing
it,
for
inserting,
in
your
own
transports,
the
depending
on
the
language,
there's
more
or
less
of
a
transport
API,
but
it's
tends
to
be
internal
because
we
want
to
change
it
over
time
and
and
the
performance
of
a
transport
can
influence.
You
like.
We
want
to
change
the
API
in
order
to
eke
out
performance,
and
we
we
do
that
do
that
pretty
commonly.
A
But
if
there's,
if
there's
specifics
again,
UNIX
doing
sake
in
particular,
should
already
be
a
mostly
soft
problem,
although
depending
slightly
on
which
language,
but
if
there's
specific
like
if
someone
wanted
quick,
let's
just
say
no
quick
is
very
Miller-
has
different
advantages
in
that
and
downfalls.
You
know
it's
it's
that
that
we
would
do
what
takes
much
more
serious
thought
decide
whether
we
wanted
to
burden
the
ecosystem
with
that
that
option,
because
each
option
sort
of
adds
a
cost.
But
yes,
there
are.
A
There
are
ways
to
plug
in
additional
transports,
and
some
of
that
has
been
been
done
and,
for
example,
like
in
Java,
the
in
process
transport
is
just
implementing
the
transport
API
and
it
was
able
to
completely
wipe
out
not
use
HTTP
2
at
all,
and
so
there's
some
things
there
in
processed
transport.
I
guess
is
the
biggest
one
that
we'd
be
interested
in
making
a
little
bit
more.
C
A
Our
socket
was
brought
up.
We've
we're
a
little
bit
familiar
with
it.
We've
not
given
it
I
think
serious
thought.
If,
if
there's
interest
we
could
look
into
it,
did
you
want
to
say
something?
Ok,
can
you
talk
a
little
bit
more
about
the
interceptors
and
the
reconnect
logic
sure
so,
I
think
over
here
on
the
features?
Where
is
it?
Oh,
those
were
different
sites
yeah.
So
so
interceptors
are
pretty
much
in
all
languages.
A
They
were
added
to
Java,
first
and
they're
they're
made
with
Lorraine
interceptors
the
the
idea
is
to
allow
you
a
place
where
you
can
insert
in
your
own
logic,
whatever
the
heck
you
want
it
to
be,
and
so
there
are
they're
commonly
known
as
like
middleware
and
some
layers
or
filters
there.
Those
are
basically
the
same
as
interceptors
the
it
tends
to
be
something
that
the
purpose
of
interceptors
is
for
times
where
you,
you
have
some
particular
behavior,
and
you
want
to
do
it
across
all
your
our
pcs
or
many
different
types
of
our
pcs.
A
A
That's
that's
a
high-level
view.
Is
that
can
I?
Is
there
something
more
specific
I
guess
about?
Interceptors
I
could
answer
okay.
So
so
then
the
other
thing
is
to
reconnect
logic
so
I
it
was
on
the
slides.
Y'all
could
have
seen
that
there
that
gypsy
will
automatically
reconnect
whenever
you're
using
to
your
PC.
You
you
make
a
channel
which
has
some
host
name
that
you're
gonna
connect
to
and
it's
gypsies
job
to
manage
connections.
However
many
of
them
are,
there
are
like
if
you're
doing,
round-robin
is
gonna,
be
lots
of
them.
A
If
it's
stick
first,
there
will
be
few
of
them,
but
it's
gypsies,
job
and
at
any
point
in
time
the
server
may
want
to
disconnect
or
the
network
goes
down
or
you
know
things
happen,
ER
PC,
but
well,
just
out
of
the
box
reconnect
whenever,
whenever
things
get
better,
there
is
exponential,
back-off
built
in
and
so
like,
because
that's
really
really
important.
Whenever
things
are
getting
disconnected,
you
don't
want
to
hammer
the
server,
then
just
hoping
it's
gonna
get
better.
A
So
there's
exponential
back-off
to
let
things
recover,
gracefully
but
commonly
that
won't
come
into
play
commonly.
There's
a
disconnect
and
we
reconnect
and
you
go
about
your
merry
way
and
you
never
saw
it
streams
and
our
pcs
are
bound
to
a
particular
connection.
So
if
that
connection
breaks,
the
RPC
will
fail,
but
any
new,
our
pcs
would
be
completely
fine.
There's
no
course
guaranteed
correspondence
between.
If
you
do
to
our
pcs
that
they'll
go
on
the
same
connection
or
anything
like
that.
It's
just
handled
by
the
the
underlying
channel.
B
A
So
there's
there's
a
couple
different
times
that
you're
wanting
to
do
routing
or
get
a
particular
request
to
a
particular
server,
because
there's
either
starting
going
on
or
things
like
that,
so
the
common
pattern
there
is
either
a
VNA
interceptor
or
just
in
the
application
code.
You
put
a
particular
key,
that's
useful
and
you
can
have
a
couple
keys
or
something
like
that,
but
you
put
it
but
take
the
key,
that's
useful
into
the
metadata,
and
so
GRC
has,
in
addition
to
their
every
request
response.
A
The
did
this
is
the
sort
of
thing
that
would
be
available
eventually
with
the
XDS
load
balancer,
because
the
XDS
protocol
allows
some
of
that
information
to
be
transmitted
to
tell
the
client
what
to
do.
But
it's
also
possible
if
you've
gonna
have
a
custom
scheme
or
things
like
that
to
write
your
own
load,
balancing
plugin
that
will
that
won't
be
able
to
use
that
information.
A
B
C
A
Streaming
is
technically
a
little
bit
faster
than
the
the
unary
use
request
response
we
tend
not
to
I,
tend
not
to
want
to
tell
people
that
too
much,
because
then
I
think
they'll
go
off
the
deep
end
and
try
to
use
it
everywhere,
because
I
gets
them
a
little
bit
marginal
performance
improvement.
Typically
request
response
is
just
so
much
easier
to
debug
and
understand
what
the
system
is
doing.
Staffs
means
something
more,
but
a
lot
of
high
performance
use
cases
benefit
very
strongly
from
streaming.
A
For
example,
any
of
this
isn't
even
I
would
say
high
performance,
but
if
you're
doing
uploads
and
downloads
streaming
can
be
a
huge
help
there,
because
you've
got
proper
pipelining
where
you
can
send
one
thing
and
then
the
next
and
the
next
and
it's
not
gonna
overburden
the
server.
You
don't
have
to
figure
out
what
batch
size
you
do,
how
many
concurrent
RBC's
or
to
the
same
level,
of
how
many
concurrent
RPC
as
you
do
so
streaming,
can
be
a
huge
huge
win
there.
A
Let's
see
you
said
a
broker,
I
mean
a
broker.
Has
it's
gonna
be
a
proxy
in
some
way,
so
it's
gonna
I
think
it
would
have
the
most
obvious
performance
characteristics.
It's
gonna
have
to
parse
it
and
translate
it
I'm,
not
sure,
like
that,
that's
just
a
straightforward
trade-off.
You
get
to
figure
out.
What
other
thing
are
you
going
to
consider
other
than
the
broker
and
whether
you're
getting
enough
bang
for
your
buck
for
the
broker
I
like
brokers,
but
you
it's
not
good
for
every
situation.
A
Is
their
postman
like
tool
to
view
the
requests
in
the
response
things
like
that
so
I'm
trying
to
think
back?
It's
been
a
little
while,
since
I
looked
at
postman
I'm
trying
to
remember
exactly
where
it
fits
in,
there
are
some
tools
to
fire
off
your
own
requests
and
see
the
responses,
but
it
was
it
did
it
do
for
live,
live
on
the
server
and
client.
B
A
It
simulates
the
client,
okay,
okay,
so
there
are
a
couple
different
command-line
tools
that
will
you
can
fire
our
pcs
I'll
just
on
the
command
line,
giving
it
the
request
and
then
seeing
the
response.
Many
of
them
will
also
use
the
JSON
converter
or
the
text
conversion
for
pro
dos
so
that
you
can
actually
see
it
as
a
human
being
because
otherwise
it's
gobbledygook
binary.
A
So
there's
the
GRC
CLI,
which
we
don't
have
a
prebuilt
binaries
for,
but
it
works
grps
curled,
your
curl
there's
two
of
them,
one
of
them
I
found
I,
really
really
liked.
I
think
it
was
the
one
without
the
CC,
but
it
was
an
NGO
and
it
was
very
nice
pre-built
binaries
and
it
also
does
have
a
JSON
request
and
you
get
a
JSON
response
granted
it's
it's
proto
over
the
wire
and
it
can
do
some
of
the
load
balancing
things
like
that
to
you
sort
of
give
it
a
name
yeah.