►
From YouTube: Keynote: Lessons Learned in Building a gRPC Implementation for .NET... Sourabh Shirhatti & John Luo
Description
Keynote: Lessons Learned in Building a gRPC Implementation for .NET Core - Sourabh Shirhatti, Senior Program Manager & John Luo, Software Engineer, Microsoft
John Luo and Sourabh Shirhatti are part of the ASP.NET team at Microsoft working on the .NET Core implementation of gRPC. In this talk, they'll cover their experience in building a new gRPC implementation. They'll start by covering the design and limitations imposed by the existing .NET gRPC library and how the library attempts to address these concerns. As part of this deep dive, they'll also cover some of the design decisions that made in designing an opinionated framework and showcase the productivity and performance benefits introduced by the new library.
A
Just
to
get
started
john-
and
I
are
members
work
in
microsoft
and
we
work
on
the.net
application
frameworks
team
at
microsoft.
Our
team
maintains
the
web
framework
asp.net
core
as
part
of
the
web
framework.
We
also
ship
an
http
application,
server
called
kestrel
and
in
addition
to
that,
we
ship
a
set
of
libraries
for
common
cross-cutting
concerns
like
logging
and
configuration.
A
So,
let's
start
out
with
what
is.net
net
is
a
free
cross-platform,
open
source
developer
platform,
so
dotnet
encompasses
a
runtime,
it's
a
vm
based
runtime,
as
well
as
a
set
of
languages
and
compilers.
So
today
we
have
c
sharp
v
b
and
f
sharp
that
comprise
the
languages
and
then
obviously
with
the
associated
compilers,
and
in
addition
to
the
runtime
and
languages,
we
have
a
set
of
rich
standard
libraries
standard
libraries.
You
know
solve
concerns
like
file
io
right
into
the
console,
make
an
http
request.
A
A
A
A
So
what
I'm
going
to
show
you
today
is
john
and
I
have
built
the
game.
Let
me
just
go
ahead
and
open
two
instances
of
this
side
by
side.
So
this
is
a
trivia
application,
all
right.
So
what
I'm
going
to
do
is
on
the
left.
I'm
going
to
go
ahead,
join
this
game
and
play
as
alice
right
and
you
can
see.
When
I
hit
start,
we
make
a
grpc
call
and
now
we're
waiting
for
other
players
to
join
before
the
game
commences
on
the
terminal
window.
A
A
Let's
say
we,
let's
answer
it
correctly
for
both
alice
and,
let's
say
bob
in
this
case,
you
can
see
as
soon
as
both
players
have
done.
Answering
I'm
getting
more
calls.
Obviously,
you'd
be
curious,
know
how
this
is
your
pc,
so
I
could
the
other
thing
I
could
show
you
is.
I
could
hop
over
here
into
my
actual
server
and
I
can
show
you
like
these
are
metrics
being
collected
from
the
server
at
this
point
like.
A
A
I
obviously
at
this
point
have
told
you
that
I've
used
your
pc,
but
if
I
could
prove
it
out-
and
you
know
show
it
to
you
in
a
better
way,
that
would
be
nice.
Fortunately,
in
this
case
I
can
so
the
other
thing
I've
done
is
in
addition
to
setting
up
both
the
server
and
the
client.
If
I
help
back
over
to
my
dashboard,
is
I
actually
had
an
instance
of
zipkin
running
and
zipkin
has
both
both
the
clients,
as
well
as
the
server
instance
are
sending
their
distributed.
A
A
So
we
made
a
grpc
call,
you
can
see
it's
an
http
post
and
you
can
see
the
grpc
status
code,
so
this
was,
you
know
the
start
game
call
and
when
both
clients,
when
both
players
were
ready,
we
started
a
streaming
call.
You
can
see
this
went
on
for
a
long
duration.
You
can
also
see
the
path
and
status
code.
B
Okay
thanks,
so
let's
get
started
with
the
first
lesson,
which
is
to
take
advantage
of
the
platformprimitivesand.net
whenever
possible.
So
as
we
worked
on
developing
the
new
grpc
library,
we
noticed
the
theme
in
some
of
the
concerns
that
users
ran
into,
for
example,
folks
mentioned
that
it
wasn't
trivial
to
set
up
tls
for
hbs.
B
B
B
The
benefit
here
is
that
is
to
configure
an
hvs
endpoint.
The
app
doesn't
have
to
load
a
private
key
in
memory.
It
can
rely
on
the
cert
being
present
in
the
certificate
store
on
the
client
side.
We
don't
have
to
specify
the
public
key
of
the
hbes
endpoint.
We
can
rely
on
the
public
key
being
present
in
the
list
of
trusted
routes
in
the
certificate
store
as
an
additional
bonus
on.
We
also
get
support
for
hsms
and
secure
enclaves
for
free.
B
B
B
Another
common
request
we
have
heard
is:
how
do
you
configure
monitoring
of
your
grpc
services,
for
example?
Maybe
I
would
like
to
track
my
request
through
the
different
grpc
endpoints,
since
it's
rare
rarely
the
case
that
only
one
service
is
needed
to
serve
a
particular
request.
This
also
includes
figuring
out
which
services
are
being
called,
how
long
they're
taking
and
what
status
or
results
they
are.
Returning.
B
With
this
in
mind,
we
leverage
the
distributing
tracing
primitives
in.net
in
the
grpc.net
library
itself.
This
means
that
we
are
emitting
trace
information
by
default
and
no
additional
instrumentation
code
is
necessary
in
the
implementation
of
grpc
services
to
complete
the
distributed
tracing
story.
The
trace
information
we
emit
can
then
be
egressed
via
distributed
tracing
libraries,
including
open,
telemetry
collectors.
B
So,
for
example,
in
the
demo
we
showed
earlier,
we
use
zipkin
to
collect
and
visualize
our
traces.
Here
we
can
see
the
traces
that
were
collected
for
two
trivia
sessions,
each
of
which
consisted
of
three
grpc
calls.
We
can
also
see
some
of
the
metadata
of
these
calls,
such
as
the
status
codes
and
the
specific
urls,
where
the
grpc
call
was
made.
B
So
the
lesson
here
is
that,
by
leveraging
the
platform
primitives
provided
by
the
standard
library
for
the
language
ecosystem,
we
benefit
from
the
improvements
in.net
for
free.
We
saw
how
this
simplifies
configuring
hvs
and
distributed
tracing
just
to
list
a
few
more
benefits.
We
also
get
the
benefit
of
performance
improvements
in
the
hp,
server
and
hp
client,
which
we'll
discuss
in
more
detail
in
a
later
section.
Another
benefit
is
support
for
additional
architectures
will
get
them
as
they're
added.
B
For
example,
we
have
recently
seen
an
uptick
in
interest
for
supporting
arm
processors,
which
grpc.net
get
for
free.
By
contrast,
because
grpc.cor
uses
native
components,
support
for
additional
architectures
will
require
more
significant
work.
Of
course,
there
are
plenty
more
benefits
that
we
can't
go
into
detail
here,
such
as
support
for
hardware
intrinsics
or
additional
metrics
for
socket
layer,
but
the
overall
learning
here
is
that,
by
relying
on
the
platform
primitives,
we
are
not
isolated
on
an
island
separate
from
the
rest
of
the
platform.
A
Thank
you,
john.
What
I
want
to
do
now
is
speak
to
the
second
lesson
we
learned
this
actually
builds
upon
where
john
just
spoke
to
so
the
other
key
lesson
that
we
learned-
and
we
learned
this
while
building
asp.net
core,
we
were
able
to
equally
apply
it
while
building
jrpc.net
is
sharing.
Abstractions
makes
everyone
more
productive.
Let's
take
a
concrete
look
at
what
is
meant
by
this,
so
the
central
hub
of
any
jrpc.net
application
is
the
host
the.
A
So
the
core
of
a
hosted
app
is
just
a
set
of
services
that
are
started
and
stopped
with
the
lifetime
of
your
application.
One
such
example
would
be
your
http
application
server,
but
what
the
host
does
in
addition
to
managing
service
lifetime,
it
allows
you
to
configure
it
and
register
various
components
via
dependency
injection.
A
So
if
we
take
a
example,
if
we
look
at
logging,
both
of
the
most
popular
logging,
libraries
in.net,
both
satalog
and
analog,
build
upon
these
common
abstractions,
so
in
the
grpc
hosted
app
model,
you're
able
to
make
use
of
these
libraries
and,
in
addition
to
the
you
know
previously
mentioned
concerns,
we
also
have
things
like
health
checks
file
providers.
Caching,
for
all
these
things,
we
can
use
the
ecosystem
of
libraries
available.
A
A
But
let's
say
we
wanted
to
expand
the
scope
of
this
example,
and
we
also
wanted
to
create
a
web
dashboard
that
exposes
the
score
service
and
is
updated
in
real
time,
while
this
might
have
otherwise
been
difficult
to
achieve.
Since
we
use
the
same
hosted
app
model,
we
were
able
to
share
the
the
business
domain
logic
that
kept
track
of
a
player's
score
and
exposed
it
both
via
a
grpc
endpoint,
as
well
as
a
websocket
application.
B
B
B
B
What
signalr
is
is
essentially
using
web
sockets
behind
the
scenes
to
allow
the
server
to
give
you
updates
on
the
score
in
real
time.
So,
let's
get
started
with
playing,
so
I
will
play
as
jeff,
and
I
am
going
to
answer
the
question
and,
as
you
can
see,
as
soon
as
the
score
is
updated
on,
the
server
is
pushing
that
information
to
my
signalr
endpoint
in
real
time
and
let
go.
Let
me
go
ahead
and
finish
the
game.
B
B
As
you
can
see,
with
the
diagram
on
the
left,
we
are
seeing
roughly
the
same
server
rps
numbers
between
grpc.net,
which
is
displayed
in
dark,
blue
and
go
which
is
displayed
in
green
in
terms
of
client
performance.
Again,
we're
also
competitive
with
grpc.core
and
go
implementations,
though
the
results
will
vary
more
significantly,
depending
on
the
traffic
pattern.
You're
measuring
for
note
that
these
are
numbers
we
are
getting
with.
The
latest
preview
builds,
so
they
will
continue
to
change
as
we
work
on
performance
improvements.
B
B
B
But
there's
more
work
to
be
done
currently,
there's
an
ongoing
collaborative
effort
with
grpc
contributors
from
google
and
the
protobuf
team
to
reduce
buffer
copying
in
the
serialization
and
deserialization
logic.
Specifically,
we
want
to
reduce
the
amount
of
allocations
by
using
the
spam
primitive
that
was
introduced
two
years
ago
as
part
of
the.net
core
2.0
2.1.
B
In
a
nutshell,
we
are
converting
the
protobuf
logic
from
using
streams
to
use
buffer
writers
and
buffer
readers.
This
means
we
are
reducing,
string
allocations
and
memory
copies
on
the
heap
and
converting
the
logic
to
use
stack
allocated
memory
instead
as
a
result
of
reducing
the
overhead
due
to
garbage
collection,
we
expect
gains
in
both
server
and
client
performance
and
now
for
the
last,
but
probably
the
most
important
lesson
I'll
hand
it
back
to
saurop.
A
So
john,
I
and
all
the
folks
at
microsoft
have
been
collaborating
with
you
know:
multiple
contributors
since
about
november
2018
and
have
shipped
multiple
releases
of
jrpc.net
over
the
course
of
almost
two
years
of
working
together
there,
a
lot
of
folks
have
helped
us
realize
our
ambitions
of
making
your
pc
a
first
class
experience
in
dot
net.
I
have
a
special
shout
out
to
some
names
on
the
slide.
A
There
are
obviously
more
names
that
I
had
to
leave
off,
but
I
want
to
specifically
call
out
jan
and
alex,
who
helped
us
get
this
project
off
the
ground.
They
helped
expose
api
surface
in
the
existing
grpc.core
implementation
that
allowed
us
to
share
the
same
api
service
for
invoking
and
handling
rpcs
across
both
the
existing
and
the
new
implementation
that
was
being
built.
A
I
also
want
to
give
a
shout
out
to
carol
who
who's
perhaps
single-handedly
contributed.
The
ms
build
integration
for
code
generation,
which
is
you
know,
hugely
instrumental
in
making
jpc
feel
like
a
first-class
citizen,
none.net
and
like
john
also
just
spoke
to
the
google
protobuf
team,
is
helping
us
with
changes
in
code
generation
to
just
reduce
buffer
allocations.
A
A
A
The
second
lesson
we
learned
was
sharing.
Abstractions
makes
every
developer
more
productive
by
using
abstractions
that
were
already
popular
in
the
dotnet
ecosystem.
We
didn't
constrain
developers
into
using
our
notion
of
our
logger,
or
only
our
di
container
people
are
able
to
plug
and
play
different
libraries
from
the
ecosystem
and
really
use
what
works
best
for
them.
A
A
I
mean
all
I
can
say
is
john
and
I
are
extremely
grateful
to
have
had
the
opportunity
to
present
at
grpc
conf
as
a
representative
of
the.net
team,
we're
excited
to
enable
developers
you
know
and
when
they
consider
building
applications
with
grpc,
we
want.net
to
be
considered
a
first
class
and
a
high
performance
option
at
microsoft.
More
broadly
we're
excited
about
your
pc
and
we
have
a
few
teams
that
have
spoken
publicly
in
their
roadmaps
about
adopting
grpc
as
well.