►
From YouTube: gRPC June Meetup/ Ctx is key! -by Samuel Davidson
Description
#grpc
Ever wonder what that ctx context.Context object is? You’ve probably been copy-pasting it without issue, but you’re barely scratching the surface of this awesome little object. Come learn the simple yet powerful API of a ctx object which can easily improve the health of your RPC ecosystem!
Talk by Samuel Davidson, Software Engineer, Google
A
Okay,
well,
hello,
my
name's
samuel
davidson,
I'm
a
software
engineer
at
google.
I
work
on
google
kubernetes
engine
on
the
secure
on
one
of
the
security
teams.
Kubernetes
as
well
as
gke
is
a
big
go
micro
services
platform
and
we
use
a
ton
of
grpc
and
we
use
and
pretty
much
everything
everywhere
has
context
the
context
object
as
the
first
parameter
and
all
our
functions
and
as
an
engineer
on
the
all
these
microservices
for
years.
A
I've
just
been
kind
of-
I
don't
know
copy
pasting,
not
really
understanding
what
this
object
was
until
a
few
months
ago-
and
I
was
like
you
know-
I'm
gonna
make
a
little
talk
on
it.
I'm
gonna
figure
it
out,
give
a
little
talk
internally
to
my
team.
They
liked
it
a
lot
I
got
shared
around,
and
so
I
got
invited
to
give
this
talk.
So
that's
the
background.
It's
a
sort
of
internal
talk.
I've
taken
apart,
I
gave
it
a
gophercon
eu
a
couple
weeks
ago.
A
That
was
pleasant,
so
sandy
davidson
at
is
my
twitter
handle.
I
don't
check
that
twitter
very
much,
but
you
can
also
dm
me
on
linkedin
and
I'm
more
responsive.
There,
if
you
want
to
connect
or
chat
or
whatever
so
the
name
of
this
talk
is
context,
is
key.
The
context.context
object
that
everyone's
passing
around
so
performance
talk.
Three
parts
I'll
try
and
go
quick.
First
is
the
design
of
the
context
object,
the
actual
sort
of
philosophy
behind
it?
A
The
second
is
the
api
of
the
package
and
how
you
actually
use
it
in
go
code
and
third,
are
just
a
bunch
of
useful
usage
patterns,
certainly
not
exhaustive,
but
stuff.
You
might
recognize
or
find
interesting,
so
first
section
the
design
of
the
context
object
so
just
to
clarify,
if
you
don't
know
what
this
talk
is
about,
you're
already
lost
we're
talking
about
the
package
called
context.
A
That's
imported
as
such,
you
may
have
seen
ctx
abbreviated
as
a
variable,
or
you
may
have
seen
it
as
the
first
parameter
in
some
rpc
function.
That's
what
I'm
talking
about.
So
it's
a
very
common
package
used
in
all
the
biggest
it's
it's
ubiquitous
among,
go
it's
used
in
all
the
big
packages
and
go
with
15
of
all.
Go
files
import
it
here.
A
If
you
see
thirty,
four
percent
kubernetes
that
tv
terraform
very
common
and
it's
free,
especially
common
in
sort
of
the
front-
end
api-
that
sort
of
layer
that
you
talk
to
the
sort
of
public
layer
of
the
package
net
http
grpc
database
sql,
it's
very
common
as
sort
of
something
you
can
attach
to
requests
or
put
as
the
first
parameter.
But
if
you
were
like
me,
as
I
described
at
the
beginning,
I'd
be
hacking
away.
A
You
know
providing
immense
value
to
my
employer
and
I
come
across
some
some
query:
some
function
that
takes
context
as
the
first
parameter.
I
really
don't
know
what
it's
supposed
to
do
or
what
it
is,
but
hey.
Of
course,
it's
also
in
the
surrounding
function.
I'll
just
copy
paste
yeah
works.
Fine.
It
compiles
fine,
nothing,
no
one
yells
at
me,
and
this
is
kind
of
how
I
got
along
for
years,
essentially
or
maybe.
B
A
Case
I
called
context.background
and
just
get
a
new
one
in
some
tests
and
nothing
yells
at
me
and
just
hope.
But
what
is
this
object
right?
So
it's
it's
used
for
go
routines
and
rpcs
as
you've,
probably
seen
in
your
own
code
bases
it's
a
simple
state
container
of
three
things.
First,
is
the
cancellation
status
of
this
go
routine
rpc
the
timeout
associated
with
this
go
routine
rpc
and
any
sort
of
arbitrary
key
value
pairs
that
are
important
for
this
request
sort
of
at
a
meta
data
level.
A
A
You
can
store
in
a
separate
variable
that
when
you
call
it
takes
no
parameters,
when
you
call
this
function,
it
will
automatically
mark
whatever
context
it's
associated
with
as
cancelled,
and
that
may
seem
really
strange
and
not
making
sense
to
you,
but
we'll
explain
in
a
minute.
So,
as
I
said,
contacts
are
passed
around
rpcs,
so
I've
got
my
pc.
I
come
up
to
it,
you
know,
and
I
type
in
the
command
line,
my
app
query
database.
A
This
is
a
pretend
app
called
my
app
that
uses
grpc
and
contacts,
and
the
first
thing
my
pc
would
do
is
create
a
context
object
locally.
It
would
maybe
assign
whatever
timeout
I'm
willing
to
tolerate
by
default,
maybe
30
seconds.
It
would
attach
some
local
credentials
that
validate
me
as
sam
as
sam's
pc,
and
then
it
would
send
that
request
with
any
request
parameters
or
whatever,
with
the
query,
as
well
as
the
context
object
onto
the
network
stack.
So
maybe
it's
a
load
balancer
first,
that
gets
forwarded
to
a
front
end.
A
The
front
end
forwards,
just
the
context
to
an
auth
server
that
could
extract
out
the
credentials
and
validate
who
I
am
validate.
I
have
permissions
move
on
to
the
backend,
the
database
et
cetera,
and
the
value
of
the
context
being
passed
all
over
the
place
like
this
is
that
all
of
these
different
computers
and
subroutines
and
rpcs
all
know
that
they're
handling
really
one
request.
It's
not
a
whole
bunch
of
unrelated
requests.
It's
all
one
context
right.
A
A
A
Out
maybe
we
can
debug
that,
specifically
so,
taking
this
same
network
stack
in
a
more
simplified
view,
we
can
explore
all
the
different
parts
of
a
context
object
starting
with
the
timeout,
so
when
same
species
sets
a
30
second
timeout
for
the
whole
for
the
original
context
that
it's
pc.
All
of
these
context,
objects
in
all
of
the
rpcs
will
say
that
their
timeout
is
30
seconds,
because
that's
from
the
sort
of
root
context,
but
sub
requests
with
that
are
getting
with
a
context,
can
have
things
like
the
timeout
overwritten.
A
So
the
front
end
to
off
server
request
could
have
only
a
five
second
timeout
that
the
front
end
sets
to
it
and
then
maybe
five
seconds
expires
it
retries
and
we
can
try
a
few
times
at
the
off
server
within
our
30
second
window.
I
don't
know
something
like
that
right.
Similarly,
the
load
balancer
could
put
a
shorter
timeout
to
the
request
to
this
front
end,
and
if
that
10
seconds
expires,
this
context,
as
well
as
any
sub-request
based
off
that
context,
will
expire
they'll
be
marked
as
canceled.
A
These
computers
can
stop
working
and
then
maybe
the
load
balancer
could
retry
on
a
different
front
end,
and,
let's
just
say
another
20
seconds
passes
this
fails
again
and
again,
then
the
original
30
seconds
from
sam's
pc
will
expire.
All
child
requests
from
that
original
context
will
also
be
marked
as
cancelled,
and
they
can.
They
all
know
that
at
that
point
they
can
be
listening,
that
the
their
context
is
canceled
and
they
can
stop
working
free
of
resources
because
sam's
pc
has
now
reported
to
the
user.
A
Similarly,
you
could
maybe
build
out
a
trace
key
value,
so
the
key
is
trace
and
the
value
is
you
know,
whatever
computer,
this
context
went
through
or
whatever
machine.
This
context
is
visited.
So
let's
say
all
of
these
computers
sort
of
implement
the
same
library
that
will
overwrite
the
trace
value
with
you
know
their
current,
the
current
trace
value
and
their
own
pc
names.
The
load
balancer
adds
its
load,
balancer
seattle
and
then
the
front
end
could
add
the
front
end.
A
Machine
id
and
the
backend
could
add
its
own
backend
id
to
these
to
this
same
trace
key
value
pair
and
then,
if,
let's
say
an
error
occurs
in
the
database,
we
could
have
again
some
special
print
function
that
extracts
out
the
trace
key
value
pair
and
puts
it
as
part
of
maybe
a
log
statement
help
people
debug.
They
could
see
that
like
traces,
that
this
this
request
failed
as
part
of
this
stack
of
vms
or
something,
and
that
could
make
debugging
easier,
and
this
is
actually
how
tracing
is
implemented.
A
Another
interesting
thing
you
can
do
with
two
values
is
obviously
these
sub-requests
can
have
different,
unique
keys
and
values
added
to
them,
so
the
front-end
could
add
some
its
own
credentials
to
the
context
objects
sent
to
the
auth
server,
so
the
auth
server
can
trust.
You
know
I'm
talking
to
a
valid
front
end.
Maybe
the
back
end
is
locked
down,
so
only
trusted
back
ends
with
valid
credentials.
A
Can
query
the
database
because
we
don't
want
the
database
accessible
to
everybody
stuff
like
that
key
value
pair
is
super
flexible,
they're,
literally
like
any
type
any
type
key
and
value.
So
you
can
put
request
ids,
experiment,
ids
platform,
data,
timestamps
versions,
whatever
you
can
think
of,
and
you
might
be
thinking
they're
very
flexible,
which
they
are,
but
because
again
they're
just
any
type
any
type.
But
you
definitely
you
could
run
some
risks
by
just
putting
too
much
crap
in
there.
So
what?
B
A
Relevant
to
any
variety
of
requests,
start
playing,
username,
query
id,
I
don't
know,
put
an
image
in
there.
Put
the
bytes
of
an
image.
Put
page
numbers
query
times:
results
limits,
parameters
whatever
it's
a
bad
idea.
The
when
I
gave
this
talk
to
the
context
devs
a
while
back
to
have
them
sort
of
proofread
it
they.
A
They
wanted
me
to
add
a
slide
about
this,
because
I
think
people
misuse
the
key
value
pairs
a
lot
and
just
put
too
much
junk
in
there
and
you
shouldn't
use
the
context
as
an
arbitrary
key
value
store.
It's
really
just
be
for
like
metadata
that
spans
the
entire
request
across
any
number
of
rpcs
again
use
the
context,
values
for
only
request,
scope,
data
that
transits
processes
and
api
boundaries.
Why?
It's
a
bunch
of
reasons,
some
of
which
are
it's
just
messy?
You
lose
your
type
safety.
A
You
don't
actually
have
good
visibility
into
the
keys
and
values
within
a
context,
object
which
we'll
explore
later
and
most
importantly,
if
you're
a
rule
follower,
the
context
stops
say:
don't
do
it.
So.
The
last
thing
I
want
to
touch
on
in
this
section
is
the
cancel
function.
I
described
it
as
sort
of
this
magic
function.
You
get
with
a
context,
object
that
when
you
call
the
function
it
will
automatically
mark
it.
The
context
is
cancelled,
no
matter
what
the
timeout
is.
So
in
this
case,
when
sam's
pc
creates
its
context
object.
A
It
also
gets
a
cancel
function
represented
by
this
tnt
here
and
if
I
came
along-
and
I
was
like
wait-
I
don't
want
to
make
this
big
long
request.
I
hit
you
know,
control
c
sec
term.
My
pc
could
hypothetically
pick
up
on
that
call.
The
cancel
function
before
terminating,
which
would
automagically
over
the
wire
mark
all
of
these
contexts
as
canceled
and
just
propagate
to
all
subrequests
that
are
currently
going
on
using.
A
Derived
from
this
original
context-
and
this
is
useful
because
it
informs
it-
informs
all
those
pcs
that
I
don't
care
about
the
response
anymore,
you
can
free
up
resources,
stop
working
stuff
like
that.
You
could
do
something
like
this,
where
the
load
balancer
is
trying
to
be
really
snappy,
so
it
sends
a
whole
bunch
of
parallel.
Requests
to
a
whole
bunch
of
different
front
ends
returns
whichever
one
is
fastest.
First
right,
so,
let's
say
the
bottom
one
returns.
First,
it
could
cancel
the
upper
request.
A
You
could
cancel
all
of
their
siblings
and
just
return
to
the
user.
The
one
that
finished
first
and
then
all
of
those
other
front
ends,
can
clean
up
resources
and
stop
working
so
naturally
based
on
how
they
sort
of
branch
out
with
requests
the
context
objects
form
a
tree
where
you've
got.
You
know
my
pc
at
the.
A
A
Similarly,
if
you
were
to
get
a
cancel
function
for
a
sub
context
and
cancel
that
context,
only
itself
and
its
children
would
expire
or
be
marked
as
cancelled
and
that'll
make
more
sense
when
we
dig
into
the
implementation
in
a
moment,
the
importance
of
this
uni-directional
tree
is
that
you
can't
sort
of
request
down
the
tree
contacts
down
the
tree,
can't
attempt
to
make
changes
to
things
up
the
request
tree.
So
this
this,
maybe
some
requests
way
down
the
tree,
thinks
we
need
more
time.
Can
we
extend
the
timeout?
A
A
You
can't
like
tell
the
sibling
to
like
you
can't
tell
other
context
like
I
want
you
all
canceled.
You
have
to
be
the
parent
owning
the
cancel
function,
to
cancel
a
child
child
context,
so
design
wise.
That's
the
whole
design,
that's
sort
of
how
data
cancellation
status,
timeout,
keys,
values
all
propagate
across
an
rpc
ecosystem
to
downstream
rpcs.
A
So
normally
I
take
questions,
but
I'm
trying
to
hurry.
We'll
just
save
your
questions
for
the
end,
I'm
sure
some
of
you
are
very
confused,
but
I'm
going
to
move
on
to
the
api
and
how
you
actually
use
this
in
go
so
the
api
of
the
context
package.
The
api
of
the
context
package
is
actually
super
duper
simple.
So
when
you
pass
one
of
those
context
objects
as
your
first
parameter,
there
are
only
four
functions
you
can
do
on
that
context.
Object!
A
Well,
it's
an
interface,
there's
actually
a
bunch
of
implementations
behind
the
scenes,
but
it's
an
interface
and
it's
got
four
functions.
A
done
function,
which
is
a
channel
which
returns
a
struct.
What
that
will
do
is
either
hang
indefinitely
until
the
context
is
cancelled
or
it
will
be
closed
with
a
new
value.
A
Those
are
the
only
two
things
that
could
possibly
happen
with
this
function,
so
it'll
really
only
ever
return
nil
with
closed,
and
this
is
how
you
can
kind
of
indefinitely
wait
for
this
context
to
be
cancelled,
there's
an
error
that
will
either
return
nil.
If
this
context
is
not
cancelled,
it
will
return
context
cancelled
if
the
context
was
cancelled
via
a
cancel
function
or
it
will
return,
contact
stop
deadline
exceeded
if
the
context
is
cancelled
via
a
deadline.
Timeout
and
those
are
the
only
three
things
it
could
ever
return
deadline.
A
It
will
return
either
true
for
the
ok
with
a
deadline
or
it's
possible
for
contacts
just
to
not
have
a
deadline,
so
they
don't
time
out
on
their
own,
in
which
case
it
would
return
false
and
nil,
and
then
the
last
function
is
a
value
is
a
key
value
lookup,
where
you
can
pass
it.
The
key
that
you
want
to
look
up
and
it'll
either
return
the
value
of
an
untyped
interface
that
you
have
to
cast
or
it'll
return
nil,
and
that's
it.
A
It's
only
four
functions,
really
simple,
very
consistent
return
objects,
but
you
might
be
left
with
some
questions.
Based
on
what
I
told
you
in
the
last
section,
which
is
like
how
do
I
cancel
this?
I
thought
there
was
a
cancel
function.
How
do
I
shorten
the
deadline?
Like
you
showed
me,
I
could
or
add
values
modify
the
key
value
pairs.
I'll,
explain
that
in
a
moment,
but
the
important
thing
to
know
about
context,
which
explains
why
it's
so
simple
is
that
they're
all
actually
immutable?
A
A
The
way
you
modify
an
context
is
by
bundling
it
up
as
a
brand
new
context
and
wrapping
up
the
old
one
as
a
parent,
so
you
can
kind
of
think
about
every
context:
object
that
has
a
whole
bunch
of
stuff
going
on
inside.
It
is
actually
a
whole
bunch
of
context,
objects
all
duct
taped
together
with
changes
with
the
change
you
want
with
a
shorter
timeout.
You
take
a
context
with
a
longer
timeout
and
you
duct
tape
it
with
a
shorter
timeout
and
you
get
a
brand
new
context
object.
A
So
I
I
like
to
think
of
nested
boxes
where
the
innermost
box
is
the
oldest
and
the
outermost
box
is
the
latest
creation
of
context
of
a
context
object
so
we'll
go
into
explaining
that
a
little
bit
more.
So
this
we
have
our
context,
objects,
sort
of
discussed
at
the
beginning,
which
has
a
30
second
timeout
and
some
credentials.
A
We
can
imagine
this
is
a
small
present
and
we
can
bundle
it
up
with
a
shorter
timeout
to
create
a
new
context,
object
that
from
the
outside
appears
to
only
have
that
shorter,
timeout
and
those
same
credentials.
But
under
the
hood,
it's
the
old,
it's
the
the
credentials
are
inherited
from
the
parent,
but
the
shorter
timeout
is
sort
of
bundled
in
at
the
latest
at
the
latest
layer,
and
you
can
do
similarly,
you
can
do
the
exact
same
thing
with
keys
and
values.
A
You
take
you
bundle
it
up
with
a
new
key
and
value
called,
let's
just
say,
request
id
and
some
uuid,
then
this
new
context
object
will
inherit
the
timeout
and
the
credentials,
but
also
have
a
request
id
that
can
be
looked
up.
We
can
take
this
further.
We
can
bundle
this
with
a
new
key
value
pair
for
where
we
overwrite
the
credentials
key
with
a
new
value.
A
So
this
output
context
will
appear
to
have
a
different
credential
as
well
as
inherit,
the
request
id
and
the
timeout,
but
again
under
the
hood,
the
old
credential
still
exists.
It
just
can't
be
looked
up
anymore
because
it's
been
overwritten
and
these
are
all
still
just
pointing
to
their
parents,
and
this
sort
of
parent
referencing
again
forces
this
tree.
Behavior
every
context
is
built
off
its
parent
and
it
can't
modify
its
parent
and
therefore
you
can't
you
can't
like
do
that
sort
of
backwards.
A
A
A
These
are
how
we
make
and
change
our
contexts.
You
can
see
all
four
of
them
take
parents,
all
four
of
them:
output,
brand
new
contacts
and
two
of
them
take
timeouts.
One
of
them
takes
new
key
value
pairs
and
three
of
them
return
cancel
functions
that
you
can
optionally
call
to
mark.
This
new
context
is
canceled
whenever
you
want
so
for
any
given
subrequest.
A
If
you
wanted
a
cancel
function
so
that
you
can
cancel
it
on
demand,
if
you
call
with
cancel,
if
you
wanted
to
add
some
time
constraints
shorten
the
timeout,
you
call
either
with
deadline
or
timeout
or
if
you
want
to
attach
some
new
key
value
pairs,
a
new
identity,
a
new
sort
of
request
id
or
something
you
call
with
value,
and
that's
how
you
can
build
out
these
sort
of
nested
boxes
create
a
context.
Object
contains
whatever
you
want
and
they're
just
you
just
keep
chaining
these
together.
A
So
the
last
thing
about
the
package
I
want
to
talk
about
is
background
and
to
do
there's
a
probably
realize
the
chicken
and
egg
of
these
four
functions,
which
is
they
all
require
a
parent.
So
what?
If
you
don't
have
a
parent
or
if
you're,
not
past,
one
or
you're,
creating
a
request
totally
from
scratch?
Sort
of
the
origin
of
all
contexts
are
background
and
to
do
if
you
don't
have
a
context,
object.
You
use
one
of
those
two.
So
if
you
look
at
that
api
one
last
time,
you've
got
our
package
context.
A
Those
four
functions,
our
context,
interface
and
there's.
The
two
final
functions
are
background
and
to
do,
and
you
can
see
that
they
both
just
return
a
context,
no
error.
No
no
questions
asked
they
return
a
non-nil
empty
context.
It
is
never
cancelled,
has
no
values
and
has
no
deadline.
So
this
is
just
a
reliable
context.
That's
just
ready
to
go.
It's
never
gonna
be
marked
as
cancelled.
You
can
build
off
it.
However,
you
want-
and
this
is
the
100
complete
context
package.
At
least
of
making
this
talk,
this
is
the
entire
package.
A
These
are
all
the
functions
and
everything
they
do
so
real,
quick.
What's
the
difference
between
background
to
do
they
both
return
in
non-null
empty
context?
They
seem
to
be
pretty
identical
and
they
basically
are
background.
You
want
to
use
it
by
the
main
function,
initialization
and
tests,
it's
the
top
level
context
for
incoming
requests.
So,
basically,
when
you
need
to
create
a
brand
new
request
from
scratch,
use
background
to
do
is
when
it's
either
unclear.
A
You're,
confused
or
a
context
is
not
yet
available,
like
the
surrounding
infrastructure
is
supposed
to
pass
you
a
context,
but
it's
maybe
not
ready.
Yet
I
don't
know
it's
just
it's
just
to
imply
to
developers
reading
your
code
that
eventually
will
replace
this
with
a
real
context
object.
But
for
now
it's
we're
using
a
blank
one
functionally
though
they're
nearly
identical.
I
thought
I'd
point
out
the
actual
functional
changes,
differences
between
the
two.
If
you
look
at
the
context
go
code,
they
are
both
created
in
the
exact
same
way.
A
A
Difference
so
it'll
just
print
slightly
in
your
logs,
okay.
That
was
the
end
of
that
section.
We're
going
to
move
on
to
the
last
section,
which
is
just
a
bunch
of
uses
patterns.
Hopefully
some
stuff
you
recognize.
Hopefully
some
inspires
you
to
use
them
in
interesting
ways
in
your
own
code
or
during
your
own
microservices
usage
patterns.
So
we're
going
to
start
with
the
cancel
function,
which
is
you
should
always
defer
a
returned
cancel
function.
If
you
read.
B
A
The
comments
for
the
weight
for
like
with
cancel
it
always
tells
you
to
defer
a
return,
cancel
function,
and
why
is
that?
So,
let's
say
in
this:
in
this
request,
we
are
going
to
make
a
sub
request,
we're
going
to
add
a
30
second
timeout.
This
function
returns
a
cancel
function
and
what
you
should
always
do
is
called
defer,
cancel
at
the
end
right
after
you
get
this
cancel
function,
and
why
is
that?
Well,
what?
If
request
errors
out
for
something
unrelated?
A
We
spin
off
a
bunch
of
sub
requests
using
this
30
second
timeout,
and
then
we
have
to
exit
early
because
of
some
error
or
some
nil
check.
Whatever
deferring
cancel
ensures
that
we
at
least
inform
all
those
subrequests
that
we
don't
care
about
their
sub
requests
anymore.
Are
you
know
your
parent
has
messed
up
your
parrot?
Your
parent
has
exited
early.
Please
stop
working.
We
don't
care
about
your
requests,
so
it's
just
it's
just
for
like
clean
code,
keeping
things
simple.
A
Just
in
case
again,
if
subrequest
is
relevant
after
this
function
returns,
it's
good
to
call,
cancel
and
clean
up
resources
if
we're
going
to
exit
early
okay,
so
that's
that's
one
pro
tip
another
one
is
getting
the
deadline
again,
you
can
just
call
dot
deadline
on
a
context,
object
to
get
the
timeout
or
the
deadline.
If,
okay,
it's
true,
then
it's.
If
we
have
a
defined
deadline,
we
can
do
math
with
it.
You
know
we
can
count
how
many
milliseconds
until
we
the
deadline,
expires.
A
Similarly,
we
can
shorten
the
deadline
by
getting
that
deadline
in
the
same
way,
but
doing
some
math
subtracting
some
arbitrary
amount
of
time,
in
this
case
200
milliseconds,
creating
a
subcontext
with
that
shorter
timeout
and,
of
course,
calling
defer,
cancel
with
the
return
cancel
function,
and
then
we
can
make
sub-requests
using
this
shortened
deadline.
I've
seen
this
pattern
a
bunch
in
some
google
code.
It's
it's
a
nice
little
pattern
where
you
can
ensure
that
you
have
at
least
a
little
bit
of
time
at
the
end.
A
Even
if
these
requests
all
time
out,
you
have
a
little
bit
of
time
at
the
end
to
clean
up
some
database,
something
or
yadda
yadda
you
can.
You
can
do
some
cleanup
code
free
of
resources,
whatever
you
gotta
do
values
setting
and
getting
so
you
can
call
context.with
value,
you
pass
it
a
key
such
as
this
magic
string,
request
id
and
you
could
pass
it
some
new
uuid
whatever
and
later
on.
You
could
look
it
up
with
context.value
passing
that
same
key,
pretty.
A
You
know
you
can
print,
but
we
completed
the
request
for
this
id
and
the
values
are
just
passed
around
sort
of
automatically
stored
within
the
context
object.
You
can
see
here
that
there's
a
duplicate
magic,
key
string
that
I
wrote
up
called
request
id.
What
you
frequently
will
want
to
do
is
put
these
keys
and
consts
some
sort
of
sort
of
type
safe
hard
to
typo
key
name.
So
in
this
case
I
have
an
id
key
const
and
I
reuse
that
for
the
same
function,
so
it's
moved
to
a
common,
constant
or
used.
A
Here's
a
toy
example
of
how
an
authorization
check
might
occur
so,
let's
say
we're
an
authorization
engine
or
we're
like
a
sort
of
im
server,
and
we
are
passed
to
context
and
we're
told,
is
this
person
authorized?
Or
can
you
tell
me
if
this
is
if
this
person
is
authorized?
So
the
first
thing
we
do
is
default
it
to
false,
and
then
we
want
to
extract
out
the
credentials
using
whatever
credentials,
sort
of
keys
and
values.
They
have
and
there's
a
lot
of
pseudo
code
here,
but
we
would
pull
out
the
credentials
value.
A
We
would
parse
that
it's
like
a
valid
object,
but
it's
not
nil.
If
all
that's
true,
we
could
call
is
aloud
which
could
maybe
do
some
apple
check
against
a
loud
database
or
a
loud
file.
Who
knows
right
again
a
toy
example
and
if
all
of
these
checks
pass,
we
would
set
aloud
to
true,
and
then
we
could
return
that
to
the
user
or,
if
not,
return,
a
permission
denied
error.
This
is
sort
of,
obviously
in
in
real
production
systems,
a
lot
more
complicated
and
robust
than
this.
A
But
this
is
a
toy
example
of
how
you
would
extract
out
credentials
from
requests
from
context,
objects
and
use
them
in
apples,
use
them
to
authorize.
So
building
off
that
we
can
take
a
common
package.
We
can
build
a
common
package
using
these
two
concepts
from
the
last
two
slides,
which
is,
we
can
create
a
package
called
an
auth
library.
C
A
So
the
last
thing
I
want
to
talk
about
is
just
the
done
function.
The
way
you
might
reasonably
listen
to
the
done
function,
since
it's
just
a
channel
that
hangs
until
the
the
context
is
finished.
Is
you
make
another
channel
for
like
marking
your
own
work?
Is
done?
You
spin
off
your
own
work
in
its
own
gun,
go
function
which
pushes
a
value
to
work
done,
and
then
you
can
use
those
fancy.
A
Golang
select
statements
to
pull
from
both
your
own
work
channel,
which
says,
like
I
finished,
all
the
work
I
needed
to
do
or
the
context.done
channel,
which
says
this
rpc
is
canceled.
We
don't
care
anymore
and
whichever
one
of
those
finishes,
first
you'll
return
that
error,
which
could
be
nil
sort
of
marking.
This
request
is
completed,
so
basically
it's
doing
two
things
in
parallel:
it's
doing
the
work
of
this
rpc.
It's
also
listening
and
waiting
for
this
context
to
be
cancelled.
A
Whichever
of
the
two
finishes
first,
so
this
is
a
common
pattern
that
I've
seen
in
a
bunch
of
libraries,
so
there's
also
packages
that
help
with
this,
such
as
error
group,
which
a
lot
of
a
lot
of
these
helper
packages
have
native
support
for
context
objects.
So
error
group
has
a
with
context
like
creator
or
instantiator,
which
will
give
you
a
new
error
group
that
automatically
listens
to
the
done
function,
and
then
you
can
just
use
this
error
group
to
go
spin
off
sub
sub
requests
and
call
the
blocking
function,
weight.
A
C
A
Everything
works
happily
or
an
error
if
the
context
expired
or
something
went
wrong
in
your
own
work
code.
So
if
you
were
to
pull
from
the
talk,
context.done
you'd
see
that
the
channel's
not
closed
and
we
can
print
the
line
questions.
So
that's
the
talk
kind
of
long.
I
was
about
30
minutes
or
28
minutes.
So
I
appreciate
your
patience
listening
in
and
let
me
just
speak
up.
If
you
have
questions,
there's
an
appendix,
I
guess
you
can
screenshot
this
all
these
aren't
you
can
just
google
all
of
these.
A
But
I
hope
you
all
enjoyed
it.
I
hope
you
at
least
learned
something.
I'm
by
no
means
a
super
duper
expert.
I
don't
work
on
context,
I'm
just
a
random
engineer
who
works
in
go?
Who
thought
this
was
an
interesting
topic
to
turn
into
slides,
so
there
there
might
be
questions.
I
don't
have
the
answer
to
there.
Certainly.
A
C
Thank
you
so
much.
This
is
like
totally
good
and
the
way
you
opened
it
up.
Actually,
I
am
still
like
that,
like
30
minutes
before
I
was
using
just
contact
stuck
to
do
for
everywhere,
wherever
the
contacts
was
expected
yeah.
This
is
good.
This
is
like
kind
of
an
eye-opener
and
I'm
one
of
the
developer,
who
don't
read
the
entire
code
on
the
go
package,
the
description
so
one
question,
there
are
a
couple
of
questions.
The
one
question
is
like
so
when
we
say
done
on
the
child
process.
C
A
Context:
objects
when
you
say
when
we
call
done,
I
don't
calling
done
is
just
listening
for
a
done
status
right,
even
even
if
your
request,
if
your
request
finishes
successfully,
it
won't
automatically
mark
its
context
as
done
its
context
still
can
live
on.
Even
though
it's
free
resources
get
read
on
the
original
background
context
will
never
ever
be
cancelled
like
a
background
or
to
do
context
again
will
never
be
canceled.
There's
no
way
to
cancel
it
functionally
you
don't
ever
have
access
to
sort
of
a.
A
I
don't
know
it's
just
like
a
cancel
function
for
it
or
a
timeout
for
it
it's
intentionally
uncancelable.
So
the
worst
case
is
that
your
is
that
your
context
will
be
canceled
all
the
way
up
right
up
next
to
the
background
or
to
do,
but
when
a
I
think
the
idea
is
like.
If
your
function
finishes
successfully
it
doesn't
you
don't
have
to
like
mark.
That's
that's.
What
sort
of
deferring
cancel
is
about,
so
you
can
at
least
tell
your
subrequests
that
we're
done
working,
but
it
doesn't.
B
C
A
C
A
B
A
C
Well,
sam
does
that
I
just
wanted
to
let
everyone
know
that
I've
launched
two
polls
and
your
feedback
is
extremely
helpful
to
us
as
we
go
forward
with
the
meetups
every
month.
So
if
you
could
just
take
a
couple
of
seconds
to
answer
the
polls,
if
you
do
not
see
them,
please
just
drop
the
message
in
the
chat,
but
everyone
should
have
seen
the
polls
pop
up
in
their
window
thanks
sam.
A
Yeah,
when
I
do
share
this,
there
are
a
ton
of
this
slide.
This
stop
talk
is
more
like
45
minutes
long
originally,
and
I
cut
out
a
lot
of
like
clarifying
statements
like
you'd
see
this
slide,
where
I
clarify
that
the
tree
is
actually
based
off
of
a
background
context
and
stuff
like
that,
but
feel
free
to
ask
this.
Is
this
with
the
slide?
You
wanted
to
ask
your
question.
C
Yeah
yeah,
so,
for
example,
when
front-end
one
gets
the
work
done
fast
and
front
end.
Two
is
also
a
kind
of
requested
parallelly
by
the
load
balancer,
for
example,
and
when
we
mark
done
to
the
channel
when
we
select
done
to
this
the
chat,
the
channel
that
is
listening.
So
it
automatically
makes
the
front
end
two
to
cancel
its
process
or.
A
That
is
totally
up
to
the
load,
balancers
implementation,
so
the
load
balancer
will
be
informed.
That
front
end
finished
right
because
it's
requested
to
the
front
end
return
successfully
and
then
the
load
balancer
can
be
like.
Okay
in
your
in
what
you're
saying
the
load,
balancer
sent
out
two
requests
in
parallel,
it's
up
to
the
load
balancer
to
be
like.
Am
I
still
waiting
on
the
second
request,
and
then
they
can.
They
can
either
cancel
that
they
can
manually
call
the
cancel
function
on
that
context.
A
A
A
C
A
B
A
That's
a
I.
I
had
this
question
in
at
gophercon
and
it's
I
don't
actually
know
because
people
were
like
well.
This
seems
very
go
pendant,
but
what
if
our
stack,
has
all
different
different
languages?
Right,
yeah-
and
I
don't
know
honestly
like
okay,
I
think
grpc
one
of
the
pleasantries
of
grpc-
is
it
will
kind
of
automatically
like
it'll.
Do.
A
A
C
A
A
A
A
You
can
see
how
it
kind
of
like
unwraps
context
to
try
and
resolve
values,
and
this
is
part
of
the
reason
why
you
can
have
multiple
key
value
pairs
with
the
same
key
context
object,
but
only
one
is
resolved
and
why
you
can't
just
learning
all
of
the
key
value
pairs
within
a
context
object.
It's
kind
of
interesting,
so.
C
A
Oh,
I'm
still
in
mine,
I'm
still
looking
at
my
corporate
one,
so
I'll
I'll
send
you
a
link
with.
I
should
be
able
to
just
share
it
in
a
normal
google
docs
way.
If
I
stop
presenting,
I
can
get
you
over
here
I'll
just
do
that
now.
Actually
let
me
get
you
all
the
link
and
you
can
put
it
in
the
meeting
notes
and.
A
Yeah
no
more
questions,
then
I'll.
Just
get
these
to
I'll,
get
the
slides
to
almost
quickly
we'll
you
can
review
them
if
you
want
use
them
as
your
own
little
note
takers,
but
I
recommend
you
go
read
through
the
package
because
the
way
I
wrote
the
stock
is,
I
just
it's
actually
a
well
very
short,
well-written
package
with
a
lot
of
interesting
blog
posts
about
it.
B
B
A
B
I
mean
that
that
statement
is
true.
I
wasn't
sure
what
the
actual
question
was,
though
I
I'm
just
curious,
so
I
I
assume
there's
a
way
to
get
a
context
from
a
stream
and
then
I'm
curious,
for
example,
is
it
stopping
the
next
item
coming
from
the
stream?
If
you
cancel
or
is
it
cancelling
the
entire
thing
and
if
there's
a
place,
I
can
just
go.
Read
the
exact
semantics
for
how
these
apply
to
streams.
That's
great
yeah.
B
If
you
look
up
the
godoc
for
geropsico,
you
should
be
able
to
find
some
documentation
in.
You
probably
want
to
look
at
the
server
stream
interface
there's
a
function
that
will
return
the
context
for
whatever
reason
the
actual
service
handlers
don't
receive
the
context
as
an
argument.
They
they
receive
a
stream
object,
and
then
you
call
the
context
function
on
that
to
get
the
context,
but
in
any
case,
that's
the
context
that
would
include
the
headers,
for
instance,
and
then
on
the
client
side.
B
Obviously,
that's
where
you
set
the
context
and
then,
if
you,
if
you
cancel
the
context
that
you
use
when
you
create
the
stream,
then
that
would
cancel
the
whole
stream
in
terms
of
like
messages
that
were
queued.
I'm
not
completely
sure.
Actually,
whether
cancellation
would
clear
out
all
the
buffers
and
tell
the
server
like
hey
your
stream
was
canceled
immediately
or
if
you
would
have
to
actually
drain
the
buffer
of
already
received,
but
not
processed
messages,
but
yeah
I
mean
that's
sort
of
just
an
inherent
race.