►
From YouTube: Intro to gRPC - Abhishek Kumar, Google
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Intro to gRPC - Abhishek Kumar, Google
gRPC is a modern, open source remote procedure call (RPC) framework that can run anywhere. Distributed systems and client-server applications are built using gRPC because it provides simple abstractions for application-layer communication, coupled with a broad and powerful feature set. A wide range of languages and platforms are supported by gRPC. Join us for this session to hear about the gRPC project, how you can use it in your applications, and how to get involved as a contributor or maintainer!
https://sched.co/Zew6
A
A
A
In
this
talk,
we
are
going
to
cover
a
grpc
as
an
overview.
I
will
start
with
a
brief
description
of
what
grpc
is
we'll.
Do
a
quick
exercise
of
going
through
what
it
takes
to
build
a
grpc
service
and
then
we'll
jump
into
a
discussion
of
the
various
features
that
one
gets
while
using
jrpc
I'll
wrap
up
the
talk
with
a
brief
discussion
of
some
new
efforts
that
the
grpc
project
has
picked
up
and
we'll
have
time
for
q
a
during
the
live
session.
A
Grpc
was
built
by
the
team
that
has
been
building
remote
procedure
call
systems
at
google
for
quite
a
bit
of
time.
Now
the
microservice
architecture
has
been
the
preferred
way
of
building
services
at
google.
For
many
many
years
and
the
rpc
system
at
google
called
stubby
has
been
running
at
a
pretty
substantial
scale.
A
I'll
now,
briefly
cover
the
process
of
building
an
rpc
service
when
you're
building
a
grpc
service,
you
typically
start
out
by
defining
your
service
in
an
interface
definition
language.
We
support
protocol
buffers
as
the
as
a
standard
out
of
the
box
solution,
but
other
others.
Competing
technologies
are
also
supported.
A
A
So
defining
the
data
model
and
the
interfaces
this
so
the
data
model
definition
just
looks,
like
you
know,
a
struct
or
an
equivalent
thing
in
whatever
programming
language
you
use.
It
allows
you
to
very
precisely
capture
exactly
the
different
excuse
me
very
precisely
capture
the
types
of
the
information.
That's
going
to
be
sent
back
and
forth
the
service
definition,
which
is
the
operations
or
proceed
or
function
calls
that
are
being
implemented,
can
also
be
defined
in
the
proto
language
in
a
in
a
manner.
A
A
Here's
a
quick
example.
So,
given
the
given
the
methods
that
we
listed
in
the
previous
slide,
this
slide
shows
the
generated
code.
On
top.
You
have
the
client
side,
signature
for
the
stub
functions
that
the
client
calls
and
at
the
bottom
you
have
the
server
side,
signature
of
the
service
methods
that
the
programmer
for
the
server
side
implements
and
that's
the
implementation
that
gets
him
invoked
by
grpc
when
a
request
from
a
client
arrives.
A
You
run
code,
generators
that
generate
client
and
server
side
stubs,
and
then
you
use,
depending
on
whether
you're
building
the
client
or
the
server
or
both
you
use
those
tabs
to
build
up
your
application
under
the
hood.
This
is
all
taking
and
there's
a
lot
of
detail
in
the
implementation
that
we'll
go
over
in
the
next
few
slides,
but
it
takes
advantage
of
a
bunch
of
http
2
features
and
provides
a
bunch
of
additional
functionality.
A
All
of
the
code
is
in
open
source
on
github.
In
fact,
all
of
our
development
happens.
Github
first
and
the
team
at
google
does
import
it
on
a
daily
basis
into
google's
internal
code
base
where
it's
used
extensively,
but
all
of
the
development
code,
reviews,
proposals
and
testing
is
visible
to
everybody
by
our
github
site.
A
This
is
very
powerful
because
it
allows
people
to
use
the
right
language
for
the
task
at
hand
without
worrying
about
the
language
being
used
by
someone
else
that
they
need
to
interface
with.
So
you
might
have
a
android
client
using
grpc
java
for
android
calling
into
a
grpc
service,
that's
implemented
in
java
or
go
or
python,
and
these
two,
these
two
groups
can
be
relatively
independent
from
each
other,
except
for
the
service
definition
that
they
both
need
to
agree
on.
A
In
addition
to
languages,
grpc
is
also
available
on
many
different
platforms.
We
are,
of
course,
heavily
used
on
linux.
Grpc
is
also
available
and
widely
used
on
windows
and
mac
os,
in
addition
to
both
ios
and
android,
as
mobile
platforms
and
bindings
for
using
grpc
are
also
available
from
different
stacks
that
are
popular
across
the
across
the
community.
A
There
are
conventions
available
for
both
backward
and
forward
compatibility
of
these
apis,
so
one
does
not
necessarily
get
fixed
into
one
particular
version
of
the
contract
that
they
specified
at
a
point
in
time
now
I
will
point
out
here
that
conventions
for
doing
things
like
semantic,
versioning
or
rest
or
crud
can
all
be
implemented.
On
top
of
this,
these
interface
definition
languages
like
protocol
buffers,
and
they
are
in
a
way
complementary,
instead
of
being
mutually
exclusive.
A
Performance
and
efficiency
has
been
one
of
the
core
focuses
of
grpc
http
2
itself
was
designed
for
higher
performance,
and
this
starts
becoming
more
and
more
critical.
As
you
go
to
service
to
service
communication,
where
you
typically
want
to
reuse
the
connections
and
really
leverage
all
redundancy
in
the
communication
to
try
to
be
very
efficient
and
fast,
and
this
is
where
grpc
really
shines
and
you
would
see-
or
you
should
expect
to
see
a
significant
amount
of
improvement
over.
A
The
grpc
libraries
were
designed
to
be
extensible,
there's
a
lot
of
functionality
that
is
provided
out
of
the
box.
If
you
take
the
example
of
authentication
mechanisms
or
monitoring
solutions,
but
there
are,
there
are
additional
extension
and
customization
points
depending
on
the
language.
We
typically
have
a
facility
for
interceptors
additional
facilities
for
plugging
in
custom
transports,
and
these
allow
various
users
in
the
community
to
to
plug
in
their
own
solution,
their
own
preferred
solution
for
all
kinds
of
features,
and
you
have
a
bunch
of
them
listed
on
this
slide.
A
Finally,
ease
of
use
is
something
that
has
been
a
priority
for
the
community
working
around
grpc
early
in
the
project.
There
was
a
lot
of
emphasis
on
improving
the
installation
experience
and
we
do
a
lot
of
work
to
make
sure
that
there's
a
single
line,
installation
available
in
in
several
languages
that,
where
your
pc
is
used
heavily,
the
apis
have
again
been
designed
to
be
idiomatic
for
the
target
language,
and
we
continue
to
explore
api
paradigms
as
languages
evolve
and
come
up
with
new
idioms
for
expressing
asynchronous
functionality.
A
Jrpc
was
designed
from
the
ground
sub
to
support
streaming
rpcs
under
the
hood.
We
just
implement
a
bi-directional
streaming.
Rpc
wire
protocol
and
all
the
different
variations
that
you
see
listed
on
top
of
this
slide
are
actually
implemented
as
special
cases
of
that
bi-directional
stream,
and
for
that
reason,
grpc
does
really
shine
when
you
get
various
streaming
use
cases
which
do
end
up
appearing
as
you
get
towards
the
more
sophisticated
ends
of
distributed
system
design.
A
As
mentioned
before,
all
of
the
development
happens
on
github
grpc
has
been
in
cncf
for
over
three
years
now,
and
all
design
changes
go
through
an
rfc-like
process
being
standards-based
has
been
very
powerful
for
grpc.
It
has
allowed,
for
example,
the
ability
to
interoperate
across
proxies
and
firewalls
built
by
different
vendors
without
any
explicit
action
on
the
part
of
the
development
team
working
on
grpc.
A
A
We
have
a
feature
called
channel
z,
which,
for
example,
allows
you
to
request
details
of
live
connections
and
get
all
kinds
of
detailed
information
about
how
much
data
has
been
sent
back
and
forth.
What
kind
of
compression
benefits
are
being
realized
and
so
on,
and
these
things
allow
very,
very
powerful
monitoring
of
life
systems
as
well
as
good
details
when
one
needs
to
debug
or
optimize
their
system.
A
All
of
this
has
resulted
in
very
good
adoption,
and
today,
grpc
is
used
heavily
across
the
industry
by
a
number
of
organizations.
Large
and
small
and
all
kinds
of
teams
trying
to
build
distributed
systems
is
just
a
summary
of
what
we
talked
about
in
terms
of
features
again,
you
know,
there's
a
lot
of
emphasis
on
being
available
everywhere,
being
able
to
provide
the
right
extensibility
while
paying
attention
to
ease
of
use
streaming,
support
and
standards.
Compliance
is
there.
A
We
have
chosen
to
go
with
the
envoy
apis.
These
are
called
xds.
Apis
x
is
for
the
different
variations
of
discovery
services,
there's
a
listener,
discovery
service,
a
lot
of
discovery,
service,
cluster
discovery,
service
and
so
on.
So
these
xts
apis
have
been
defined
in
the
onboard
project
and
are
typically
used
by
the
onboard
proxy
when
speaking
with
a
control
plane
such
as
sto
to
try
to
orchestrate
the
communication
across
the
service.
A
Mesh
grpc
has
adopted
the
same
xts
apis
so
in
principle
the
same
control
plane
that
was
orchestrating
communication
between
applications
that
were
sitting
right
next
to
on
voice
side,
cars
that
same
control,
plane
can
now
orchestrate
communication
between
grpc
clients
and
servers
or
a
hybrid
scenario
where
one
end
point
is
using
an
on
voice.
Sidecar
and
the
other
end
point
is
a
straight-up
grpc
application.
A
Without
an
on
voice,
sidecar
proxy,
the
xts
support
has
been
released
in
jrpc
1.1.30
with
the
client
set
support
for
the
listed
xts
protocols
and
load
reporting
via
lrs
there.
There
is
additional
work
ongoing
and
the
team
is
continuing
to
look
at
more
and
more
of
these
service
mesh
features
in
the
xts
apis,
with
the
intention
of
providing
a
more
first-class
experience
for
grpc
developers
when
work
when
building
for
a
service
mesh
type
deployment.
A
A
A
A
A
A
It
doesn't
take
a
stance
on
exactly
what
conventions
an
application
developer
should
use
and
rest
is
a
set
of
conventions
that
have
been
shown
over
time
to
hold
some
value
in
terms
of
being
able
to
develop
and
build
application.
Apis
and
grpc
supports
rest
just
fine.
So
if,
if
someone
wants
to
use
the
rest
conventions,
they
can
absolutely
express
those
conventions,
while
using
grpc
as
the
underlying
mechanism
for
making
the
actual
calls
which
you
would
have
in
a
rest,
api,
so
the
rest
conventions.
A
A
Ultimately,
you
just
have
to
think
if
I
had
a
tcp
connection
between
this
client
and
server,
how
long
will
it
survive?
If
you
are
going
across
the
internet,
it's
unlikely
that
it
will
survive
for
longer
than
a
day.
If
it's
within
the
same
data
center,
you
might
have
much
better
control
and
they
might
survive
for
much
longer.
A
Is
there
an
out
of
the
box,
possibility
to
send
push
notifications
from
server
to
client,
so
grpc
does
not
support
push
notifications
per
se.
What
it
supports
is
the
ability
for
a
client
to
make
a
request
and
watch
for
a
notif
make
a
watch
style
rpc.
So
the
watch
style
is
where
the
client
says:
hey,
I'm
interested
in
any
changes
to
this
resource.
A
A
A
Then
you
can.
We
can
have
interoperability
between
an
http
client
and
a
grpc
server.
However,
some
of
the
things
that
are
available
to
a
plain
grpc
client,
for
example,
streaming
bi-directional
streaming
of
messages,
http
2
flow
control,
http
2,
multiplexing
of
multiple
requests
on
top
of
the
same
http
2
session.
A
A
Again,
the
answer
here
is
yes:
grpc
has
a
facility
to
to
transmit
something
called
metadata
from
client
to
server
and
back
in
the
direction
of
server
deployment,
and
the
metadata
are
transmitted
as
http
2,
headers
and
effectively.
The
application
developer
has
full
control
on
what
that
metadata
is,
and,
in
fact,
the
standard
grpc
library
is
typically
shipped
with
or2
support.
A
A
The
actual
validation
logic
would
have
to
be
provided
elsewhere.
Grpc
would
not
provide
the
validation
logic
on
the
server
side,
but
the
facility
to
expose
the
oauth
to
a
job
token
to
the
application
is
there
and
the
application
can
then
turn
around
and
use
a
use,
an
appropriate
validation
library
too,
to
perform
the
validation.
A
Yes,
it
does
in
fact,
because
it's
a
client
server,
rpc
protocol,
all
communication,
both
in
terms
of
initial
connection
and
individual
rpcs,
have
to
be
initiated
by
the
client.
The
server
cannot
choose
unilaterally
to
initiate
a
new
rpc
or
a
new
connection
to
a
client.
The
client
is
the
one
that's
in
charge.
The
client
is
the
one
that
makes
the
initial
request.
A
A
Yes,
event.
Driven
works,
fine
with
grpc.
In
fact,
most
or
I
would
say,
many
implementations
of
grpc
in
languages
such
as
c
plus
plus
java
are
are
sort
of
asynchronous
by
design.
As
long
as
you
know,
the
application
developer
has
chosen
this
particular
architectural
paradigm,
there's
nothing
in
the
corresponding
grpc
library.
That
would
stop
them
from
doing
it.
All
you
need
to
do
is
for
your
language
of
choice.
A
A
The
next
question
is
from
frank:
herman
is
jrpc
a
good
choice
to
send
audio
or
files
to
the
back
end.
Yes,
the
answer
is
grpc
works,
just
fine
for
sending
binary,
audio
or
other
files.
The
idea
would
be
that
you
know
your
rpc
request
would
have
a
binary
type
in
protocol
buffers.
That's
you
know,
field
named
bytes
and
your
bytes
can
be
any
type
of
data,
whether
it's
audio
or
other
files.
A
A
So
this
is
a
pretty
common
use
case
and
if
you
look
at
the
type
of
services
that
people
are
building,
there
are
many
file
oriented
services,
storage
services
that
have
been
built
using
grpc
and
there's
many.
There
are
many
live
audio
and
video
services
being
implemented
over
grpc.
So
it's
absolutely
a
valid
choice
for
those
use
cases.
A
A
Many
open
source,
reverse
proxies
like
the
envoy
proxy
and
nginx
already
support
jrpc.
So
you
just
need
to
work
with
your
reverse
proxy
or
your
load
balancer
to
configure
it
for
grpc
in
general,
any
proxy
that
supports
http,
2
or
any
load
balancer
that
supports
http
2
by
definition,
supports
grpc
out
of
the
box.
A
We
are
running
out
of
time,
so
I'll
try
to
go
through
a
few
more
questions,
and
then
we
will
have
the
slack
channel
where
I'll
continue
to
answer
any
questions
that
come
up.
So
the
next
question
is:
are
there?
Is
there
any
type
of
performance
loss?
Typically,
there
is
a
lot
of
attention
paid
to
performance
with
in
the
grpc
development
in
all
of
the
different
languages.
A
In
terms
of
penalties,
you
can
still
expect
to
pay
a
small
performance
penalty
for
framing,
because
your
pc
does
multiplex
messages
from
different
rpcs
on
the
same
tcp
stream,
so
that
would
be
a
small
performance
penalty
and,
depending
on
the
use
case,
you
might
see
some
amount
of
synchronization
overheads,
especially
if
the
use
case
is
such
that
a
single
tcp
connection
in
a
single
rpc
stream
is
all
that
was
needed.
Having
the
ability
to
scale
up
is
not
necessarily
needed.