►
From YouTube: gRPC Easy - Richard Belleville, 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.
gRPC Easy - Richard Belleville, 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. Getting your micoservices talking to one another should be as simple as "import antigravity". Come hear about the latest developments in gRPC's Python bindings that make getting up and running easier than it's ever been. This talk will cover running services without generating code and simplifications in channel management.
https://sched.co/ZexG
A
Hi,
I'm
richard
belleville
and
I'm
a
software
engineer
at
google
on
the
grpc
team.
I
am
awesome
on
most
things:
github
and
twitter,
for
example,
and
today
I'm
going
to
talk
about
a
project.
I've
been
working
on
called
grpc,
easy
first,
a
little
bit
about
myself.
I
have
been
working
for
google
for
about
a
year
and
a
half
now
primarily
on
the
python
bindings.
A
Before
that
I
was
working
at
a
smallish
networking
company
called
adtran.
I'm
glad
that
I
spent
time
there
first
because
it
gave
me
a
ton
of
perspective.
The
thing
about
small
companies
is
that
everyone
tends
to
be
less
specialized.
You
have
to
be
generalized
in
order
to
cover
all
of
that
ground
that
needs
to
be
covered.
So
in
my
time
there
I
got
to
help,
build
and
maintain
a
custom
messaging
framework
as
well
as
build
our
own
container
orchestration
framework
before
kubernetes
became
the
defacto
standard
and
then
migrated
to
community
kubernetes.
A
Once
we
saw
the
writing
on
the
wall.
Since
google
is
such
a
big
company,
most
people
are
hyper
focused,
which
can
sometimes
lead
to
myopia.
So
I'm
glad
I
had
my
experience,
my
previous
company
as
a
member
of
the
target
demographic
for
grpc,
because
I
think
that's
enabled
me
to
empathize
with
our
users
a
little
bit
better
than
I
otherwise
would
have
okay.
So
enough
about
me,
let's
talk
about
grpc,
although
this
talk
is
called
grpc
easy.
A
This
is
not
an
introductory
talk
on
grpc,
so
I'm
not
going
to
be
over
going
over
all
of
the
basics
in
detail.
If
that
is
what
you're
looking
for
there's
another
talk
at
kubecon
that
I
believe
should
have
aired
yesterday
called
intro
to
grpc
by
abhishek
kumar
the
tech
lead
for
grpc
at
google.
If
you're
not
watching
this
live,
you
should
probably
pause
me
and
go
watch
that
talk
or
one
of
the
other
various
intros
talks.
Now.
A
For
the
benefit
of
those
of
you
who
are
watching
live,
let's
do
a
very
brief
recap
of
the
structure
of
an
application
using
grpc
grpc
is
an
rpc
framework.
Rpc
standing
for
remote
procedure
call
when
you
boil
away
all
the
fat.
This
means
that
we're
a
library
and
a
set
of
development
tools
that
enable
you
to
define
and
call
a
function
so
that
it
runs
on
a
different
machine
from
the
caller,
though
it
could
run
on
the
same
machine
if
you
set
things
up
that
way.
A
A
But
when
I
talk
about
grpc
in
this
presentation,
you
can
safely
assume
that
I'm
talking
about
the
original
implementations
built
by
google
since
they're,
the
oldest
most
robust
and
most
popular,
so
a
default
grpc
is
a
point-to-point
client
server
model
where
the
client
and
server
can
be
in
different
languages
very
much
like
http
json
rest.
The
difference
is
in
the
payload
and
the
different
concurrency
models
you
can
use.
A
So
if
you're
going
to
call
a
function,
both
the
caller
and
the
colleague
need
to
know
the
api
and
the
abi
the
application
binary
interface
by
default,
but
not
as
a
requirement
grpc
uses
protocol
buffers
for
that.
So
you
can
see
an
example
of
what
a
protocol
buffer
service
definition
looks
like
here.
It
looks
very
similar
to
how
you
would
define
a
function
in
say
c.
So
that's
what
grpc
is,
what
about
its
users
and
how
they
feel
about
it.
Well,
grbc
has
found
very
wide
usage
in
the
data
centers
of
big
high
traffic
companies.
A
A
Well,
we
hear
it's
well
supported.
You
have
a
preferred
language.
That's
all
we've
got
binding
and
tooling
for
it.
You
wanna
run
windows.
We
got
you,
you
need
to
run
an
arm,
no
problem.
We
hear
that
it's
performant
at
the
transport
level
we
introduce
very
little
overhead.
A
lot
of
complex
logic
has
been
put
in
place
to
ensure
maximal
performance
for
multi-threaded
applications
and
protocol
buffers
being
a
binary,
serialization
format
cut
down
substantially
on
the
amount
of
time
you
would
otherwise
be
serializing
and
deserializing
json.
A
A
We
hear
that
it's
robust
when
it's
got
a
bug
report
for
a
server
that
crashed
after
a
year
of
serving
we
fixed
the
bug,
but
learned
that
we
were
down
to
once
a
year
sorts
of
bugs
in
the
stack,
and
they
say
that
it's
safe,
the
interface
definition
language
provided
by
protobufs,
helps
save
you
from
shooting
yourself
in
the
foot
by
sending
an
accidentally
malformed
request
to
the
server
it's
like
using
a
statically
typed
language
after
being
forced
to
use
an
untyped
language
forever.
But
is
it
easy
to
use?
A
I
don't
think
I've
ever
gotten
that
sort
of
feedback
before
very
often
the
task
of
migrating.
These
organizations
to
grpc
lands
on
the
shoulders
of
a
platform
team
like
an
ipc
team.
Part
of
the
reason
for
that
is
that
migrating
from
an
existing
messaging
system
can
be
tricky,
but
part
of
it
is
likely
that
using
grpc
itself
isn't
always
that
easy,
and
we
sometimes
get
positive
confirmation
on
that
from
smaller
organizations
and
individuals
struggling
to
roll
out
grpc,
the
grpc
team
regularly
scours
stack
overflow
and
answers
as
many
questions
as
we
can.
A
This
here
is
just
a
sampling
of
python
related
issues
that
we've
seen
now
it's
unavoidable.
Whatever
your
project
is
that
some
users
are
going
to
have
questions
about
it,
but
if
you
want
to
be
inclusive
and
popular,
your
goal
should
be
to
minimize
the
level
of
surprise
and
of
cognitive
burden
for
everyone
as
much
as
possible.
A
A
I'm
gonna
wager
the
majority
of
people
watching
this
talk
of
used
requests,
even
if
python
isn't
their
daily
driver.
Why?
Well
one
python
is
easy
writing
an
integration
test.
Do
it
in
python
writing
a
supporting
script.
Do
it
in
python,
working
to
start
up
and
need
to
move
fast,
hey
it
worked
for
reddit.
Do
it
in
python
two,
the
request
library
is
easy.
You
can
sneeze
and
accidentally
send
some
json
to
a
different
continent.
A
Personally,
I
think
this
is
one
of
the
major
reasons
why
http
json
rest
has
become
so
very,
very
popular,
ubiquitous,
user-friendly
libraries.
So
what
you're
looking
at
now
is
the
gist
that
introduced
the
request.
Library
to
the
world
on
the
left
is
what
making
http
get
requests
look
like
before
the
request
library
came
out
of
the
scene
and
on
the
right
is
what
making
an
http
cat
looks
like
after
the
request
library
was
introduced,
import
the
library
then
do
the
call
so
simple.
I
always
get
a
kick
out
of
the
first
comment
to
this
gist.
A
A
So
one
day
I
decided
to
point
out
my
issues
with
the
library
to
piece
of
paper.
This
was
eventually
transport
transformed
into
a
design
dock,
but
at
the
time
I
just
called
it
a
complaint
doc.
There
were
a
lot
of
little
things,
but
there
were
really
two
main
friction
points
that
I
saw
the
first
had
to
do
with
protocol
buffers
I
like
to
lurk
around
github
for
people
pulling
in
our
library,
so
I
can
see
exactly
how
they
use
it.
A
My
first
observation
was
that
the
vast
majority
of
people
are
not
advanced
users
of
the
api.
The
second
thing
I
noticed
is
that
people
have
absolutely
no
idea
what
to
do
with
protocol
buffer
definition
files.
So,
unlike
rest,
grpc
has
a
build
time
step,
even
if
you're,
using
an
interpretive
language
like
python
or
node,
you
feed
your
dot
proto
file,
which
contains
your
service
definition.
A
You
know
your
function,
signature
into
the
protocol
compiler
and
it
spits
out
code
in
your
language
of
choice
that
you
can
pull
into
your
client
and
server
code
now
internal
to
google.
This
is
all
abstracted
away
from
the
user.
There
was
a
paper
published
in
acm
back
in
2016
that
describes
in
detail
what
google
source
control,
build
and
test
systems
look
like
called.
A
I
believe
why
google
stores
billions
of
lines
of
code
in
a
single
repository.
I
encourage
you
to
take
a
look
at
that
afterwards,
but
in
short,
google
doesn't
scatter
its
code
base
across
dozens
or
hundreds
of
tiny
git
repos
connected
together
by
package
managers
like
is
fashionable
in
the
open
source
community
stays.
Instead,
google's
code
base
is
live
at
head.
Every
source
file
lives
in
a
single
code
base
called
google
three
and
an
internal
build
system
called
blaze
tracks
every
source
file
and
every
intermediate
target,
so
that
the
build
system
is
completely
hermetic.
A
The
build
system
is
general
enough
that
they
created
a
rule
set
that
allows
you
to
say
I
have
a
dot
proto
file
and
I
want
a
library
in
c
plus,
plus
or
java,
and
then
you
can
just
add
a
dependency
on
that
library,
as
simply
as,
if
you
were
any
as
simple
as
if
you
were
pulling
in
a
library
in
your
target
language.
I
believe
the
use
case
of
protocol
buffer
code
gen
was
actually
a
driving
factor
for
the
crazy
generality
of
blaze,
which,
by
the
way,
has
relatively
recently
been
open
sourced
as
battle.
A
Agnostic
build
systems
are
exceedingly
rare,
so
while
they're
integrations
with
maven
and
setup
tools
and
various
other
language-specific
build
systems,
you
still
have
to
figure
out
how
to
integrate
with
those
specialized
rules,
and
then
you
have
to
be
the
one
to
worry
about
how
you
pull
down
the
protocol
buffer
files
from
the
central
source
and
what
to
do
with
the
generated
code.
So
what
do
most
people
do
the
simplest
thing
they
copy
the
dot
proto
file,
so
they
have
one
copy
of
their
client
repo
and
then
one
copy
on
their
server
repo.
Okay.
A
Now
these
two
have
to
stay
in
sync.
Every
time
you
or
anyone
else
makes
an
update
to
the
service
definition
or
to
a
message
definition.
They
have
to
remember
to
update
both
fun.
That's
called
kinesins
if
you're
looking
for
the
exact
software
coupling
term
okay,
so
you've
copied
your.profile
across
multiple
repos.
Now
you
struggle
with
the
protocol
compiler
command
line
interface.
A
This
is
all
in
the
tutorial
on
our
website,
but
once
you
start
pulling
in
multiple
proto
files,
or
you
have
expectations
about
what
language
specific
module,
the
code
should
be
importable
as
in
for
a
fun
time,
so
people
maybe
figure
that
stuff
out,
if
not,
they
probably
hand,
modify
the
generated
code.
I've
seen
that
on
github
affair
a
few
times
now,
when
you
check
and
hand
modify
generated
code,
the
next
person
that
makes
an
update
to
the
dot
product
file
is
in
for
a
nasty
surprise.
A
A
So,
in
practice,
the
people
who
are
successful
with
protocol
buffers
tend
to
store
all
of
their
organizat
organizations.proto
files
and
a
single
repo
and
then
pull
that
repo
into
their
client
and
server
repos
using
git
sub
modules.
Then
they
integrate
code
generation
into
whatever
build
tool
they're
using
so
that
developers
don't
ever
have
to
deal
with
generated
code
directly.
So
that's
the
first
pain
point
juggling
produce.
A
A
A
I
actually
heard
a
good
joke
about
this
sort
of
thing.
Once
an
http
library
walks
into
a
bar
and
orders
a
beer,
it
takes
the
beer
and
walks
out
the
bar
one.
Second
later
it
walks
back
into
the
bar
and
orders
another
beer
takes
it
and
walks
out
of
the
bar
and
so
on
and
so
forth,
often
http
libraries
unnecessarily
spin
up
and
tear
down
tcp
connections.
A
So
grpc's
current
approach
is
to
get
the
application
author
to
tell
us
when
they're
done
ordering
beers,
at
which
point
they
close
their
channel,
the
tcp
connection
is
shut
down
and
the
memory
used
to
manage
the
channel
is
returned
to
the
system.
But
in
practice
we
don't
see
people
closing
their
channels
ever.
A
In
fact,
we
often
see
servers
that
need
to
send
downstream
requests
spin
up
a
new
channel
for
each
request
they
receive
and
they
don't
ever
close
those
channels,
memory,
link
nasty
surprise
for
them
down
the
road
and
we've
seen
this
sort
of
problem,
not
just
with
open
source
users
but
with
users.
Internally,
google,
we
introduced
a
context
manager
based
api
to
combat
it,
but
that
just
didn't
seem
to
be
enough.
A
Even
if
you
do
use
the
contacts
manager
version,
it
adds
an
extra
level
of
indent
and
it
isn't
very
pretty
to
look
at
so
with
those
problems
in
mind.
I
try
to
create
a
before
and
after
picture
for
grpc
python.
Just
like
requests
did
so
here's
that
before
and
after
picture
on
the
left,
you
see
the
before
we
import
the
grpc
library
and
then
import
our
two
generated
files.
Then
in
the
main
function
we
first
construct
a
stub.
A
We
never
wrote
the
symbol,
greater
stub
into
our
dot
proto
file,
but
we
have
to
use
it.
Nonetheless,
honestly,
I
usually
have
to
look
in
the
generated
code
to
remember
what
that
name
should
be.
Then
we
construct
a
protobuf
request.
Payload
make
an
rpc
against
the
local
host
using
the
stub
and
request
a
message,
and
finally,
we
print
out
the
response,
not
a
great
delivery
on
the
idea
of
a
function
call
but
on
another
machine.
A
So
you
see
we're
using
a
contact
manager
here
to
manage
the
lifetime
of
our
channel.
I
know
from
my
github
lurking
the
usage
of
this
form.
Isn't
very
common
people
generally
just
create
their
channel
and
don't
close
it
fire
and
forget
and
of
course
we
have
to
generate
our
code
using
good
old
product
for
python.
We
provide
the
pip
installable
grpcio
tools
package
that
bundles
protoc
and
the
grpc
python
plug-in
on
the
right.
You
can
see
our
attempt
at
getting
closer
to
the
ease
of
use
of
requests.
A
We
still
import
grpc
the
same
way,
but
now,
instead
of
generating
code
as
a
build
time
step,
you
can
import
serialization,
deserialization,
sub
and
service
or
code
from
a
dot
proto
file
at
run
time.
Instead
of
remembering
that,
there's
an
underscore
pb2
or
underscore
pb2,
grpc
suffix
you
just
import
the
dot
protofile
that
you've
written
and
chose
the
name
of
and
is
checked
into
source
control.
The
object
you
get
back
is
a
python
module
object,
but
you
can
name
it
whatever.
You
like
in
general,
I
like
to
call
them
protos
and
services.
A
So
we
create
a
request
message
and
then
in
a
single
line,
we
send
our
message
and
receive
the
response
function.
You
invoke
is
greeter
dot,
say
hello,
which
is
exactly
what
we
wrote
in
our
dot.
Proto
file
no
need
to
remember
arbitrary
suffixes
or
to
look
them
up
from
the
generated
code.
You
may
have
accidentally
checked
in.
A
Okay,
so
let's
look
at
things
a
little
bit
more
depth.
First,
there's
the
runtime.proto
file
parsing.
What
these
new
functions
do
is
integrate
with
the
python
import,
live
import,
lib
module
to
instantiate
modules
directly
from
a
dot
proto
file
in
your
python
path.
This
depends
on
the
presence
of
the
grp
cio
tools
package
that
you've
traditionally
used
at
build
time
that
bundles
the
c
extension
that
does
the
actual
parsing
and
code
chat
for
protobots.
A
What's
really
nice
about
this
is
that
it
lowers
the
barrier
to
entry
for
prototyping
change,
some
fields
around
your
dot
proto
file,
no
need
to
recompile,
just
restart
your
client
or
server.
It
was
also
really
important
to
us
that
you'd
be
able
to
mix
together
generated
code
with
code
loaded
directly
from
a
dot
proto
file
at
runtime,
so
your
runtime
parse
files
can
import
from
dot
profiles
that
have
already
had
code
generated
for
them
and
vice
versa.
A
That
way,
if
you
prefer,
you
can
use
runtime
parsing
while
developing
and
pre-generate
the
code
when
you're
ready
to
put
it
into
production.
Alternatively,
if
you're
distributing
your
application
as
a
wheel,
you
can
now
just
include
your
dot.
Protofile
in
the
wheel,
instead
of
generating
python
code
from
it
and
including
that.
A
The
other
big
change
that
we've
made
is
channel
pooling
now,
instead
of
manually,
creating
a
channel
then
creating
a
stub
from
that
channel.
You
can
do
something
that
really
does
just
look
like
calling
a
function.
Of
course,
this
is
backed
by
the
same
sort
of
channel
that
you
would
have
used
before
it's
just
lazily
instantiated
and
kept
in
a
process
global
cache
after
a
configurable
period
of
time,
without
any
use
channels,
will
be
evicted
from
the
cache
without
any
intervention.
A
A
If
you
want
to
see
a
full
in-depth
build
out
of
this
example,
you
can
just
look
my
name
on
youtube.
There's
one
in
go
and
another
in
python,
I'm
going
to
be
building
up
on
the
python
example,
and
I'm
only
going
to
be
showing
off
the
client
here,
since
the
improvements
we
just
talked
about
over
the
past
couple
of
slides
are
really
only
on
the
client
side.
If
you
like,
you
can
actually
pull
down
the
go
version
of
the
server
from
the
previous
talk
and
test
it
out
against
the
client
code.
A
From
today's
talk,
likewise,
the
client
code
will
be
available
on
my
github,
so
the
key
value
store.
We're
building
is
really
just
a
network
accessible
version
of
this
data
structure.
In
python
you
can
store
a
value
under
a
particular
key.
You
can
get
a
value
under
a
particular
key
and
you
can
check
whether
a
particular
key
exists
within
the
store.
It's
nothing
very
fancy,
okay.
So
this
is
what
our
protocol
buffer
definition
looks
like
we've
got
a
record
consisting
of
two
strings:
a
key
and
a
value.
A
A
A
Most
of
the
implementations
are
a
single
line
to
invoke
the
rpc
and
then
a
single
line
to
print
the
results.
You
can
see
one
new
argument
here,
which
is
insecure,
equals
true.
This
was
actually
a
point
of
debate
when
designing
these
apis.
We
wanted
to
make
things
as
easy
as
possible,
but
in
2020
you
really
don't
want
to
make
anything
insecure
by
default,
so
the
default
is
actually
tls
encryption
and
if
you
want
to
do
a
plain
text,
connection
for
unit
testing,
for
example,
then
you
have
to
opt
in
with
this
explicit
keyword
argument.
A
So,
let's
start
with
grp
curl
to
quit
its
readme
from
github.
It
is
a
command
line
tool
for
grpc
servers,
it's
basically
curl
for
grpc
servers.
I
think
that
says
about
80
of
it.
The
really
cool
thing
about
this
is
that,
if
you
don't
necessarily
is
that
you
don't
necessarily
need
to
write
the
sort
of
client
that
we
just
spent
the
last
few
slides.
A
Looking
at
for
simple
use
cases,
you
can
just
write
a
shell
script
that
uses
jrp
curl
gp
curl
was
written
by
joshua
humphreys
who's
a
developer
at
full
story.
He
gave
a
presentation
on
the
tool
at
gophercon
2018,
so
take
a
look
at
that.
If
you
want
more
details
on
it,
so
here's
an
example:
usage
of
grp
curl
to
interact
with
the
key
value
store.
A
We
just
talked
about
there's
a
plain
plain
text:
flag
here,
because
again
insecure
by
default,
bad
there's,
the
payload,
which
is
defined
in
json
here,
there's
the
server
target
and
there's
the
fully
qualified
method
that
we
want
to
invoke
boom
out
comes
a
record,
but
there's
a
catch.
We
supplied
json.
A
A
There's
a
grpc
service
definition
that
allows
a
server
to
tell
interested
clients
exactly
what
methods
it
has
and
what
the
in
messages
and
out
messages
look
like.
So
when
we
ran
grp
curl
here,
what
happened
was
the
grp
curl
process?
First,
read
a
query
against
the
reflection
server
at
the
target
we
specified.
A
It
used
the
information
it
learned
to
serialize
our
json
into
a
protobuf
serialized
format.
The
catch
is
that
you
have
to
choose
to
export
a
reflection
server
on
your
target.
It's
really
easy
in
all
languages,
just
a
couple
of
lines
of
code,
but
it's
an
opt-in
process
and
there
are
certain
instances
in
which
you
may
not
want
to
for
security
reasons,
for
example,
but
reflection
is
actually
even
cooler
than
this.
What
it
really
gives
you
more
than
anything
else,
is
discoverability.
A
So
that
is
as
far
as
tips
and
tricks
for
making
grpc
easy
goes.
But
I'd
like
you
to
know
that
we're
absolutely
receptive
to
contributions
and
suggestions
to
do
with
usability.
So
if
you
have
an
idea
or
even
just
a
complaint,
please
provide
us
with
more
feedback.
One
of
the
hardest
things
about
maintaining
an
open
source
project
is
that
more
often
than
not
when
something
is
broken
or
difficult
to
use.
We
never
hear
from
that
user.
They
just
drop
the
library,
so
we
definitely
do
value
the
feedback.
A
When
we
hear
from
our
existing
or
potential
users,
the
two
places
that
you
would
want
to
give
that
feedback
are
one
of
the
several
github
repos
that
has
their
implementation
or
the
grpc-io
google
group,
which
is
where
we
sort
of
conduct
official
business
like
api
extension
proposals
or
just
answer
questions
and
the
apis
that
you
saw
here
today
should
be
available
in
the
next
release
of
grpc.
If
you
want
to
try
them
out
before,
then
you
can
just
pull
from
our
nightly
builds.
So
with
that,
I
think
we
can
move
on
to
questions.
A
Hello,
everybody
glad
to
see
you
all
live
now.
I
think
we're
gonna
go
ahead
and
get
started
with
questions.
So
please
forgive
me
if
I
mispronounce
any
of
your
names,
I'm
sorry
about
that.
First,
one
I
see
is
from
deepak
any
provision
to
generate
uml
model
from
proto,
it's
possible
that
such
a
tool
exists
within
the
community
ecosystem.
A
A
There's
an
environment
variable
that
allows
you
to
tell
the
protocol
compiler
where
to
look
for
those
and
it's
a
very
simple
format
where
it
takes
a
serialized
protocol,
buffer
message
on
standard
n
and
it
outputs
code
on
standard
out,
and
so
you
could,
for
example,
take
in
an
arbitrary
protocol
buffer
and
output,
a
uml
file
in
any
format
that
you'd,
like
so
chandra
asks.
When
would
you
use
grpc
rather
than
when
you?
When?
Would
you
not
use
grpc?
A
A
There
might
be
some
network
elements
that
aren't
going
to
support
everything
you
might
be
running
in
a
browser
that
doesn't
support
trailers,
which
is
most
of
them.
At
the
moment
I
will
say
for
a
caveat:
there
is
grpc
web
which
allows
you
to
get
most,
but
not
all
of
the
functionality
of
grpc
and
requires
a
proxy
in
the
middle.
So
those
are
circumstances
where
you
might
choose
not
to
use
grpc.
A
I
did
give
you
a
bunch
of
pros
at
the
beginning
of
this
talk
of
grpc
like
type
safety,
for
example.
The
the
other
big
area
where
you're
going
to
want
to
use
grpc
is
where
you
need
streaming
or
you're.
You
have
very.
You
have
a
lot
of
sensitivity
to
latency
right.
So
in
an
event-driven
model
you
don't
want
the
clients
to
be
polling,
because
polls
always
have
a
cooldown
between
each
poll.
What
you
want
is
for
the
server
that
sources.
A
The
events
to
push
them
to
the
client,
that's
when
grpc
streaming
is
going
to
be
incredibly
valuable
to
you
on
the
next
one
deepak
asks
does
protobuf
support,
inheritance
and
composition.
That's
a
really
good
question,
so
composition,
very
basic
feature
of
protobufs.
You
can
arbitrarily
nest
message
types
inside
of
each
other
and
that's
going
to
allow
you
to
do
composition.
A
As
for
inheritance,
there
isn't
inheritance,
as
you
know
it
from
languages
like
java
c
plus,
but
there
is
a
feature
called
extensions
which
allow
a
message
to
say
that
they
are
reserving
certain
field
numbers
for
a
third
party
usage,
which
means
that
an
application
that
uses
any
particular
message
is
able
to
add
their
own
fields
defined
by
their
file
with
within
those
extensions.
So
that's
that's
some
something
akin
to
inheritance.
A
Chandra
asks
when
there's
a
simple
client
server
architecture.
Would
you
still
recommend
grpc
versus
normal
rest?
Absolutely
the
other
thing
that
I
I
will
say
there
is
people
sort
of
build.
This
false
dichotomy
between
grpc
and
rest.
Rest
technically
is
a
set
of
semantics
for
how
you
build
your
apis
and
you
can
build
a
restful
grpc
service.
It
just
means
that
you
need
your
rpcs
to
be
resource
oriented.
A
A
Christian
asks
what
about
using
golang
for
grpc
proto?
Is
there
also
a
way
to
directly
make
use
of
the
dot
protofiles?
If,
yes,
how
is
code
completion
handled
than
an
ides?
If
no,
what
do
you
recommend
here
check
and
generated
code?
Okay,
so
I
think
you've
keyed
into
something
crucial,
which
is
for
comp
for
compiled
languages.
A
This
scheme,
where
we
load
from
dot
protofiles
at
runtime,
does
not
work
the
same
way.
The
reason
that
it
works
in
python
and
node
and
could
potentially
work
in
php
and
ruby
is
because,
when
you
say
fu.bar,
you
know
you
access
a
bar
member
of
a
variable
foo
in
those
languages,
you're
literally
doing
a
dictionary,
look
up
right,
you're,
looking
up
that
symbol
bar
at
run
time,
that's
not
what's
happening
in
the
compiled
languages
in
the
compiled
languages.
A
A
You
could,
in
principle,
do
something
similar,
but
the
way
that
you
would
access
the
protos
individual
members
of
a
protocol
buffer
message
would
be
very
different
and
not
quite
as
idiomatic.
So
that's
the
first
part
of
the
question
you
couldn't
principal,
do
it.
I
wouldn't
recommend
it.
The
other
question
was:
if
no,
what
do
you
recommend
here
check
in
generated
code?
A
I
would
still
say:
try
your
very
best
not
to
check
in
generated
code.
There
are
a
couple
things
you
can
do
here.
The
first
one
is
going
to
be.
I
mentioned
that
internally
to
google
a
build
system
called
blaze
is
used.
That's
been
open
sourced
as
a
system
called
basil.
I
actually
think
that
the
go
tool
chain
was
inspired
by
a
lot
of
the
the
features
in
blaze.
You
could
just
use
basil
I've
seen
a
lot
of
goling
projects
using
basil.
A
If
you
don't
want
to
use
that,
if
you
want
to
use
the
vanilla
golang
tool
chain,
there
is
a
go
generate
command
that
might
meet
your
needs
in
general.
I
think
best
practice
is
to
include
your
generated
files
in
your
git.
Ignore
file
if
you're
using
git
bart
bart
smith
asks
is
using
the
protofiles
from
runtime
also
available
in
java,
no
not
to
my
knowledge,
but
with
the
same
caveat
as
in
the
previous
answer
that
you
could,
in
principle,
use
reflection
apis
to
read
from
a
dot
proto
file
at
runtime.
A
A
This
not
sure
I
fully
understand
the
question
okay.
So
yes,
if
we're
talking
about
differences
between
a
client
and
between
an
actual
local
function
call
and
one
against
a
grpc
server,
there
is
an
addition
to
the
arguments.
There's
also
the
target
server,
the
location
of
the
target
server,
and
there
are
things
like
transport
level
security.
A
A
That
would
help
to
abstract
that
away
a
little
bit.
I
don't
know
if
that
fully
answers.
Your
question,
though,
alex
asks
any
plans
to
add
more
officially
supported
languages
in
the
future.
So
I'm
I'm
I'm
wondering
if
this
is
about
grpc
in
general
or
if
this
is
about
the
features
that
I
discussed
here
today.
I'm
assuming
that
this
is
about
general
language
support.
No,
I
do
not
know
of
plans
for
additional
languages,
but
they're
popping
up
in
the
community
all
the
time.
For
example,
kotlin
support
recently
came
around.
A
I
know
of
multiple
rust
implementations
that
have
been
coming
around.
If
you
keep
your
eyes
peeled,
you
will
see
lots
of
other
languages
coming
around
and
if
you
have
any
language
that
you
care
about
in
particular,
it's
not
too
difficult
to
wrap
the
grpc
core,
which
is
which
is
it
used
to
be
a
plain
c89
set
of
apis
that
you
can
wrap
a
higher
level
api
around
now,
it's
c
plus,
but
there
it
is
a
relatively
stable
set
of
api.