►
From YouTube: Building Distributed Applications with .NET and Dapr
Description
Building distributed applications is not an easy thing to do. Even though there are some inherent benefits, breaking down your application into a collection of smaller services comes with a completely different set of challenges. This is where Dapr can help us out. It provides a runtime and a collection of building blocks that can be used with any language, in any cloud or on-prem environment. In this session, we’ll dive into Dapr, discuss the various building blocks it supports, and see some demos of how you can make use of it in your .NET applications.
This session is run by the San Antonio Cloud Computing user group (https://www.meetup.com/cloud-computing-san-antonio/) that hosts meetups in San Antonio, TX.
C
A
C
C
You
know
me
and
my
team,
we
really
focus
on
you,
know,
developer
education,
developer
relations,
and
you
know
just
making
sure
that
everyone
has
a
really
good
experience
like
building
and
using
our
tools,
and
you
know
just
really
trying
to
achieve
whatever
they
are
trying
to
achieve
with
the
application
that
they're
trying
to
build
now.
What
I
want
to
talk
to
everyone
about
today
is
a
technology
that
I've
been
working
on
and
working
with
for
the
past,
probably
about
the
past
year,
or
so.
C
It's
called
adapter
right
and
dapper
really
makes
it
easy
or
easier
to
start
building
distributed
systems
to
have
applications,
cloud
native
applications,
microservice
applications,
whatever
term
or
technology,
that
you
kind
of
want
to
slide
into
that
slot.
I
think
dapper
makes
it
really
easy
or
much
easier
for
you
to
do
it,
and
what
I
want
to
do
is
show
you
how
exactly
that
happens
now.
I
know
for
me
again:
this
is
a
user
group
session.
This
is
not
a
conference
or
build
or
anything
like
that.
You
know
I
want
everyone
to
feel
comfortable.
C
I
want
everyone
to
feel
free
to
go
ahead
and
ask
questions.
I
know
the
folks
are
going
to
be
monitoring
and
asking
questions
and
stuff
like
monitoring
the
questions
and
things
of
that
nature.
Yeah
I'll
be
peeking
into
the
chat
too
a
little
bit.
I
see
some
folks,
oh
wow.
We
got
some
folks
here
from
miami.
That's
awesome,
my
buddy
jose
is
here
from
brazil,
I'm
from
antigua
if
anyone's
wondering
where
I'm
from
you
know.
C
I
live
in
florida,
but
you
know
originally
I'm
a
caribbean
boy,
so
you
know
shout
out
to
anybody.
That's
here
from
the
caribbean,
but
with
that
being
said,
how
about
we
just
go
ahead
and
get
into
it
right
and
again,
like
I
said
before,
feel
free
to
go
ahead
and
just
pop
in
questions.
As
things
happen
right,
we
don't
have
to
wait
to
the
end
or
or
anything
like
that.
C
C
And
I'm
you
know,
I'm
assuming
that
most
of
you
folks
are
developers
or
you
work
with
developers,
or
you
have
developers
on
your
team
and
things
of
that
nature
and
when
we
think
about
building
applications
today
and
particularly
applications
that
need
to
scale
like
there's
a
lot
of
problems
that
developers
need
to
kind
of
figure
out
right,
like
there's
things
that
they
have
to
sort
out
as
they're
trying
to
be
successful
in
these
apps.
And
you
know
that,
for
instance,
is
things
like
you
know?
C
What
type
of
infrastructure
am
I
going
to
use
to
build
my
application?
What
kind
of
programming
languages
I'm
going
to
need
to
use
you
know?
Sometimes
I
may
need
to
use
multiple
programming
languages,
because
you
know
one
language
might
be
stronger
in
doing
something
else
than
the
other
one
right
and
then,
as
I'm
trying
to
take
my
monolithic
application
right,
like
my
big
app,
that
kind
of
has
everything
kind
of
bundled
in
together.
C
C
So
again,
like
imagine,
we
have
like
some
type
of
online
store
or
something
of
that
nature,
and
I
know
it's
christmas
or
it's
black
friday
or
it's
some
special
holiday
in
whatever
country
that
you're
in
and
you're
like.
Okay,
I
need
to
you
know
scale
up
like
the
inventory
service.
Like
the
thing
that's
like
serving
in
the
product
data,
or
I
need
to
scale
up
like
the
payment
processing
thing,
the
thing
that's
taking
money
and
charging
folks,
you
know
charging
your
credit
card
or
your
bank
account.
C
C
You
know
what
I
mean,
so
that's
where
microservices
kind
of
help
out
where,
like
I
could
just
scale
the
little
thing
like
the
little
piece
of
of
my
app
or
the
service
in
my
code,
that's
really
doing
the
work
and
really
needs
like
more
resources
and
the
other
parts
of
it.
I
can
kind
of
just
leave
it
alone
right
and
then
now
we
can
start
to
more
intelligently,
make
use
of
our
resources,
our
servers,
our
vms
and
things
of
that
nature,
a
little
bit
better.
C
So
I
mean
that
sounds
like
okay.
Well,
that's
not
so
hard
to
do,
but
it
actually
turns
out
like
there's
a
lot
of
challenges
when
it
comes
to
building
like
these
microservices
these
these
distributed.
You
know
cloud
native
applications
and
a
couple
of
those
reasons
really
have
to
do
with
the
fact
that
you
know
when
you
kind
of
look
across
the
landscape
today,
like
there's
just
so
much
choice
for
things
that
you
might
want
to
do
within
your
app.
C
So,
for
instance,
some
of
the
things
we
might
want
to
do
is
like
distributed
tracing
right
like
now.
If
I,
if
I
don't,
have
one
huge
app
and
I
have
a
bunch
of
smaller
apps,
how
can
I
figure
out
like
what's
the
path
the
code
is
taking
throughout
these
different?
You
know
these
different
services
right.
I
need
to
be
able
to
trace
that,
or
let's
say
I
want
to
do
something
like
messaging.
I
want
to
do
pub
sub
or
I
might
need
to
do
service
discovery
right,
like
service
discovery
being
hey.
C
I
have
all
these
services
that
compose
together
to
make
my
solution.
How
do
I
know
where
they
are?
How
do
I
know
how
many
they
are?
How
do
I
know
if
they're
healthy
right,
like
how
do
I
know
I
should
you
know,
use
this
one
versus
the
other
one
and
then
again,
as
we
think
about
like
you
know
how
microservices
are
somewhat
dynamic
right
like
I
can
have
two
instances
of
a
thing
or
one
instance
of
a
thing
or
100
instances
of
a
single
service
like
how
do
I
know
what
the
address
is?
C
How
do
I
know
how
to
get
there?
How
do
I
know
whether
it's
again,
it's
upwards
down
or
whatever
the
case
is-
and
you
know
in
addition
to
that
like
when
we
kind
of
look
across
the
ecosystem,
there's
so
many
options
for
things
that
we
could
use
to
kind
of
plug
into
that
space.
So
again,
like
let's
say
I
want
to
do
messaging.
Well,
there's
rabbitmq,
there's
activemq!
C
I
could
use
a
hosted
service
in
the
cloud
like
azure,
service,
bus
or
sqs.
You
know,
or
you
know
what,
if
I
want
to
do
like
something
like
like
tracing
like
I
mentioned
before,
right
or
what?
If
I
wanted
to
do
state
management,
you
know
what
kind
of
database
do
I
want
to
use
what
kind
of
caching
service
do
I
want
to
use
right,
and
so
now
for
all
of
us
as
developers,
we
have
to
try
and
figure
out.
C
What's
the
right
combination
of
these
things
that
make
sense
right
at
least
make
sense
for,
like
the
feature
set
and
the
thing
that
we're
trying
to
build,
and
then
not
only
that,
but
we
have
to
think
about
well
what
are
the
programming
languages
that
it
supports?
So,
for
instance,
one
service
might,
you
know,
have
better
python
support.
C
Again
it
becomes.
It
becomes
a
little
bit
hard.
It
becomes
a
little
bit
distracting
because
now,
instead
of
you
really
just
focusing
on
writing
code
and
solving
business
problems,
now
you're
trying
to
like
you
know,
figure
out
the
infrastructure
right
like
now
you're
trying
to
figure
out
like
how
do
I
plug
these
things
together.
Just
so,
I
can
get
my
job
done
and
again
it
really
starts
to
take
up
some
time
and
again.
Here's
another
example
like
of
how
application
might
be
decomposed
right.
C
What's
going
on
so
you
know
long
story
short,
this
is
kind
of
where
dapper
comes
into
play
right.
What
dapper
is
is
a
pretty
much
an
open
platform,
a
runtime
that
will
allow
you
to
build
microservices
a
little
bit
easier
by
using
some
common
extractions
that
the
team
decided.
Well.
You
know
these
are
the
most
common
patterns
and
practices
that
people
that
are
building
cloud
native,
microservice
applications
or
user,
and
so,
let's
create
this
abstraction.
A
Yeah,
I
was
going
to
say
you
know,
I've
always
heard
software
development
or
computer
science
in
terms
of
the
human
side
of
it,
and
what
we're
really
trying
to
do
is
manage
complexity,
and
I
like
that,
that
you
mentioned
that
it
seems
like
dapper,
is
a
relatively
straightforward
manner
to
manage
a
lot
of
those
complexities
and
that
it
kind
of
gives
you.
I
don't.
C
For
sure-
and
you
know
a
common
example
I
like
to
use
when
I
talk
to
folks-
is
so-
let's
say
hey,
I
want
to
do
like
a
messaging
thing
right,
like
let's
say
I
want
to
use
like
some
cloud
hosted
messaging
service
right
now.
Most
of
these
things
don't
have
like
a
local
development
instance.
So
now
it's
like.
Oh
my
gosh,
like
I
gotta,
connect
to
the
cloud,
and
I
gotta
do
this
off
handshake
and
I
gotta
figure
that
out-
or
you
might
say,
okay
well
we're
still
in
the
early
stages
of
building
our
app.
C
I
don't
know
where
we're
gonna
be
storing
our
information,
like
I
don't
know
what
I'm
going
to
be
using
for
caching,
I
don't
know
what
I'm
going
to
be
using
for
some
of
these
other
components,
but
now
I'm
going
to
have
to
start
bringing
some
of
these
these
libraries
these
frameworks,
these
sdks
node
packages,
java
jars.
You
know
net
nuget
packages
into
my
app
and
then,
if
I
decide
hey,
I
don't
want
to
use
this
anymore.
Then
I
gotta
uninstall
and
I
gotta
like
retrofit.
C
My
app
right,
like
I
gotta
you,
know,
create
another
abstraction
or
another
thing
to
be
able
to
handle
that,
and
you
know,
would
it
be
great
if
we
didn't
have
to
do
that
right?
Wouldn't
it
be
great
if
you
could
just
focus
on
hey?
I
just
want
to
build
my
app
and
let
someone
else
deal
with
it.
You
know
what
I
mean
and
that's
kind
of
what
dapper
does
right.
C
You
can
make
use
of
some
of
these
common
patterns
and
practices,
and
you
can
use
any
programming
language
that
you
want
like
it
doesn't
matter
right,
so
you
know
a
lot
of
times
you
might
be
in
an
environment
where
you
know
your.
You
know
your
system
or
you
know
the
things
that
you're
working
on
are
built
up
from
multiple
languages.
Right,
like
I
used
to,
I
used
to
work
at
a
stock
trading
company.
C
You
know
prior
to
my
current
job,
and
you
know
in
that
company
I
would
say,
like
that:
company
was
a
collection
of
other
smaller
companies
that
were,
you
know
that
were
acquired
and
each
each
of
those
smaller
companies
had
a
different
programming
language
right.
So
I
was
working
with
folks
that
did
ruby
things
and
php
things
and
python
things,
but
we're
all
building
like
the
same
stock
trading.
C
C
Okay,
well,
not
that
people
go
here
and
ruby
people
go
to
the
other
side,
it's
the
same
application,
so
we
have
to
figure
out
a
way
in
the
middle
to
kind
of
have
them
talk
to
each
other
right
and
we
had
to
write
a
lot
of
code,
and
you
know
a
lot
of
you
know
serialization
code
and
messaging
code
and
things
of
that
nature
to
kind
of
make
that
work
we
didn't
have
dapper
at
the
time.
That
would
have
been
great
if
we
had
that,
but
you
know
these
are
these.
C
Are
these
are
real
problems
that
people
have
to
do
right
and
you
have
to
spend
you
know
sprints,
sprint
time
and
and
developer
cycles
to
kind
of
figure
those
things
out
so
again.
So
this
is
one
of
the
good
things.
I
think
that
dapper
gives
us
right.
You
know
we
can
use
any
language
that
we
want
to
use
any
language
that
you
know
speaks
http
or
grpc,
it's
cloud
agnostic.
C
So
this
is
not
like
an
azure
thing
like
it
doesn't
only
run
in
the
cloud.
It
doesn't
only
run
on
kubernetes.
You
know
you
can
run
it
on
your
machine.
You
can
run
it
local
host.
If
you
want
to,
you,
can
run
it
on
your
internal
data
center.
If
you
want
to
or
you
can
run
in
the
cloud,
if
you
want
to
right,
it's
completely
up
to
you,
and
on
top
of
that,
like
it's
open
source,
it's
free,
it's
pluggable!
So
you
know
one
of
the
things
you'll
see
as
we
go
forward.
C
A
little
bit
is
like
you
know,
the
implementation
and
the
and
the
abstractions
that
are
created.
A
lot
of
them
were
submitted
by
folks
in
the
community
that
they
were
like.
Oh
wow.
This
is
really
cool.
Like
I'm,
going
to
submit
a
pr,
and
I'm
going
to
add
my
component,
I'm
going
to
add
my
messaging
thing,
I'm
going
to
add
my
my
dns
thing
or
whatever
the
case
is
to
make
it
easier
for
me
to
use,
and
now
by
you
know,
by
proxy,
like
everyone
else
will
be
able
to
use
it
too.
C
So
I
did
mention
I
mentioned
a
few
times
about
like
these
building
blocks.
So
let's
talk
about
what
exactly
these
building
blocks
are
right
like
what
are
these
patterns
that
dapper
kind
of
gives
us
and,
like
I
said
before,
what
happened
was
the
team
kind
of
did
a
survey
like
they
looked
around
in
the
community?
They
spoke
to
customers
and
different
folks
and
they
were
like
okay.
Well,
how
are
you
building
your
app
city
like
what
are
the
things
that
you
really
care
about,
and
so
this
is
these?
C
Are
the
collections
of
building
blocks
that
the
team
was
able
to
come
up
with?
So
again,
you
can
see
here.
On
the
left
side,
we
have
service
to
service
invocation,
which
is
like
service
discovery.
You
know
state
management,
which
is
you
know
it's
like
a
key
value
store
like
I'm,
going
to
store
and
retrieve
stuff,
we
can
do
pub
sub.
You
know
we
have
triggers
if
you're
into
that
events
driven
type
programming
model
where
you
can
have
input
output
bindings,
then
there's
actors,
observability
secrets
and
then
obviously,
like
I
mentioned
before
it's
extensible.
C
So
not
only
can
you
have
your
own
implementation
for
each
building
block
you
could
you
know,
suggest
or
propose
your
your
own
building
block
as
well?
We
could
you
know
we
could
take
that
into
the
core.
We
can
start
building
around
that
now,
one
of
the
cool
things
that
you'll
see
also
about
these
building
blocks
and
one
of
the
reasons
why
they're
so
language
agnostic
is
because
they're
able
to
be
built
on
top
of
these
features
or
these
these
standards
that
pretty
much
almost
any
programming
language
could
use
today.
C
So
let's
say
you
know,
I'm
writing
something
in.
I
don't
know
in
rust
or
go
or
I'm
writing
something
in
haskell,
right,
hypothetically,
like
some
programming
language.
As
long
as
it's
able
to
talk
http
or
grpc,
you
should
be
able
to
work
with
dapper,
which
is
great
right
now.
As
you
see
here
like
some
of
these
things
might
have
sdks
like
there's
a
node
sdk,
there's
a
python
sdk,
it's
a
net
sdk,
but
the
sdk
is
completely
optional
right.
C
The
the
sdk
is
almost
like,
like
syntactic
sugar
right,
like
you
know,
you
don't
have
to
use
it
if
you
don't
want
to.
But
if
you
do,
then
you
know
there's
definitely
some
some
nice
cities
there
that
that
it
kind
of
brings
along
the
way
and
again,
like
I
said
before
at
the
bottom,
you
can
see.
Like
you
know,
we
have,
we
can
host
this
anywhere.
You
know,
so
we
have
folks
from
alibaba
cloud
from
aws.
C
You
know
kubernetes
tons
of
folks
that
are
contributing
to
this
project
as
well.
Now,
how
does
dapper
kind
of
work?
Let's
kind
of
talk
about
the
implementation
a
little
bit
and
again
also
remember
anytime
folks,
have
questions
again
feel
free
to
go
ahead
and
drop
them
in
the
chat
and
I'll.
We
can
always
pause
and
rewind
and
talk
about
them.
C
So
the
way
that
dapper
works
is
using
the
sidecar
pattern,
and
you
know
folks
are
familiar
with
things
like
service
meshes
or
you
know
those
types
of
things
like
this
might
sound
familiar
to
you,
but
essentially
you
have
an
application,
so
you
can
see
my
app
that's
there
on
the
left
side
and
you
have
your
site
card.
That's
deployed
next
to
every
instance
of
your
application
right.
So
when
I
say
every
instance
again,
we
think
about
microservices.
C
If
I
have
five
instances,
five
copies
of
my
app
that
are
actively
running,
I
should
have
five
copies
of
my
sidecar
right
next
to
it
that
are
also
actively
running
and
what
the
sidecar
does
is.
One
like.
It's
gonna
go,
look
at
your
app
and
say:
okay,
this
application.
The
service
is
available
at
this
port,
and
these
are
the
things
that
it
you
know.
These
are
the
topics
that
it
wants
to
subscribe
to,
and
these
are.
These
are
the
things
that,
like
it
exposes
to
the
world
and
then
from
the
perspective
of
your
application.
C
Oh,
like
a
service
mesh
sure
so
I'd,
say,
dapper
and
service
meshes
offer
almost
slightly
different,
like
capabilities.
A
lot
of
our
folks
use,
dapper
and
service
meshes
together.
So
you
know,
if
you
look
at
our
docs
you'll,
see
dapper
running
next
to
something
like
open
service
mesh
or
next
to
something
like
istio.
C
So
when
you
think
about
service
meshes,
those
are
for
again.
From
my
perspective,
those
are
more
so
aligned
with
like
access
control
with
message,
routing
or
I'm
sorry,
like
traffic
routing
between
you
know,
components
and
things
of
that
nature.
Dapper
is
more
so
aligned
around
making
patterns
and
abstractions
available.
C
I
want
to
almost
want
to
say,
like
service
meshes
and
dapper
operate
at
different
levels
of
your
programming
layer
right,
so
service
meshes
are
almost
like
the
communication
layer
like
where
is
traffic
going
and
dapper
is
more
like
in
your
code.
Right
like
it's
in
your
application,
like
you,
you
you
program
to
dapper
right,
like
you
call
dapper
in
your
code,
like
you
say,
hey
dapper,
give
me
my
states,
you
know
you
say
dapper,
you
know,
stand
up
and
call
this
actor.
C
C
Yeah
yeah,
exactly
right,
like
dapper,
you
know,
is
almost
like
it's
a
part
of
your
application
right
because
an
api,
you
call
and
it's
a
service
that
you
can
consume
versus
service
message,
which
does
provide.
You
know
different
capabilities
to
your
application
infrastructure.
But
it's
not
something
like
like
you.
Don't
call
istio
open
service
mesh
from
inside
of
your
application.
C
A
C
All
right
cool
all
right,
so
so
there
as
we're
looking
at
the
model,
the
sidecar
model
on
the
slide
here.
So
you
can
see
you
know,
there's
there's
a
well-defined
url
that
lets
us
know
which
one
of
the
building
blocks
that
we're
gonna
call.
So
the
first
one
shows
how
we
call
the
you
know:
service
service
invocation.
The
second
one
shows
state
management,
and
now
the
second
one
will
show
how
we
work
with
pub
sub.
So
again,
here
you
can
see.
C
I
want
to
publish
a
message
to
shipping,
and
then
you
know
there
the
orders
would
be
the
topic
and
then
you
know,
inside
of
your
http
payload,
you
know,
you'd
have
some
json,
you
know
payload
or
something
like
that
that
you
want
to
pass
along.
That'll
actually
have
the
data
that
you
wanted
to
share
and
again
there's
there's
tons
of
services
in
here
right.
So
there's
also
secrets
as
well
that
we
could
do.
C
Okay.
So
so
these
are
the
different
building
blocks
that
we
talked
about
right.
State
management,
pub
subs.
You
know
secret
management,
there's
actors,
there's
observability,
there's
tons
of
stuff.
Now,
let's
talk
about
what
happens
on
the
other
side
right
like
so,
your
app
is
going
to
go
ahead
and
call
these
services
through
dapper,
but
someone
has
to
configure
them
like
these
services
still
need
to
exist,
and
so
what?
If
you
remember
what
I'm
saying
the
building
blocks
are
essentially
abstractions
over
real
implementations.
C
So
if
you
can
see
here,
for
instance,
if
I
needed
a
state
store,
you
know
I
might
choose
to
use
redis,
I
might
choose
to
use
cosmos
db.
I
might
you
know,
choose
to
use,
you
know.
Dino
will
do
me
or
cassandra
whatever
the
case
is,
but
the
thing
is
like
my
application,
never
knows
about
it.
Like
I
never
install
like
the
node
package,
the
the
jar,
the
net
thing
like.
I
don't
have
to
do
that.
C
C
You
know
sometimes
what
I
again
another
I'd
like
to
tell
folks,
hey
whatever
you
want
to
use
locally
use
that,
because
maybe
that
makes
sense
right,
use,
redis
locally
use,
rabbitmq
locally.
But
then,
when
I
publish
my
application
to
the
cloud
I
might
want
to
use
a
hosted
service
instead,
but
whenever
I'm
switching
over
to
that
hosted
service,
my
application
code
doesn't
change,
and
that's
that's
something
I
want
to
keep
hammering
in
for
folks.
C
My
application
code
doesn't
change,
but
all
I
have
to
do
is
like
swap
out
the
configuration
and
now
you
know,
it'll
be
pointing
to
a
different
thing.
Obviously,
please
test
out
your
configurations.
Don't
just
swap
your
configuration
and
make
sure
you
know,
make
sure
the
right
permissions
and
those
types
of
things
are
set
up,
but
in
terms
of
like
your,
you
know,
your
business
code
like
we
don't
have
to
change
anything
there,
which
is
which
is
amazing.
C
Okay,
like
I
mentioned
before
a
little
while
ago,
so
we
can
host
in
a
few
different
places,
so
we
could
sell
post
locally
or
we
could
be
in
kubernetes
and
then
for
folks.
Some
folks
might
be
familiar
with
something
called
hashicorp
nomad.
So
you
know
all
those
type
of
environments,
hashicorp,
nomad
docker,
compose
darker
swarm
all
those
types
of
things.
C
No,
it
doesn't
so
what
it
will
do
so
and
service
bus
and
mass
transit,
like
they
add
some
additional
like
niceties
right,
like
some
additional
developer
things
on
top
of
the
broker.
All
again,
all
what
dapper
is
doing
is
it's
giving
you
abstractions
over
these
implementations
right?
So
you
know,
particularly
when
we're
talking
about
publish
subscribe,
you
know
your
app
says,
or
your
app
will
define
hey.
These
are
the
topics
that
I'm
interested
in
and
so,
when
your
dapper
sidecar,
that's
right
next
to
it
starts
up.
C
It's
going
to
keep
looking
at
that
implementation
right,
the
implementation
might
be
service,
bus
or
rabbitmq
or
redis,
or
whatever
you'll
keep
looking
at
the
implementation
that
we
set
up
in
configuration
and
we'll
say:
oh
okay,
someone
published
a
topic
for
this
thing,
I'm
going
to
pass
it
along
to
my
application
when
that's
associated
with
me,
but
that's
really
all
it
does
right.
It's
just
it's
just
monitoring
like
passing
those
things
back
in
for
that
particular
use
case,
but
I
know
I
believe
in
service
bus
and
mass
transit.
C
C
You
can
use
dapper
project
time
and
project
tie
actually
has
like
a
little
extension.
Actually,
maybe
I'll.
Let
me
swing
over
to
my
browser
really
quickly,
but
yeah.
If
you
look
up
project
thai,
I
think
that's,
I
think
that's
in
the
dotment
repo,
if
I'm
not
mistaken,
is
this
where
it
is
yeah,
there's
actually
a
dapper
extension.
C
Isn't
it
I'm
trying
to
see?
Where
is
this?
If
you
come
over
here
to
samples
there,
you
go
dapper
right,
here's
even
a
pub
sub
extension
and
so
yeah
you
could
totally
use
dapper
tie
and
again
it's
just
an
extension
right.
So,
like
you
know,
you
define
extensions
in
the
tide.yaml
file,
you
specify
dapper
and
you
know
the
rest
of
this
stuff.
You
know
you
specify,
you
know
some
dapper
configuration
and
then
the
rest
of
this
is
just
the
rest
of
your
thai.yaml
file,
but
yeah.
You
could
totally
do
that
for
sure.
C
Okay,
no
more
questions
all
right.
Let's
keep
it
going,
let's
see
what
we've
got
right,
so
here's
an
example
of
it
running
locally
on
my
machine
right
or
or
what
it
would
look
like
running
locally
in
your
machine
and
the
way
this
actually
happens
is
that
you
know
whenever
you
do,
dapper
run
right.
So
dapper
one
is
the
cl
cli
command
right
like
it's.
C
C
I
don't
know
web
app,
2020
right,
like
whatever,
whatever
your
app
is
called
and
what
it'll
do
it'll
stand
up
that
sidecar
and
it'll
stand
up
your
application
right
next
to
it,
and
then
it'll
also
look
for
those
components
right,
like
the
configuration
that
you
set
up
and
then
once
you,
and
also
too,
when
you're
running
local
in
your
machine
is
going
to
use
your
local
docker
instance.
If
you
have
docker
installed,
but
again
you
don't
have
to
use
docker.
C
If
you
don't
want
to
it's,
it's
totally
fine
and
then
also
too
I
mentioned
before,
like
it
also
runs
in
kubernetes.
I'm
not
gonna
show
you
a
kubernetes
demo
today,
but
I
know
a
lot
of
folks
always
ask
about
it.
The
way
that
this
works
is
that
you
know
there's
this
particular
installation
that
works
with
dapper
on
kubernetes,
and
so
what
will
happen
is
for
every
pod
that
you
specify
so
and
again
a
pot
is,
you
know,
like
a
a
container,
for
I
shouldn't
say
a
container.
C
Okay,
so
we've
been
talking
a
lot.
How
do
we
start
to
get
into
some
demos
right?
Hopefully,
folks
are
like
okay,
I
get
it
abstractions.
You
could
do
stuff
like.
Let
me
actually
see
what
it
looks
like
well,
let's
take
a
look.
First
at
service
invocation
and
pop
sub,
like
we'll
see
what
the
flow
looks
like
and
then
we'll
we'll
take
a
look
at
a
demo
and
we'll
see
exactly
how
it
works
so
with
service
invocation.
Remember
now
I
have
my
app
my
service
right
and
you
know
if
I
have
10
apps.
C
C
I
want
you
to
call
service
a
right
and
I
want
you
on
service
a
to
call
new
order,
and
so
the
two
dappers
now
since
they're
on
the
same
network
right
they're
gonna
use
something
called
mdns,
multicast
dns,
you
know
if
they're
in
different
environments
like
they
could
use.
Also
things
like
you
know,
coordinates
that
we're
in
kubernetes
and
also
too,
they
could
use
like
an
external
dns
provider.
C
So
I'm
going
to
say:
oh
hey,
I
found
this
dapper
sidecar
and
now
it'll
establish
an
mtls
connection,
so
mtls
being
like
mutual
tls
right,
like
there's
going
to
be
certificates
going
both
ways
right
from
the
client
and
the
server
in
this
case
the
two
dapper
sidecars
to
just
make
sure
that
that
connection
that
information,
that's
going
back
and
forth
is
encrypted
right.
So
you
have
a
secure
channel
between
these
sidecars.
C
So
anyway,
my
app
is
going
to
say
hey.
I
want
you
to
invoke
the
service,
but
your
app
doesn't
know
where
the
service
is
right.
Like
dapper
knows
where
it
is
because
it
knows
where
the
other
side
cars
are.
So
it
knows
where
to
forward
your
request
to,
and
then
you
know
your
request
or
your
service
knows
how
to
receive
it,
and
then
it's
going
to
send
your
information
back
right
and
again
same
way,
as
you
can
imagine,
with
the
state
service
right,
like
you're
gonna,
say
hey.
C
I
want
you
to
give
me
the
state
from
this
thing
right.
I
don't
know
where
you're
storing
it.
I
just
want
you
to
store
it
for
me.
Like
that's
all.
I
really
care
about,
like
here's,
some
information
that
I
want
you
to
put
in
there
right.
You
can
see
it's
giving
you
a
key
and
the
value
now
if
you're
looking
at
here.
C
And
then,
like
I
said
before,
if
we
need
to
swap
these
things
out,
you
know
your
app.
Your
app
will
be
none
the
wiser
right
like
I
could
swap
it
out
as
long
as
the
information
is
there
that
will
be
able
to
pull
it
back
for
you
all
right.
So,
let's
head
over
to
vs
code
and
what
I
want
to
do
is
show
you
an
app
or
actually
let
me
head
to
my
browser
first,
this
was
the
yeah.
C
It's
using
blazer
right
now,
so
it's
using
server
side,
blazer,
and
so
this
ui
is
just
you
know,
single
page
application
right
like
there's,
not
a
lot
of
crazy
things
happening
here,
but
you
know,
as
you
can
see
it's
you
know
fully
functional
app.
I
could
do
things
like
you
know.
I
could
rate
things.
I
could
add
things
to
the
cart.
C
C
C
So
one
there's
the
ui
service
right
like
there's
just
this
front
the
front
end
of
it
there's
an
application,
this
blazer
app.
That's
you
know
showing
us
the
ui
that
we're
looking
at
there's
the
web
api.
That
has
the
information
for
each
of
these
different
products
and
that's
a
completely
separate
service
running
in
a
different
place,
and
then
there's
also
the
order
or
the
checkout
processor
right.
C
So
whenever
I
click
these
things
right
and
I
come
up
here
and
I
you
know,
I
hitch
submit
it's
sending
that
into
a
queue
and
then
on
the
other
side
of
that
queue,
I
have
some
type
of
worker.
That's
listening
for
messages
to
be
put
onto
the
queue,
so
we
can
start
processing
them
as
they
you
know
as
they
as
they
come
up.
Okay.
So
how
do
we
implement
this?
Let's
see
how
we
actually
like
adapterize
this
application.
C
C
I
want
you
to
see
how
the
ch
proj
file
doesn't
have
a
lot
of
stuff
in
there
right.
It
has
nothing,
it
says
nothing
about
state
store,
it
doesn't
say
anything
about
dapper.
I
don't
have
anything
talking
to
me
about
publishing
messages.
There's
no
rabbitmq
references,
there's
no
redis
references!
There's
there's
nothing
in
here
right.
It's
pretty
much,
just
a
bare
bones:
blazer
app
with
exception
of
some.
You
know
some
design
assets
that
have
been
put
into
it.
C
Right
and
again,
the
same
can
be
said
about
some
of
these
other
ones
right,
so
you
know
I'll
click
through
the
rest
of
these
I'll
open
up
the
products
api
right,
the
products
api.
This
one
only
has
a
reference
to
mongodb,
but
other
than
that
it
doesn't
know
anything
about
dapper.
It
doesn't
know
anything
about
the
checkout
processor,
it
doesn't
know
anything
about
the
front
end
right
and
then
and
again,
I'm
just
showing
this
to
prove
to
y'all
like
this
thing
knows
nothing
about
dapper.
C
This
thing
only
knows
about
cloud
events
I'll
tell
you
all
about
what
cloud
events
are
in
a
little
bit,
but,
as
you
can
see
this
this
this,
this
checkout
processor,
whose
job
is
to
listen
to
a
queue
and
pull
messages
off
a
queue,
has
no
no
information
in
here
that
says
anything
about.
You
know
I'm
going
to
use
rabbitmq
or
service
bus,
or
you
know
sqs
or
anything
of
that
sort
like
it
doesn't
know
anything
about
it.
C
C
So,
let's
start
with
the
website
right,
because
the
website
has
to
make
a
request
whenever
it
stands
up
and
it
has
to
say
hey
give
me
that
product
information
right
so
inside
my
eraser
application,
I'm
going
to
go
into
the
components
folder
and
inside
of
my
components,
folder,
I'm
going
to
close
this
down
a
little
bit.
You
can
notice
here
that
I'm
making
a
call
to
this
thing
called
product
service
right
so
again
we're
looking
through
here.
C
You
know
I'm
using
product
services
to
add
ratings
and
doing
all
kinds
of
stuff,
but
it
really
it
doesn't
know
anything
particularly
about
dapper
and
now,
if
I
look
into,
I
should
have
a
services
folder
somewhere
in
here.
I
have
a
thing
here
called
dapper
product
service
and
all
this
is
doing
is
I'm
making
use
of
the
http
client
factory.
C
I
don't
know
if
everyone
is
a.net
person
or
not,
but
essentially
this
is
just
a
a
you
know,
like
a
class
that
helps
me
create
instances
of
http
client
that
I
could
use
to
make
requests
and
I'm
saying
hey,
create
this
http
client
right.
It
has
a
date,
the
name
dapper
right.
So
this
is
the
dapper
client.
I
want
you
to
use
and
then
I'm
just
making
a
request
right.
So
this
request
is
saying:
hey.
I
want
you
to
send
a
patch
request.
It's
sending
an
http
patch
request
over
to
this
service.
C
The
service
is
called
products
api.
I'm
calling
the
product
service
right
and
again
same
thing
with
get
products
right.
You
saw
in
the
beginning
whenever
my
component
starts
up
whenever
it
opens
up
for
the
first
time.
All
I'm
doing
is
that
I'm
saying
hey
call
the
products
api
and
you
know
call
the
product
service
again
notice,
the
difference,
this
one's
a
get
request
and
this
one's
a
patch
request
right.
C
So
again,
I'm
still
able
to
use
like
my
http
semantics
on
my
servers,
you
know
what
I
mean,
but
the
only
thing
that
this
application
knows
about
is
how
to
speak.
Http
right,
like
that's
the
only
thing
that's
going
on
here
now:
let's
take
a
look
at
the
products
service
a
little
bit,
and
this
may
or
may
not
surprise
you,
but
you
know
this
is
this
is
just
a
plain
old.
C
You
know
dot
net
controller
right,
so
folks
are
familiar
with
net.
We
create
controllers
to
handle
http
and
and
web
requests,
and
here
you
can
see
you
know
whenever
you
make
a
call
to
slash
products
right.
If
you
do
a
get
request,
I'm
going
to
call
this
get
list
thing
and
it's
going
to
pull
some
stuff
out
the
database.
If
I
want
to
get
a
product
by
id
right,
you
know
the
patch
requests
so
on
and
so
forth.
Right
but
again
like
there's
nothing
in
here
that
says
anything
about
dapper
right.
C
I
have
done
nothing
special
to
this
application
now,
so
you
might
be
asking
okay.
How
does
my
app
know
where
dapper
is?
How
does
it
know?
You
know:
okay,
the
urls
are
set
up
but
like
how
does
it
know
where,
like
what's
the
important?
What's
the
ip
just
like?
Where
is
this
stuff
set
up
right?
So
if
we
go
back
to
the
website
because
remember
we
have
the
website,
the
web
is
going
to
call
the
product
service.
If
we
head
over
to
the
website
and
again
this
is
very.net
specific.
C
But
again
this
really
has
nothing
to
do
with
net.
This
is
just
how
we
implement
it
right
inside
of
our
configure
services
right,
like
I'm
configuring,
an
http
client
with
this
name
and
I'm
just
saying:
hey
anytime,
someone
asks
for
a
dapper
client
just
give
them
a
thing
with
this
address
and
port
right,
and
so
I'm
assuming
that
dap
is
going
to
be
running
on
35
3500,
but
that's
it
right,
like
notice.
Nothing
else
in
here,
I
don't
have
any
api
keys
in
here.
There's
no
security!
C
Tokens
and
all
these
types
of
stuff
right,
I'm
pretty
much
just
saying
hey
when
the
http
client
factory
gets
asked
to
give
them
a
thing
of
dapper.
That
looks
like
this.
You
know
return.
You
know,
give
give
me
something
with
this
base
address.
Okay,
all
right!
So
any
questions
about
that.
So
far
before
I
move
on
a
little
bit.
A
C
Sure
sure
sure
so
now
so
we've
seen
how
what
the
code
looks
like
right.
At
least
we've
seen
what
the
code
looks
like
from
the
website
and
from
the
products
api
perspective.
Now,
let's
talk
about
how?
How
is
it
actually
running
now,
like
we
showed
before,
like
you
can
host
dapper
in
a
few
different
places
you
can
host
a
local
host.
You
can
run
it
in
kubernetes
me
personally,
I'm
running
it
in
docker
compose
on
my
machine
right
and
I'll.
Show
you
a
little
bit
of
what
that
looks
like
now.
C
If
you
look
here
on
the
right
side,
I
have
two
docker
compose
files
and
also,
if
anyone's
not
familiar
with
docker
compose
again
just
send
us
a
message.
Just
ask
the
question,
and
you
know
we
could
we
could
pause
and
we
could
dive
into
it
right.
So
I
have
two
docker
compose
files,
and
I
did
that
specifically
because
I
wanted
to
have
one
compose
file
for
my
application.
C
So
if
I
show
you
what's
inside
of
the
infrastructure
right
again,
I'm
using
mongodb,
you
know
to
store
my
information.
I
have
rabbitmq
and
redis
here
right
for
my
state
store
for
caching
and
also
for
sending
messages
and
things
of
that
nature
right.
This
hashicorp
vault
as
the
implementation
of
secrets,
if
I
needed
to
use
that-
and
I
also
have
zipkin
here
right-
it's
like
zipkin
is
a
tool
that
does
distributed
tracing
and
I'll.
Show
you
a
little
bit
what
that
distributed.
Tracing
piece
looks
like,
but
again
this
is
just
infrastructure.
C
There's
no
dapper
things
inside
of
this
particular
compose
file.
So
now
what
this
allows
me
to
do
is,
I
can
say,
docker
compose
up
and
now
I'll
just
have
these
services
that
are
just
running
on
my
network,
my
virtual
network
that
docker
has
created
for
me
now.
This
is
where
the
good
stuff
is
right,
like
if
we
take
a
look
at
this
compose
file
and
I'm
going
to
collapse
some
of
these
things
right.
C
So
each
one
of
these
things
represents
a
service
and
a
dapper
sidecar.
So
if
you
remember
what
I
said
before
for
every
instance
of
your
app,
you
have
you're
gonna
have
adapter
sidecar,
so
here
you
can
see.
I
have
a
website.
I
have
a
website,
dapper,
sidecar
products,
api
products,
api,
sidecar,
check
out,
processor,
processor,
sidecar.
Again
you
kind
of
get
the
point
right
like
app
sidecar,
app
sidecar
like
that's.
C
That's
it
right
like
say
it
to
yourself
when
you
leave
this
session
like
app
sidecar
like
that's,
how
dapper
works
right
and
if
we
take
a
look
at
what's
inside
of
these
so
again,
this
is
this
is
very
docker
compose
specific
right.
So
what
we're
doing
is
I'm
just
telling
it
to?
You
know,
build
my
application.
You
know
using
the
code
that
I
have
and
I
want
you
to
run
it
on
port
80.
right.
C
C
C
Everything
here
is
pretty
much
the
same,
like
it's
almost
like
a
copy
paste
job.
You
know
you
know,
as
developers
we
like
to
copy
paste
stuff,
but
this
is
the
same
thing
right.
What's
the
name
of
my
app
products
api?
What
port
is
it
on
port
80.
where's?
The
configuration
here's?
It
is
right
and
it's
all
pointing
to
the
same
place
right
so
on
and
so
forth.
C
So
again
like
as
we're
setting
this
up
inside
of
docker
compose,
you
set
up
your
application
and
then
you
set
up
your
sidecar
and
then
you
know
notice
how
all
these
also
too,
you
might
notice
this.
All
of
these
are
pretty
much
running
on
the
same
port
right
because
you
know
from
the
perspective
of
dapper
like
we're
all
in
the
same
place,
so
this
thinks
the
products
api
is
on
port
80
because
it
is
within
the
container
right,
just
like
the
checkout
processor
is
in
the
container
right.
C
So
now,
whenever
I
start
it
up,
all
that's
gonna
happen
is
docker.
Compose
is
gonna,
start
up
each
of
these
things
and
then
dapper's
gonna
be
able
to
say,
okay.
Well,
this
is
where
it
is.
You
know
now.
I
know
how
to
how
to
set
these
things
up.
Okay,
all
right!
Let's
go
back
to
the
slides
I'll
show
you
all
how
to
configure
these
things
in
a
second,
let's
head
back
to
the
slides
and
and
kind
of
keep
it
going.
C
Okay.
So
let's
talk
about
publish
subscribe,
so
the
publish
subscribe
facility
in
dapper
is
is
based
on
it's
like
a
simple
abstraction.
That's
based
on
topics
right
so
again,
whatever
the
implementation
is,
I
have
to
give
it
the
data
and
the
topic
that
I
want
to
publish
to,
and
also
my
app
or
my
service.
That's
on
either
side.
My
service
has
to
say
well:
what's
the
topic
that
I
want
to
subscribe
to,
which
is
cool
so
now
using
http.
I
don't
need
to
know.
C
C
So,
let's,
let's
take
a
look
back
at
our
application
and
let's
look
over
something
really
quickly,
so
you
remember,
I
said
before
right.
So
whenever
I
hit
the
submit
button,
it's
going
to
send
out
a
message
and
it's
going
to
publish
it
to
whatever
the
thing
that's
configured
right.
Well,
you
know
that
that
instance
that
rabbitmq
thing
that
I'm
using,
because
if
you
saw
I
had
it
there,
my
docker
compose
file
that
rapid
q
thing
that
I
had
was
not.
C
You
know
it's
not
code
that
I
control
it's
code
that
we
have
to
configure
right,
it's
an
app
that
I
have
to
configure.
So
so
how
do
we
do
that?
And
if
we
head
back
over
here,
I'm
going
to
go
back
to
my
code
base
now
you
might
notice
this
I'm
going
to
zoom
in
just
for
a
brief
moment,
but
you
might
notice
that
there's
a
thing
here
called
components.
C
If
you
remember
when
I
was
showing
you
my
docker
compose
file
for
my
sidecars,
I
had
this
thing
called
components,
but
I
also
had
this
thing
called
configuration
right
this
config.yml.
So,
let's
take
a
look
inside
of
these
things
and
see
how
exactly
we
we
set
some
of
this
stuff
up
from
the
other
side.
Again,
this
is
not
stuff
that,
like
you,
have
to
do
as
a
programmer,
but,
like
you
know,
someone
has
to
set
this
up
for
you.
C
You
know
whenever
you
deploy
it
now
to
configure
dapper,
we
have
to
use
yaml,
because
you
know
yaml
is
just
kind
of
how
people
do
microservice
things
these
days
and
here's
an
example
of
how
you
can
configure
rabbitmq
using
using
dapper
right.
So
you
know
I
give
it
some
metadata.
It
has
a
name,
and
then
here
is
the
part
where
you
kind
of
specify
the
configuration
right.
So
you
know
again
for
those
of
you
that
may
or
may
not
like
naval
again
look
at
it
this
way.
C
I
have
the
name
right
like
what
is
this
thing
called
and
then
how
do
I
configure
it
inside
of
the
spec
right?
So
inside
of
the
spec,
you
can
see
that
I
say
hey.
I
have
something
called
a
rabbitmq
server,
like
that's
the
name
of
my
rabbitmq
and
it's
inside
of
my
docker
network
right
and
then
this
is
the
port
that
it's
listening
on
and
then
here
you
know
I
could
you
know
I
could
pass
along
some
other
rabbitmq
specific
settings
there
that
I
need
to
pass
it
right,
but
it's
the
same
thing
too.
C
If
you
want
to
head
over,
we
take
a
look
at
redis
right.
If
we
look
at
some
of
our
redis
things,
for
instance,
here
like
if
I
wanted
to
use
redis
right,
I
could
say
pub
subreddits
again
this.
This
metadata
is
just
the
name
right
all
this
stuff
from
you
know,
everything
above
spec
is
copy
paste
right,
so
some
folks
might
be.
I
don't
know
what
this
is.
I
don't
know
what
it
is
either
I
just
copy
paste
it
right.
C
The
important
stuff
happens
in
the
spec,
because
that's
where
you
specify
your
settings,
excuse
me
so
here
you
can
see
I'm
doing
something
like
I'm
specifying.
This
is
redis
service
and
the
redis
service
is
running
on
this
port
right.
One
of
the
things
that
you
might
be
noticing
is
a
little
bit
different
from
the
rabbitmq
one.
Is
that
instead
of
me
just
having
the
name
of
the
I'm
sorry,
the
value
for
the
password,
I'm
actually
getting
it
from
a
secret
store
and
that
secret
store
is
also
configured
inside
of
dapper
right
but
see
now.
C
This
is
one
of
those
one
of
the
ways
that,
like
my
application,
doesn't
have
to
store
this
information
right.
My
app
doesn't
have
to
store
the
password
to
redis
and
the
password,
the
rabbitmq
and
the
password
to
all
these
other
things.
Right
like
I
could
just
let
that
happen
on
the
side
of
dapper
right
and
now
I
can
start
control
these
things
from
that
side.
C
But
if
I
look
here
at
the
bottom,
it
says
auth
says
I
want
to
use
the
secret
store,
called
local
secrets
right
and
if,
like
I
mentioned
before,
you
know,
I
could
use
different
types
of
secret
stores,
so
I
can
have
a
secret
store.
That's
like
hashicorp,
vault
or
azure
key
vault,
or
I
could
use
a
simple
local
file
that
I'm
using
here
only
use
the
local
file
for
testing
and
not
for
the
deployment.
Please
don't
do
it.
C
I
don't
want
to
get
in
trouble,
don't
put
your
secrets
in
the
files
in
production
right,
but,
as
you
can
see
here,
I
could
say
where's
that
configuration
where'd
it
go
here.
We
go.
I
have
a
local
sequence
configuration.
This
is
the
metadata
right
copy
paste
and
this
part
at
the
bottom
is
the
settings
right?
What's
the
name
of
the
file
that
I
want
to
connect
to
it's
dapper
local
secrets.json,
and
here
it
is
secret.json.
C
This
is
my.
You
know
this
is
some
password
here
that
I
put
in
here
right,
like
that's
the
password
that
I'm
using
for
redis.
But
again
I
just
have
it
here
for
testing
and
showing
you
an
example
of
how
you
know
my
app
doesn't
have
to
have
this.
This
can
be
in
key
vault.
This
could
be
up
in
the
cloud
somewhere.
It
doesn't
have
to
be
here
in
your
app,
but
you
know
you
could
use
it
like
this
solely
for
the
purposes
of
testing
right.
C
Let's
take
a
look
now
inside
of
here
and,
let's
see
how
we
can
set
up
can
distribute
distributed
tracing
now
distributed
transit
is
pretty
cool.
It's
one
of
those
things
that
when
you
start
building
micro
services,
like
you
didn't
you
don't
think
you
need
it
until
like
you're,
like
halfway
through
your
project
and
you're
like
okay.
Well,
this
code
is
working
and
this
service
is
working
and
that
service
is
working.
C
But
when
I
put
them
together,
they
don't
work
and
I'm
trying
to
figure
out
at
what
point
in
time
in
my
in
my
workflow,
does
it
stop
working
right?
I
need
to
be
able
to
trace
it
throughout
and
figure
out.
Where
does
this
thing
stop
right
like?
Where
is
this
thing
breaking
that's
where
just
retracing
becomes
pretty
fun
and
so
from
a
dapper
perspective?
C
C
So
let's
take
a
look
at
my
browser
and
I
can
show
you
what
some
of
these
things
kind
of
look
like.
So
I
mentioned
before
that
I
was
running
rabbitmq,
so
I'm
going
to
log
into
my
rev
mq
instance
right
and
one
of
the
things
I'll
zoom
in
a
little
bit.
One
of
the
things
that
you'll
notice
in
rabbitmq
is
that,
for
instance,
if
I
come
to
cues
notice,
this
thing
is
here:
contoso
dapper,
rabbit,
checkout
right.
I
didn't
create
this
right.
C
This
is
something
that
you
know
dapper
creates
for
me,
which
is
great
right.
If
I
come
over
here
and
I
look
at
exchanges,
this
is
not
something
that
I
created
right.
There's
a
there's,
an
exchange
here
for
checkout,
like
once,
you
configure
dapper
like
it'll,
just
create
these
things
for
you
and
then,
as
you
can
imagine
too,
as
dapper
shuts
down.
You
know,
depending
on
how
you
have
your
your
thing,
set
up,
it'll
just
it'll
just
go
away
right
like
it.
C
Won't
linger
around
if
you
don't
want
it
to,
but
again,
I'm
just
sure
you
again,
as
the
administration
of
these
things
happen.
You
know
these
are
things
that
like
get
created
and
then
also
purge
out
of
your
system,
based
on
how
you
have
your
thing
set
up
in
dapper,
I'm
also
using
this
thing
here.
This
is
called
redis
insight,
like
it's
a
little
utility
app.
This
is
really
cool
for
for
looking
at
things
like
this.
C
Now,
let's
say
I
go
ahead
and
let's
pop
some
stuff
in
here,
I'm
just
going
to
add
some
stuff
to
the
cart
right
now,
I'm
using
redis
for
state
store,
even
though
it's
popping
up
here.
If
I
come
back
to
this,
what
should
happen?
I
think
I
got
to
refresh
this
thing
because
they
don't
show
up
by
default
there
you
go
right
so
notice.
Now
I
have
a
some
state
right
and
then
there
you
see,
you
know
the
quantity
of
my
products
right.
C
C
C
I
want
you
to
put
this
thing
in
redis,
because
that's
how
we
configured
it,
but
you
know
again,
I'm
not
I'm
not
the
one,
that's
controlling
it
and
I'll
go
ahead
and
I'll
purge
this
I'll
go
ahead
and
hit
submit
right
and
then,
when
we
come
back
and
we
refresh
this
is
this:
is
this
a
refresh
button
there
you
go
right,
so
you
notice,
I
refreshed
it
and
then
it's
gone
right.
My
state
has
disappeared.
C
You
know
this
thing
no
longer
exists
right,
but
again,
dapper
manages
those
things
for
me
like
that's,
not
stuff
that
we
have
to
manage.
Okay
now,
let's
take
a
look
at
zipkin.
So,
like
we
mentioned
before,
zipkin
is
a
tool.
That's
really
helpful
in
doing
distributed
tracing
now.
If
I
go
ahead
and
hit
just
hit
the
search
button.
What
you're
seeing
here
is
my
apps
that
I
created
I'm
going
to
zoom
in
because
I
know
that's
super
small,
but
what
you're
seeing
here
is
my
apps
that
are
created.
C
I
have
my
checkout
processor.
I
have
my
website.
I
have
my
web
api,
but
again
because
of
plugged
in
dapper,
and
I've
told
it
to
use
zipkin
as
my
source
for
tracing.
I
could
look
and
see
how
the
information
flows
throughout
my
application
so
notice.
You
see
that
I
don't
know
if
you
can
see,
but
it's
like
a
little
dots
that
keeps
flowing
by
every
now
and
again.
C
Whenever
my
website
starts
up,
it's
going
to
make
a
call
to
the
products
api
right
and
then
the
products
api
is
gonna,
send
back
some
information
and
I
might
get
information
about
all
the
products
I
might
get
information
about
one
product.
I
might
wanna
update
some
things
like
that
goes
down
this
route
and
now,
whenever
I'm
publishing
a
message
right
and
even
though
I'm
publishing
through
redis
or
rabbitmq
right,
I
could
still
see
where
it's
flowing
to
right.
So
I
could
see
how
it's
flowing
from
my
website
into
my
checkout
processor
right
again.
C
Zipkin
is
just
one
thing
that
you
could
use
for
this.
If
folks
are
going
to
the
cloud
you
could
use
application
insights
because
there's
an
app
map
thing
that
you
could
use.
Jager
is
another
thing
that
visualizes
some
of
these
application
traces.
That's
that's!
That's
really
useful
as
well,
but
again
you
can
imagine.
I
might
have
a
lot
more
services
than
these
right.
This
is
just
three
services,
but
you
might
have
tons
of
them
and
you
want
to
know
how
is
your
information
flowing
like
these
visualizations
are
really
helpful
as
you're
building
applications.
C
But
again
I
don't
have
anything
in
my
code:
no
packages,
no
configuration
in
my
application
code.
That
knows
anything
about
zipkin.
This
just
happens
because
those
dapper
sidecars
can
handle
a
lot
of
that
stuff.
For
me
right
so
again
as
a
developer,
I
can
really
just
focus
on
what
I'm
working
on
I'm
not
necessarily
digging
into
some
of
those
pieces.
C
Okay,
so
that
was
the
observability
piece
right.
What's
cool
about
the
observability
piece,
so
I
showed
you
how
it
uses
zipkin,
it's
actually
using
open,
telemetry
internally
right,
it's
able
to
use
some
of
those
open,
telemetry
like
standards
and
apis
to
be
able
to
send
your
messages
to
different
places.
So,
like
I
said
like
you
could
use
app
insights,
you
could
use
datadog.
You
know.
Prometheus
is
another
thing
that
folks
use
to
capture.
You
know
metrics
and
logging
and
things
of
that
nature.
C
If
you
want
to
you
know
you
can
configure
the
sample
rates
and
all
kinds
of
stuff,
I
think
there's
even
a
dapper
chart.
I
think
the
charts
is
what
you
call
them
for
for
grafana.
So
again,
if
you
wanted
to
have
like
a
dashboard
like
this
and
put
it
up
on
your
monitor
in
your
team
room
and
just
kind
of
monitor
how
things
are
going
right,
you
can
see
things
like.
C
C
Okay,
moving
forward
a
little
bit,
there's
a
couple.
Other
features
that
I
didn't
have
a
chance
to
put
into
the
demo,
because
it's
it's
a
lot.
I
definitely
want
to
leave
some
more
time
at
n2,
so
we
could
talk
about
it
and
talk
about
you
know,
questions
and
anything
that
you
all
might
be
concerned
about.
But
you
know,
dapper
has
input
output
triggers
if
folks
are
familiar
with
like
that.
Azure
functions.
C
Serverless,
like
you
know,
eventing
type
model
like
we
can
do
that
as
well.
We
have
different
bindings
that
we
could
use
on
either
side.
So
whether
we
want
to
you
know,
take
inputs
from
things
like
social
media
or
trigger
things
like
you
know,
database
inserts
or
sending
messages
with
twilio
or
anything
of
this
sort
like
we
could
totally
do
that.
Dapper
has
a
virtual
actor
framework,
which
is
really
cool.
C
A
lot
of
folks
always
ask
me
like
how
does
this
compare
to
things
like
orleans,
microsoft,
orleans
or
akka.nets,
or
you
know,
name
your
actor
framework
and
the
thing
that
I
always
say
is
you
know
always
remember
that
dapper
is
not
programming,
language
agnostic,
so
you
can
have
actors
in
different
programming
languages.
You
can
have
dot-net
actors
and
python
actors
and
java
actors,
whereas
things
like
orleans
and
of
that
nature
are
very
specific
to
like
the
platform
and
the
programming
language
that
they
run
it
and
that's
not
a
good
or
a
bad
thing.
C
Now
I
want
to
say
it
was
march
march
this
year.
I'm
sorry
may
this
year.
So
just
you
know,
just
a
couple
of
months
ago
we
released
dapper
1.2.
So
I
was
really
excited
about
this
release,
because
this
added
some
additional
capabilities
that
you
know
I
was
a
big
fan
of
one.
We
had
some
new
components
that
were
added
from
some
different
companies,
so
like
folks,
like
alibaba
and
the
man
group,
which
are
you
know
some.
C
You
know
cloud
infrastructure
folks
submitted
like
some
some
different
components
if
you're
familiar
with
console
console
from
hashicorp.
Essentially
what
it
does
is
service
discovery
like
it's
a
service
discovery
component,
but
until
this
release
came
out,
you
know
you
had
to
use
whatever
the
dapper
facilities
were,
but
now,
like
you,
have
a
separate
building
block
that
we
could
use
for
dns
resolution.
C
So
now
you
can
plug
in
things
like
console,
and
you
know
maybe
someone
will
you
know
you
know,
contribute
like
a
different
one
or
or
something
like
that
right,
pub
sub
without
cloud
events.
Oh
you
know
what
that
reminded
me.
I
did
not
show
you
the
checkout
processor.
Shame
on
me
for
not
doing
that.
Let
me
show
you
what
the
checkout
processor
looked
like,
because
if
I
don't
show
you,
then
that
slides
not
going
to
make
any
sense
to
you.
C
I
want
to
listen
to
this
pub
sub
for
this
topic,
and
this
is
the
routes
I
want
you
to
send
it
to
it's
almost
like
specifying
a
callback
right.
So
whenever
an
event,
fires
or
whatever
a
message
gets
published
for
checkout,
I
want
to
send
it.
I
want
you
to
send
it
to
the
checkout
route
and
here's
a
checkout
route
right
here
right,
so
whenever
slash
checkout
gets
hit
on,
you
know
on
this
controller
is
going
to
go
ahead
and
execute
this
function
and
one
of
the
things
that
dapper
does
is
it
uses?
C
This
thing
called
cloud
events
like
cloud
events
is
a
standard.
I
think
it's
you
know
fully
supported
by
the
cncf
and
is
trying
to
be
adopted
by
a
lot
of
message.
Brokers
and
just
you
know,
distributed
systems
messaging
tooling.
It
essentially
allows
you
to
create
wrappers
around
messages
like
like,
very
well-known,
consistent
wrappers.
C
One
of
the
ways
I
kind
of
think
about
it
is
like
imagine,
http,
and
you
know,
http
has
a
a
request
payload,
but
that,
in
addition
to
that
payload,
there's
headers
that
you
could
look
at
right,
and
so
before
you
read
the
payload,
you
can
look
at
the
headers
and
you
can
make
decisions
about
the
contents
of
that
message
right.
Well,
I
think,
up
until
now
like
there
was
really
no
standard
that
specified
what
the
shape
of
that
looked
like
for
for
messaging
events.
C
Right
because
again,
like
they're,
very
well
known,
http
headers,
you
know
content
type
and
cache
control,
and
you
know
those
types
of
things
but
for
messaging
we
didn't
really
have
something
like
that,
and
this
is
kind
of
where
cloud
events
comes
into
play
so
because
dapper
does
rely
on
standards.
It's
going
to
send
us
messages
using
like
this
cloud
events
pattern.
So
what
I'm
doing
here
is
I'm
just
saying
you
know
from
the
request
that
comes
in.
C
I
want
you
to
read
it
as
a
cloud
event
and
then
I
could
start
looking
at
things
like
the
id
and
the
type,
and
you
know
the
data
content
type
like.
I
could
start
looking
at
the
metadata
of
the
message
and
then
I
can
decide
what
do
I
want
to
do
with
that
message
or
not
right
and
so
in
a
very
short
compressed
way.
C
C
I
have
a
package
that
knows
how
to
read
cloud
events
in
dot
net,
but
I
don't
know
you
might
be
in
another
language
like
I
don't
know
c,
plus,
plus
or
python,
or
I
don't
know
if
they
have
any
I'm
just
saying
hypothetically,
it
might
be
on
a
different
one
and
they
don't
know
how
to
talk
to
cloud
events.
They
don't
know
how
to
serialize
it
or
deserialize
it.
Now
we
can
set
up
dappers
so
that
it
can
say
hey
whenever
you
send
me
a
message.
C
Another
thing
that
we
have
is
this
thing
called
api
scoping
now
with
api
scoping.
I
showed
you
like.
We
have
those
different
building
blocks
now
you
could
turn
them
off
right,
so
you
could
say:
hey
for
this
dapper
sidecar,
I'm
going
to
turn
off
state
management,
I'm
going
to
turn
off,
publish
subscribe.
C
I'm
going
to
turn
off
stuff,
you
know,
because
by
default,
like
they're
all
turned
on,
even
if
you
don't
configure
them
or
not-
and
you
might
say
hey,
I
don't
want
anyone
to
use
these
apis,
I'm
just
going
to
turn
them
off
right,
and
so
that's
something
that
you
could
do
here
now
in
1.2
and
this
here.
This
is
the
name
resolution
that
I
was
talking
to
you
folks
about
a
little
bit
earlier.
C
Where
now
you
know,
instead
of
just
using
mdns
or
you
know
the
kubernetes
thing,
you
can
use
an
external
dns
provider
like
something
like
hashicorp
console
and
now
you
could
discover
where
your
adapter
containers
are
or
your
dapper
sidecars
are
using
console
now.
Why
do
we
want
this?
Why
is
this
a
good
idea?
Well,
it's
a
good
idea,
because
when
you
think
about
it,
what
what
actually
happens?
Oh,
not
far
too
quickly
when
you
think
about
it,
when
you're
inside
of
kubernetes
or,
if
you're
running
on
localhost,
how
do
you
this?
How
do
you?
C
How
do
you
discover
sidecars
that
are
on
a
different
network
or
in
a
different
data
center
or
somewhere
else?
It's
kind
of
hard
for
you
to
do
that
right,
like
because
the
dns
you
know
your
dns
is
not
going
to
be
able
to
go
all
the
way
over
there.
At
least
mdns
is
not
going
to
do
that.
Kubernetes
dns
is
not
going
to
do
that
right.
You
have
to
you
know
you
have
to
do
some,
some
special
things
to
make
that
happen.
C
Well
now
you
know
now
that
we
can
have
external
dns
providers
that
makes
that
situation
a
little
bit
easier
right.
So
hey,
I
might
be
like
I'm
in
florida
and
you
might
have
a
data
center
in
africa
or
you
know
london
or
somewhere
else.
Now
I
can,
you
know,
use
the
power
of
you
know
these
external
dnses
and
I
can
start
reaching
out
and
grabbing
stuff,
which
is
really
cool
and
again
this
was
just
released
in
1.2.
C
So
right
now,
there's
only
console
in
there,
but
I
can
imagine
you
know
we'll
have
some
other
things
popping
up
to
fill
that
space
too.
Okay,
so
just
before
I
end
off,
I
just
want
to
share
some
resources.
People
always
ask
like,
what's
the
best
place
for
me,
to
go
to
learn
about
dapper,
and
my
answer
is
always
like
there's
tons
of
places
to
go
to
learn
about
dapper,
you
can
go
to
dapper.io,
there's
tons
of
docs
there
you
know.
C
You
know
install
it
based
on
your
operating
system,
windows,
linux,
mac,
whatever
you're
using
and
then
kind
of
just
follow
through,
like
that's
a
great
place
to
go.
There's
the
github
repo
there's
a
blog,
there's
the
discord
channel,
I'm
a
big
fan
of
the
discord
channel.
I
think
I
actually
even
have
it
open
here
yeah,
I
kind
of
do
let
it
load
for
a
second
but
yeah.
You
can
come
over
here
to
the
discord
channel
and
then
the
team
is
in
here
they're
making
announcements.
C
What
is
this?
How
do
you
close
this?
There
we
go,
there's
different
channels
for
the
different
sdks.net
sdk
go
sdk,
there's
a
rust
sdk.
Now,
I'd
even
know
that
see
there
you
go.
I
actually
really
love
coming
in
here
too,
and
checking
out
the
show
and
tell
here
you
can
see
different
folks
from
the
community
that
are
like
here
are
some
things
that
I
built
with
dapper
here:
blog
posts
that
I've
written
and
samples
that
I've
created.
C
C
The
ebook
is
free,
it's
online
and
when
I
say
it's
free,
it's
free,
like
you,
don't
have
to
put
in
your
email
address
to
get
it
emailed
to
you.
You
can
just
you,
can
just
go
straight
to
the
link.
It'll,
take
you
to
docs.microsoft.com
and
you
can
learn
how
to
start
building
dapper
applications
with
diamond.
C
C
Yes,
yes,
you
can
and
one
of
the
ways
I
I
mean
we
actually
even
have
samples
for
that.
But
if
you
look
at
here
right
like
if
I
want
to
run
it
in
windows
right,
I
can
install
in
windows
or
if
I
wanted
to
run
it
in
kubernetes,
there's
actually
a
kubernetes
tutorial
in
here
somewhere
there's
a
kubernetes
tutorial.
Let
me
see
kubernetes
there
we
go
how
to
get
dapper
up
and
running
and
kubernetes
like
there's
tons
of
stuff,
and
this
will
run
on
a
single
node
cluster.
Yes,
so
you
could.
C
I
gotta
get
rid
of
this
one.
I
gotta
set
this
thing
up.
I
gotta
you
know,
there's
work
that
needs
to
happen
and
that
not
that
work
is
a
bad
thing,
but
you
know
if
you
could
save
time
and
abstract
some
of
these
things
and
focus
on,
like
I
don't
know,
building
your
sports
app
or
building
your
entertainment,
app
or
building
your
shopping,
cart,
app
or
whatever.
The
case
is,
like
I'm
pretty
sure,
like
your
your
managers
and
business
people
would
really
appreciate
it.
A
And
I
I
think
too,
from
from
a
secure,
you
know
software
development
life
cycle
perspective.
You
know
being
able
to
abstract
that
and
kind
of
think
about
it,
where
you
can
kind
of
make
the
decisions
and
and
not
have
to
install
a
ton
of
packages
that
are
just
tied
in
and
you
can
go.
Let
me
think
about
it.
What
do
we
want
to
do
with
this
and
and
the
implementation
seems
pretty
straightforward
to
to
use
dapper
as
a
tool
to
you
know
you
have
quite
a
bit
of
choices
with
it.
C
For
sure-
and
you
know
for
my
application-
I
you
know
this
was
a
net
demo,
it
doesn't
have
to
be
a
dot-net
demo.
It
could
be
any
process
that
you
can
run
on
the
machine
right.
I
want
to
say
process
like
any
process
that
you've
written
that
you
could
run
on
a
machine.
It
could
be
python,
it
could
be
go,
it
could
be
c
plus
plus
it
could
be
whatever
you
know.
As
long
as
they
can
talk
to
and
respond
to,
http
then
or
grpc,
then
you
know
it's
good
to
go.
C
C
Three
there
you
go
reverse
proxy,
that's
what
it
is
so
yarp
for
roads
that
might
be
familiar.
Europe
is
yet
another
reverse
proxy.
That's
what
why
arp
that's
what
it
stands
for.
The
purpose
of
yarp
was
not
just
to
create
another
reverse
proxy,
as
the
name
says,
but
the
goal
was
to
create
an
extensible
reverse
proxy
for
net
developers
right
so
you
know
we
we've
had
a
lot
of
folks
come
and
say:
hey.
C
We
want
to
be
able
to
write
code,
you
know
what
I
mean
and
put
it
in
like
the
proxy
layer
and
take
it
out
of
our
application.
So
you
think
about
things
that
proxies
do
for
you
right
like
they
do
filtering.
They
do
things
like
throttling.
For
example,
caching,
like
proxies,
do
a
lot
of
things,
for
you
it'll
be
great.
If
I
could
have
some
parts
of
my
some
of
the
those
cross-cutting
concerns,
I
suppose
like
in
the
proxy
and
out
of
my
app
right.
C
I
know
that
the
proxy
could
route
to
one
or
many
apps
that
are
sitting
behind
of
it.
What's
happening
with
your
app
is
still
active
man.
They,
let's
see
what
was
the
last
release
I
hate
when
it
does
this,
I
really
hate
this
okay
hold
on
one.
Second,
let
me
move
this
to
another
window.
Yarp
is
still
active.
They
had
a
release
pretty
yeah
just
in
april.
So
just
this
past
april
was
the
last
release
of
yarp
and
yeah.
C
A
C
C
Okay,
like
what
I
was
talking
about
from
from
a
component's
perspective,
but
I
can
also
say,
like
my
web
api,
like
my
my
my
my
website,
app,
can't
call
the
what
would
I
call
that
thing
that
products
api
as
an
example
right,
so
it
works
with
the
dapper
things,
but
it
works
with
you
know
the
services
service
control.
Oh
here,
it
is
perfect,
apply
service
access,
control.
There
we
go
so
I
could
say
I'm
trying
to
find
an
example
right
right.
C
A
C
Wow,
I
you
know,
I
heard
the
announcement
I
haven't
dug
into
it
too
much.
I
just
heard
that
android
apps
are
gonna,
be
running
on
windows
I
mean
we've
had
a
we've
had
a
good
relationship
with
like
android
apps
in
general,
like
we
have
a
good
partnership
with
samsung,
you
know,
particularly
when
it
comes
to
office
and
office
interoperability.
C
I
think
it
makes
a
lot
of
sense.
You
know,
I
think
it
also
gives
android
developers
like
a
wider
audience
to
deploy
their
apps
to
you
know.
I
know
we're
in
the
united
states,
but
if
you
look
at
the
market
share,
there's
there's
more
android,
apps
and
phones
than
there
are
for
ios
right,
so
that
now
this
check
kind
of
just
opens
up
the
world
for
just
some
new
ways,
for
developers
to
to
take
advantage
of.
C
But
yeah,
but
well
folks,
today
again
I'd
love
to
know
what
you
know.
You
all
think
about
dapper
I
mean
our.
I
mean
this
is
a
user
group.
So,
let's,
let's
talk
man
like
are
you?
Are
you
all
building
microservice
applications?
Are
you
thinking
about
building
microservice
applications?
You
know,
what's
what's
everyone
kind
of
kind
of
doing
and
working
on
and
are
thinking
about
working
on?
Are
you
all
folks
using
kubernetes?
I
know
I
know
a
little
bit
of
kubernetes,
but
I'm
not
like
a
kubernetes
ninja
or
anything
like
that.
C
A
Yeah
I've
been
considering,
I
have
kind
of
some
personal
projects
that
I've
been
considering
kind
of
messing
around
with
some
microservices
and
converting
them
over.
I
haven't
really
moved
past
the
kind
of
the
design
stage
and
thinking
about
it,
I'm
still
kind
of
trying
to
come
up
with
a
game
plan
before
I
move
forward.
C
Yeah
yeah,
you
know,
I
have
a
lot
of
friends
locally,
that
are
developers
and
you
know
they're
they're
still
getting
up
to
speed
with
what
containers
are
you
know
and-
and
I
get
it
right
because
everyone-
everyone
doesn't
run
at
the
same
pace.
You
know
what
I
mean
and
they
try
to
understand
like
what
are
some
of
the
developments
benefits
of
using
containers
and
then
like
okay.
Well,
I
have
these
containers.
How
do
I
manage
these
containers
and
what
are
the
tools
do
I
need
what
the
tools
do?
A
Yeah
something
I've
been
thinking
about
too
just
kind
of
I
like
to
think
I
don't
know,
maybe
not
so
much
realistically,
but
philosophically
of
you
know
how.
How
does
it
compare
to
start
from
scratch
with
microservices
rather
than
transfer?
You
know
an
existing
monolith
over,
it
seems
like
it
would
be.
A
C
So
it's
like
the
question
like
how
like
what
do
you
call
a
microservice
right?
I
mean
I'm
a
rhetorical
question
right,
but
you
know
like
how
micro
is
a
micro
service
like
how
do
you
know
like
these
are
the
pieces
that
I
want
to
break
apart,
and
it's
kind
of
hard
to
know
that
if
you
don't
have
an
app
to
break
apart,
you
know
to
me,
or
unless
you've
had
some
experience,
building
something
before
now,
you're
rebuilding
it
over
from
scratch.
C
It's
a
new
app,
but
it's
really
an
old
app
you're
trying
to
replace
you
know
because
a
lot
of
times
what
happens
is
people.
You
know
what
some
of
the
failures
I've
seen
with
folks.
Is
that
like
we're
going
to
do
micro
services
and
we're
going
to
build
all
our
new
apps
and
micro
services,
but
like
they
don't
know
what
are
those
boundaries
that
constitutes
a
single
service
right
like?
Should
a
single
http
method
be
a
microservice?
C
Probably
not.
You
know,
in
my
opinion,
probably
not
right,
but
then
should
my
whole
payments
gateway,
be
a
microservice.
I
don't
know,
maybe
maybe
not
right.
You
know
like
what's
the
data
that
I'm
going
to
be
sharing
across
my
different
domains,
right
like
if
you
think
about
I,
have
the
concept
of
a
customer
or
a
product,
it
has
to
probably
be
in
the
ui
and
it
has
to
be
in.
I
might
have
a
crm
system.
Maybe
my
crm
is
a
micro
service.
C
I
don't
know
right
like,
and
I
have
payroll
and
I
have
all
these
different
types
of
things
like
products
and
reports
like
all
of
them
have
the
concept
of
a
customer.
You
know
I
mean
like
how
do
I,
how
do
I
share
that
around
these
different
micro
services
that
I
have
like?
What's
the
best
way
for
me
to
kind
of
break
those
apart,
and
even
with
that?
How
do
I
do
reporting?
How
do
I
report
on
a
micro
service
architecture
right
like
I
might
have
different
piece
of
information
scattered
all
over
the
place?
C
You
know
I
mean
how
do
we
do
these
types
of
things?
I'm
not
saying
that
they're
they're
they're,
not
these
problems
are
solved
problems
but
like
we
have
to
think
about
them
right.
We
have
to
think
about
like
what
are
the
implementation
details
that
we
need
to
consider
right,
like
where's,
our
data
warehouse
going
to
live
like
how
is
it
going
to
talk?
Are
we
going
to
use
like
a
cqrs
partner?
Are
we
going
to
do
things
like
event,
sourcing
and
all
these
types
of
things
we
still
have
to
have
like?
C
A
For
me,
that's
that's.
The
funnest
part
of
the
coding
is
kind
of
you
know,
breaking
everything
down
to
decisions
and
going
well.
Why
would
I
do
this
versus?
Why
would
I
do
that
and
what
what
what
are
our
values
and
and
so
on
and
so
forth?
For
me,
that's
that's
far
more
fun
than
any
other
aspect
of
software.
C
Yeah
I
mean
it's,
I
think
software
developers
at
heart
are
just
people
that
like
to
solve,
puzzles
like
that's.
Our
job
is
to
solve
puzzles
at
the
end
of
the
day
and
some
puzzles
are
more
fun
than
others,
but
at
the
end
of
the
day,
we're
solving
puzzles
right,
and
you
know
if
you,
if
you
love
your
job,
like
you,
probably
love
solving
puzzles,
and
you
know
finding
solutions
to
problems.
A
C
C
So
if
you're
going
to
use
dapper,
if
you're
going
to
use,
containers
and
stuff
like
that,
like
you're,
probably
going
to
run
windows,
containers
versus
linux
containers
and
then
there's
a
whole
other
conversation,
we
can
have
about
windows
versus
linux
containers.
But
if
the
question
is
solely
is
to
use
dapper,
do
I
have
to
change
or
not
use
wcf,
and
the
answer
is
no.
You
could
use
wcf
just
use
the
http
binding,
because
wcf
can
speak
to
http
sounds.
C
A
C
C
At
least
I
hope
they
know
how
their
own
app
works
and
then
they're
going
to
go
through
the
process
of
deconstructing
it
into
pieces
that
make
sense-
and
you
know
I
can
imagine
they're-
probably
going
to
want
to
make
use
of
the
service
discovery,
pieces
right
and
being
able
to
call
and
figure
out
where
those
other
things
are
within
the
architecture.
I
can
imagine
you
probably
want
to
do
some
distributed
tracing,
because
you
want
to
make
sure
that
the
messages
are
going
in
the
right
way.
C
I
can
imagine
you
want
to
do
things
like
maybe
pubs
up.
Maybe
you
have
maybe
in
your
ruby
app,
I
don't
know
I'm
just
making
making
it
up,
but
maybe
you're
using
you
know
a
redis
or
rabbitmq
or
a
nats
or
activemq
or
whatever
to
pass
these
messages
around
right.
Like
you
know,
your
developers
now
just
need
to
learn
how
to
send
http
requests
to
dapper,
and
they
don't
need
to.
You
know
be
too
concerned
about,
like
the
other
pieces
around.
A
A
C
D
C
Yeah,
here's
here's!
Here's
literally
an
issue,
a
bunch
of
folks
that
are
using
dapper.
You
know:
china,
australia,
the
uk,
united
states
yeah,
there's
tons
of
folks
in
here
that
are
using
it.
I'm
pretty
sure.
If
you
go
to
the
what's,
it
called
I'm
pretty
sure.
If
you
go
to
the
home
page,
I'm
pretty
sure
we
have
them
on
the
home
page
too.
I'd
be
surprised.
C
If
we
didn't
there,
we
go
right
like
companies
using
dapper,
so
yeah
I
mean
there's
a
lot
of
folks
using
dapper,
obviously
we're
using
dapper
too,
because
you
know
we
built
it.
It'd
be
kind
of
silly
if
we
didn't
use
it,
but
yeah
there's
lots
of
folks
using
dapper
big
companies,
small
companies,
you
know
hobbyists
stuff
like
that,
because
again
one
of
the
good
things
about
dapper
is
it's
very
lightweight.
It's
not
a
heavy
process.
C
Your
process,
like
the
code
that
you
write,
is
probably
going
to
be
bigger
than
dapper.
You
know
what
I
mean
like
all
dapper
is
doing
is
like
it's
like
a
funnel
right,
like
it's
taking
in
requests
and
it's
passing
it
along
and
it's
applying
some
configuration
and
policies
to
it.
But
you
know
there's
really
not.
C
C
C
F
right,
whatever
the
case
is
right
and
then
inside
of
here
I
should
probably
put
it
in
this
one
instead
right,
but
imagine
I
did
it
up
here
and
your
your
contents
right,
because
what
you're
passing
into
graphql
is
like
a
json
document
that
specifies
your
query
right
so
that
that's
just
the
content
right.
So
you
you
create
your
payload
and
you
call
the
endpoint
magic.
We
have
graphql
right
it,
just
it
just
kind
of
works,
because
again,
graphql
is
just
http
right.
C
It's
you
know
the
difference
with
graphql
and
rest,
because
I
think
a
lot
of
folks
always
seem
to
think
like
it's
hugely
different.
The
convention
is
different.
It's
still
http
right,
there's
still
headers,
there's
still
you
know,
urls
and
and
request
bodies
and
status
codes
like
still
http
just
the
convention
is
different.
C
Yeah,
there's
there's
some
discussion
in
there
about
that,
and
I
think
it
would
be
great
if
folks
comment
on
it.
There's
something
that's
been
spoken
about,
that's
not
it.
Where
is
this
thing
there
we
go,
there's
something
that's
been
spoken
about,
but
we
haven't
finalized
on
it
yet.
But
if
folks,
I
can't
type
for
nothing
today.
C
If
folks
are
interested
definitely
head
over
here-
and
you
know
we
could
talk
about
it.
You
know
like
there's.
Definitely
some
issues
in
here
about
that
error,
handling
or
transient
faults
right,
there's
an
issue
in
here
somewhere.
I
don't
know
where
it
is,
but
I
don't
remember
where
it
is,
but
there's
an
issue
in
here
that
talks
about
it
that
specifically
talks
about
retries.
I
think
I
think
that's
what
it's
called.
I
think
it's
called
the
retry
issue,
yeah
yeah
resharp
pattern.
C
D
A
C
C
Yeah
yeah
yeah-
I
do
so
I'll
I'll
paste
this
in
the
chat
somewhere,
but
mine
is
just
at
github,
cecil,
phillip
and
it's
a
contoso
crafts.
So
let
me
tell
you
a
little
bit
about
this
project
or
this
repo.
This
repo
is
kind
of
different
because
there's
nothing
really
in
maine,
like
everything
is
in
branches,
and
so
I
have
a
lot
of
different
implementations
of
the
same
app
in
different
branches.
So
I
have
an
implementation
in
orleans
using
actor
framework.
I
have
a
thai
version.
That's
just
using
thai
no
dapper.
C
I
have
steel
toe
folks
have
ever
heard
about
using
steel
toe
for
building
micro
services.
Steel
toe
comes
out
of
like
the
vmware
group
of
hooks,
and
then
I
also
have
a
dapper
version.
Now.
This
readme
is
a
little
old
and
I
say
it's
old
because
if
you
come
here,
you
might
notice.
I
have
way
more
branches
than
I
showed,
and
one
of
the
reasons
is
because
if
you
look
at
some
of
these
things,
you'll
see,
I
have
a
dapper
and
a
dapper
sdk
branch
right.
C
So
this
one
just
uses
raw
http,
but
we
also
have
client
sdks
for
net
and
for
other
languages.
So
if
you
wanted
to
see
how
to
use
the
client
sdk
for
dotnet,
you
could
cuz,
you
know
you
could
switch
over
to
this
branch
and
you
can
kind
of
go
to
like
the
same
component
right.
So
let's
say
I
went
to
the
website
right
like
if
I
went
to
the
website.
I
click
on
services.
C
Instead,
I'm
using
dapper
clients
and
I'm
making
the
calls
instead,
but
like
look
at
how
much
smaller
the
code
is
right
like
these
are
pretty
much
all
one-liners
like
this
could
be
a
one-liner
right.
I
didn't
only
because
I
declared
a
variable,
you
know,
but
you
know
versus
being
four
lines
of
code.
There
could
be
one
line
of
code
right,
but
that's
that's.
That's
the
difference
that
we're
really
talking
about,
but
you
know
it's.
The
benefit
is.
C
If
you
want
to
use
your
http
client,
then
you
could
start
using
some
of
your
own
middleware
delegating
handlers,
any
other
investments
that
you
might
have
put
into
the
library
right.
So
someone
mentioned
poly
right
like
we
have
extensions
for
poly
off
of
http
client.
So
you
could
do
that
if
you
wanted
to
right
and
just
use
your
own
http
client,
but
if
you
don't
care
about
middleware
and
some
of
that
other
stuff,
then
totally
fine,
like
you
could
just
use
our
dapper
client
and
it'll
work.
C
E
Yeah,
I
would
say
this
was
pretty
phenomenal,
like
I've
been
kind
of
following
dapper
for
for
a
while
now
and
really
seeing
this
demo
with
the
explanations
of
how
each
of
the
individual
components
interact
and
all
the
extensibility
you
can
do.
I
kind
of
want
to
hop
into
this
like
right
after
this.
I
really
want
to
hop
into
this.
C
Yeah
dapper
is
really
fun.
If,
and
I
think
this
is
the
case
for
most
people,
but
I
could
be
wrong
if
you,
if
you
work
in
an
environment,
that
there's
multiple
programming
languages
right,
because
one
of
the
things
that
we
see
a
lot
in
the
dot
net
space,
there's
tons
of
actor
frameworks,
there's
tons
of
you
know,
distributed
distributed
systems
thing
the
messaging
frameworks
and
all
kinds
of
stuff
that
work
well
as
long
as
you're
writing.net
on
both
sides
right.
This
dapper
works.
C
Well
with
anything
you
know
some
of
the,
but
then
we
have
to
talk
about
like
what
the
drawbacks
is.
Drawbacks
are
right,
because
now
it's
like
okay,
I
have
multiple
languages,
but
like
now
you
know
I
might
be
losing
some
functionality
that
I
might
need
I'll
give
you
an
example,
because
I
think
it's
good
to
talk
about
the
good
and
the
bad
right.
I
I
you
know
I'd
be
remiss
if
I
come
on.
C
I
only
talk
about
the
good
stuff
if
you're
using
something
like
redis
as
an
example,
redis
does
more
than
just
key
value
right.
Redis
has
streams.
Redis
has
different
data
types
and
all
kinds
of
stuff
that
you
might
want
to
use.
So
then
it
might
make
sense
that
I
have
a
redis
sdk
inside
of
my
app,
and
I
just
use
that
as
like
a
hard
dependency.
C
C
Let
me
know
when
I
can
get
it
back
and
then
you
know
you
do
like
this.
Like
I'm
done,
you
know
what
I
mean.
So
it
depends
on
what
your
app
needs
right
like
do.
You
need
to
be
able
to
control
like
those
little
knobs
and
buttons
and
and
all
those
things
or
are
you
fine?
Just
you
know
kind
of
like
that
person
we
had
someone
talking
about
like
they're,
going
to
deconstruct
their
ruby
application.
C
C
My
products,
api
is
the
only
thing
in
here
that
has
a
dependency
and
that's
on
the
mongodb
driver,
and
I
want
it
in
there
because
I'm
running
certain
queries
for
data
that
I
need
to
be
able
to
specify
a
query
language
right.
Dapper
doesn't
support
query
languages,
you
see
what
I'm
saying,
but
it
does
do
insert
it
does
do
like
you
know
retrieval.
C
You
know
what
I
mean
so
again.
You
got
to
think
about
like
what
really
makes
sense
for
the
app
that
you're
trying
to
build.
So
for
me
that
makes
sense,
because
I
get
service
discovery
I
get
pub
sub,
but
then
I'm
still
gonna
like
use
my
database
package.
You
know
I'm
gonna
use
that
thing.
You
know
what
I
mean,
but
everything
else
I
can
let
dapper
use,
which
kind
of
goes
into
like
another
question.
C
A
lot
of
people
always
ask
I'm
trying
to
answer
questions
that
I
think
people
are
gonna
ask
before
I
disappear
a
lot
of
questions,
type
of
question
that
people
ask
are:
do
I
have
to
use
all
the
building
blocks?
No,
you
don't
have
to
at
all
like
you
could
just
use
whatever
you
feel
like
using.
You
know
what
I
mean.
So,
if
you
tell
me
hey,
I
only
want
to
use
pub
sub
and
you
know
I'm
going
to
figure
out
the
rest.
C
That's
fine
right
or
if
you
just
want
to
use
dapper
for
managing
secrets.
That's
fine!
You
know
it's!
It's
not
like
a
all
or
nothing
type
of
thing,
like
some
other
frameworks
might
be
use
the
parts
that
you
want,
use
the
parts
that
make
sense,
and
then
you
know
you
can
figure
out
what
you
want
to
do
for
the
other
things.
C
In
iis
you
can
run
it
next
to
ias,
because
dapper
is
a
process
right,
so
you
know
you
can
run
the
process
next
to
it
and
what
you
could
do
so
where's
my
thing:
let's
do
this,
I'm
gonna
pull
up
the
terminal.
So
let's
say
right.
I
have
dapper
installed
on
this
machine
right.
I'm
going
to
it's
that
big
enough
right,
sir.
I'm
going
to
assume
that's
big
enough.
Hopefully
that's
big
enough!
C
Some
executable
that
is
running
out,
but
when
iis
runs
is,
will
be
listening
on
port
80.
Right
so
is
will
be
you
know:
local
hosts,
80
right,
whatever,
whatever
it
is,
so
you
don't
run
dapper
in
is,
but
you
run
it
next
to
it.
So
you
can
always
just
say:
dapper
d,
you
know
app.
What's
it
called
dash
app
id
and
then
call
it
I
don't
know
is
whatever
you
want
to
call
it
right
and
then
I
could
say
dash
app
dash
ports
kitty
right.
C
So
now,
whenever
dapper
starts
it's
gonna
be
like
is
running
on
the
machine
in
its
own
process.
Dapper
is
running
next
to
is
its
own
process,
so
it
doesn't
matter
what
web
server
you
use
it
could
be.
Is
it
could
be?
Apache
could
be
whatever
you
know.
You
could
be
running
on
port
443.
If
you
want
to
and
using
you
know,
ssl
certificates
whatever,
like
whatever
port
you're
running
at
and
now
just
remember,
for
every
instance
of
the
application.
You're
gonna
have
another
instance
of
dapper
right.
C
I
guess
one
of
the
things
that
I'd
wonder
about
dapper
does
not
do
virtual
hosts,
so
you
know
like
you
can
hit
you
can
hit.
You
can
hit
iis
and
then
it'll
direct
to
a
virtual
directory
based
on
like
the
host
name
or
something
like
that.
I
don't
think
dapper
would
not
do
that,
like
that
bird
doesn't
have
awareness
to
know
about
virtual
hosts
within
web
servers.
You
know
what
I
mean.
C
C
C
That
way,
just
because
you
know
that's,
that's
how
marketing
sells
it
right,
like
marketing
across
the
industry,
sells
microservices
as
a
cloud
thing
and
something
that
I
need
someone
else
to
do
for
me,
and
it's
really
not
like
microservices,
is
more
so
around
like
patterns
and
practices.
So,
if
you
think
about,
maybe
you
do
run
iis
right
and
you
have.
Maybe
you
have
a
form
of
is
machines.
You
know
what
I
mean
next
to
those
is
machines
you
could
put
dapper
instances
next
to
all
of
those
and
that's
fine.
C
You
know
what
I
mean,
because
there
might
be
one
or
more
services
that
you
want
to
pull
out
of
that.
So
let's
say
your
is:
does
everything
except
pop
sub
right
and
so
now,
like
your
app,
can
call
through
dapper
to
get
pubs
up
and
it
could
funnel
out
to
outer
space
right
and
whatever
you
know
what
I
mean
pull
that
information
back
like
it
doesn't
really
matter
at
that
point,
so
you
can
run
it
on
your
machine.
You
can
run
it
on
premises.
You
can
run
it
in
containers.
C
D
C
Go
ahead,
no,
that's
it
windows,
mac!
Whatever
I
haven't,
tried
it
in
the
chromebook.
I
know
someone's
gonna.
Ask
me
about
chromebooks.
I
don't
know.
Okay,
I
don't
own
a
chromebook.
I've
never
tried
to
write
software
to
chromebook.
I
don't
know,
but
like
linux
mac
windows,
it
will
run
dapper
and
as
long
as
you
can
speak
accp
you
should
be
fine.
C
C
I
mean
you
could,
but
you
know,
it'll
be
problematic,
but
if
you
have
so
again,
if
you
look
at
the
kubernetes
analogy
of
a
pod
right
just
and
it
doesn't
have
to
be
kubernetes,
but
you
know
you
have
your
unit
of
deployment.
Is
your
app
and
your
sidecar
like
that
is
a
single
unit
of
deployment.
They're,
not
separate
things.
You
know
so
again.
If
I
have
10
instances
of
my
app,
I
have
10
side
cards
like
it's
a
one-to-one
relationship
throughout
the
board.
E
C
C
Our
grafana
stuff,
our
dapper
d
process,
anything
that
says
operator
is
kubernetes
things
for
folks
that
want
kubernetes
things.
Yeah
century
century
is
a
thing
I
think
century
is
what
generates
those
mtls
certificates.
So
those
certificates
are
generated
on
the
flag
for
you,
so
you
don't
have
to
do
certificate
management
they're,
like
generated
and
rotated
for
you,
which
is
great
but
yeah,.
C
Yeah
again,
I
think
the
thing
with
you
know
the
main
things
I
always
want
to
get
folks
out
with
dapper
is
any
programming
language
you
know
runs
on
any
host
and
just
use
the
pieces
that
you
want
right,
because
it's
about
flexibility
at
the
end
of
the
day,
you
don't
have
to
use
the
whole
thing.
You
don't
have
to
use
the
sdks.
If
you
don't
want
to
but
they're
there,
you
don't
have
to
run
it
in
kubernetes.
C
If
you
don't
want
to
because
a
lot
of
people
again
like
marketing
has
people
thinking
that
microservice
is
only
running
kubernetes.
That's
not
the
case.
You
could
run
them
on
your
own
machine
without
anything,
it's
fine!
It's
it's
about
choice
right
and
I
think
dapper
is
one
of
those
projects.
Why
I
like
the
opera
is:
what
is
project
that
gives
you
choice?
It's
not
vendor
locked
in.
It's,
not
azure
locked
in.
It's,
not
cloud
locked
in
it's,
not
virtual
machine
or
container
locked
in
run
it
wherever
you
want
use.
A
C
Again,
the
only
thing
I'd
say
is,
you
know,
download
it.
Try
it
out.
If
you
find
problems
submit
an
issue,
you
know,
if
you
have,
if
you
there's
anything,
you'd
want
to
see,
definitely
feel
free
to
message
me
on
twitter
or
reach
out
to
any
of
the
dapper
folks
there
on
twitter.
Also,
I
think
it's
up
here
somewhere
where's
that
thing
here.
It
is
well
yeah.
C
You
could
come
to
them,
you
could
you
know
the
team
is
looking
at
these
things
and
looking
at
community
feedback
and
whatever
is
going
on
so
yeah
definitely
feel
free
to
just
you
know,
like
don't
be
afraid
to
ask
questions.
I
guess
is
my
thing.
You
know
people,
people
get
scared,
sometimes
for
one
reason
or
the
other
don't
be
afraid
to
come
on
and
ask
questions.
A
Yeah
and
cecil
is
very
approachable.
You
know
I
just
all
I
had
to
do.
You're
like
man,
this
guy
see
on
the
dot
net,
show
you
know,
and
then
I
just
email
him
and
he's
like
sure
I'll.
Do
it
no
problem?
And
you
know
I
that
I
want
to
give
a
massive
thank
you
to
you
for
for
coming
out
and
speaking
with
us,
and
you
know
just
a
lot
of
people
being
on
the
receiving
end
of
and
needing
to
pay
it
forward.
A
You
know
you
just
you're
kind
of
sowing
the
future.
You
know-
and
I
have
a
very
special
place
in
my
heart
for
for
for
people
who
educate
and
you
know,
and
and
do
it
at
you
know
no
cost
for
people
and
just
just
do
it
for
for
the
love
of
devs
and
and
students
learning.
So
thank
you
very
much
for
for
coming
out.
C
Yeah,
thank
you
for
having
me
really
appreciate
it.
I
mean
I
come
back
as
long
as
the
time
works
out
like
you
know,
I'd
come
back
and
we
could
talk
about
some
other
topics.
If
you
want,
you
know,
we
could
talk
messaging,
we
could
talk
micro
apis
with
net.
That's
going
to
be
a
new
thing
that
people
are
playing
around
with.
That
could
be
interesting.
We
could
talk
azure
service,
bus
or
you
know
anything
of
this
sort,
whatever
whatever
folks
are
interested
in
learning
about-
and
I
know
about
that-
I
can
come
back.