►
From YouTube: Extend Your Microservices With Pluggable Components Via Dapr - Artur Souza & Yaron Schneider
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Extend Your Microservices With Pluggable Components Via Dapr - Artur Souza, Microsoft & Yaron Schneider, Diagrid
Speakers: Artur Souza, Yaron Schneider
The Distributed Application Runtime (Dapr) provides APIs that simplify microservice connectivity. Dapr is a portable, serverless, event-driven runtime that makes it easy for developers to build resilient, stateless and stateful microservices that run on the cloud and edge and embraces the diversity of languages and developer frameworks. Dapr codifies the best practices for building microservice applications into open, independent, building blocks that enable you to build portable applications with the language and framework of your choice. Each building block is configured via components in Dapr. Dapr components required to be written in Go and built into the runtime binary, limiting the set the services that can be used via Dapr. This session will show how microservices can now use Dapr building blocks with their own components, written in any language and take advantage of the Dapr runtime capabilities.
A
And
today
we're
going
to
talk
to
you
about
a
few
updates
that
we've
been
seeing
for
the
Dapper
project
that
we'd
like
to
share
with
the
broader
community
and
everyone,
and
also
talk
about
pluggable
components
in
the
upper
which
were
recently
introduced
in
adapter
1.9
and
before
we
go
into
all
the
details.
I
really
want
to
thank
our
amazing
Community
contributors
who
really
helped
Drive
plugable
components
into
Dapper.
A
So
thank
you
to
all
of
our
amazing
contributors,
and
so
let's
talk
a
little
bit
about
what
Dapper
is
and
what
Dapper
does
as
a
another
application,
developer
writing
a
distributed
system
or
a
micro
service
architecture
on
top
of
kubernetes
or
anywhere.
Really,
you
might
be
writing
something
like
this
right.
You
might
have
a
bunch
of
services
that
communicate
with
each
other.
They
might
have
a
queue
or
a
database.
They're
writing
to
you
might
have
a
secret
story
configuration
store.
A
You
know
the
underlying
infrastructure
for
all
of
your
applications
and
it
looks
simple
on
the
surface,
but
when
you
get
into
the
nitty-gritty
details
of
it,
there
are
many
many
distributed
systems
challenges
that
developers
have
to
solve
each
and
every
day,
really
with
every
new
feature.
Also,
so
things
like,
how
do
you
do
State
Management
from
multiple
replicas
writing
to
the
same
record?
How
do
you
do
conflict
management
at
scale?
How
do
you
do
error,
handling
and
fault
resiliency?
When
you
talk
to
your
message,
bus?
A
How
do
you
delay
messages
being
sent
over
an
event-driven
system?
How
do
you
secure
messages
not
just
between
your
service
to
service
calls,
but
to
your
database
and
encrypt
those
connections
and
rotate
these
keys,
so
so
lots
of
these
distributed
systems
challenges
are
meeting
developers
and
as
complexity
Rises.
A
But
some
things
you
can
see
here
are
service
to
service
invocation,
which
is
a
way
to
find
discover
and
secure.
Communication
calls
State
Management,
which
allow
you
to
save
State
and
get
state
in
a
reliable
way,
Pub
sub,
which
allows
you
to
very
easily
create
event
driven
system
without
all
the
boilerplate
code
and
issues
associated
with
it
resource
bindings,
which
is
a
way
to
trigger
your
application
based
on
events
coming
in
from
external
systems.
Act.
This
is
a
very
specific
programming
model
that
distributes
compute
and
state
at
a
high
granular
rate.
A
Observability
and
secrets
are
ways
to
basically
observe
everything.
That's
going
on
in
Dapper,
because
Dapper
is
at
the
intersection
of
all
of
your
application,
Communications
that
were
basically
observed,
everything
for
you,
whether
it
reverses
services
to
service
calls
or
whether
it's
coming
in
from
something
like
copper,
AWS
sqs,
without
you
as
a
developer,
needing
to
take
any
sdks
and
defenses
into
your
code,
and
these
apis
are
being
added
by
the
community
at
a
very
active
pace.
And
of
course,
Dapper
is
not
only
tied
to
kubernetes.
A
So
really
adapter
doesn't
have
your
Lifting
for
you,
and
this
is
how
you
use
the
operator
to
have
your
application
process
the
Dapper
process.
It's
called
overheated
pure
grpc,
and
these
are
a
bunch
of
examples
of
how,
for
example,
you
would
use
the
app
or
to
discover
a
different
application
wherever
it's
running
just
by
its
name
and
invoke
a
method
or
get
some
state
or
publish
a
message
to
the
orders
topic
or
get
a
secret
from
some
Secret
store
called
Apple.
A
So
as
a
developer,
you
get
these
consistent
apis
and
Dapper
basically
make
sure
that
everything's
secure,
reliable
and
traceable
under
the
hoods.
So
at
this
point
you
might
think
well,
this
Dapper
replace
State
Stores
or
Pub
sub.
Well,
the
answer
is
no.
It
doesn't
integrate
with
over
105
components
that
represents
the
majority
of
services
that
you
will
find
in
clouds
like
AWS,
Google
cloud
and
Azure,
and
also
open
source
ones.
So
these
are
just
a
few
here
on
the
right,
but
Dapper
has
a
very
extensible
model
to
it.
A
A
All
of
these
components
were
contributed
by
our
amazing
community,
so
that
really
integrates
so
as
a
developer.
You
let
your
developers,
talk
to
it
very
consistent
and
portable
API,
but
as
an
operator
infrastructure
person,
you
can
decide
what
the
underlying
implementation
is
based
on
the
environment
that
you're
running
in
and
it's
basically
a
yaml
swap.
A
A
This
is
an
update
for
the
community
traction
that
we're
seeing
dapper
today
is
the
ninth
largest
project
in
cncf,
based
on
the
report.
It
was
released
by
cncf
a
month
ago.
I
think
it
was
we're
seeing
lots
of
amazing
companies
contributing
to
the
project
yeah.
We
have
over
2
200
computers
contributors
today
and
our
Discord
Community
is
growing.
Please
join
us
after
the
talk
it'd
be
great
to
get
your
thoughts
and
feedback
on
the
project,
so
this
is
really
how
Dapper
components
are
plugged
into
our
runtime
today.
A
So
we
have
the
Dapper
binary
Dappers
written
in
go,
which
means
that
every
time
you
want
to
add
a
binary.
Oh
sorry,
a
component
to
the
Dapper
binary.
You
need
to
go
to
our
repository.
You
need
to
basically
write
the
implementation
and
go.
It
has
to
be
go
because
the
app
is
written
and
go.
We
will
accept
the
pr
we'll
approve
it,
we'll
lgtm
it
and
then,
when
the
next
version
of
dapper
ships
it'll
get
compiled
into
the
Dapper
binary
and
that's
where
we
have
over
100
different
components.
A
But
many
organizations
actually
need
to
extend
Dapper
for
adapter
to
be
able
to
talk
to
systems
that
are
proprietary
to
their
own
organizations
or
if
they
have
some
kind
of
business
logic,
that's
an
IEP
to
their
company
and
they
can't
actually
contribute
it
Upstream.
So
this
is
a
use
case
that
we're
seeing
more
and
more
of,
and
today
it's
very
difficult,
adding
these
private
components
before
version
1.9,
so
you
would
have
to
Fork
the
main
Dapper
repository
you
would
need
to
force
the
components.
Contribute
repository,
get
those
local
versions.
A
You
need
to
write
your
custom
component
and
go
which
means,
if
you're
an
organization
that
doesn't
have
knowledge
and
go.
You
need
to
learn,
go
it's
I,
love!
Go
it's
my
favorite
language!
No,
that's
not
true
anymore.
Typescript
is
now
favorite
language,
but
my
second
favorite
one
especially
for
back-end
stuff,
and
you
know
you
need
to
become
an
expert
in
it.
A
Although
it's
it's
kind
of
easy,
but
you
still
need
to
learn,
go
which
is
a
major
hurdle
for
many
organization
and
then
once
you
have
your
components
set
up,
you
basically
need
to
integrate
it
into
Dapper,
build
your
custom
binary.
If
you're
building
a
custom
container,
you
need
to
go
to
the
adapter
settings
and
basically
pull
off
your
version
of
the
image.
So
this
is
the
the
configuration
of
the
environment
really
so
it's
kind
of
a
convoluted
process,
but
now
in
1.9
we
have
the
concept
of
plugable
components.
A
So
you
can
write
a
component
in
any
language
that
supports
grpc,
and
then
you
just
need
to
package
that
into
a
container
or
a
process
depending
on
whether
or
not
you're
running
Dapper
in
a
containerized
environment
or
not,
and
then
you
just
deploy
your
application
code,
so
this
has
become
comes
really
easy.
The
core
design
settings
for
us
are,
of
course,
to
be
securing
performance,
so
we
use
Unix
domain
sockets.
A
So
you
can't
invoke
these
components
from
outside
of
your
local
network
namespace,
whether
you
know
it's,
your
VM
or
a
pod
on
kubernetes
we're
leveraging
RPC
standards.
So
there's
no
new
RPC
framework
here
we're
just
leveraging
Google
grpc,
which
is
fully
supported,
no
limitations
there
on
any
grpc
features.
There
is
very
low
operational
overhead
because
we
are
leveraging
existing
Dapper
crds.
A
So
if
you're
familiar
with
the
concept
of
crd,
it's
basically
a
kubernetes
resource
that
allows
you
to
extend
kubernetes
and
many
projects
that
you
will
find
that
basically
Deploy
on
top
of
kubernetes
have
10
20
30.
Some
of
them
even
have
80
crds,
and
that
adds
a
lot
of
operational
overhead
in
dapper.
Today
we
have
four
crds,
and
so
we
did
not
add
a
new
one
to
add
plugable
components,
we're
basically
raising
our
same
component
CBD
and
then
it's
platform
agnostic.
A
We
make
sure
that
everything
we
do
in
Dapper
is
compliant
both
to
kubernetes
and
kubernetes,
and
so
yes,
bugable
components
run
inside
Fitness
and
outside
of
it.
Something
we
ruled
out
was
used,
go
plugins
because
it
requires
the
use
of
sigo
and
one
of
the
founders
and
creators
of
the
go
project.
We
go
around
time
basically
said
that
seago
is
not
go.
If
you,
if
you
Google
sigo,
is
not
go,
you
will
find
the
the
article.
A
That
explains
why
I'm
not
going
to
go
into
details
here,
but
it's
basically
causing
lots
of
cross
compilation
issues
with
basically
be
telling
everyone
this
developer
out
there.
No,
you
can't
really,
you
know,
run
pluggable
components
locally
or
on
Windows
machines
and
there's
low
performance.
So
it
takes
the
performance
here
and
then
there
is
also
some
dependency
Management
in
your
host
processing,
the
plugin.
A
If
you
have,
if
you're
referencing
other
packages,
they
must
have
the
same
version
and
that
creates
version
and
conflict
management,
and
that
becomes
a
real
issue
and
then,
of
course,
yeah
the
language
support
they
talked
about
earlier.
So
this
is
the
user
experience.
Basically,
this
is
80
of
user
experience.
So
this
is
what
a
component
crd
in
Dapper
would
look
like.
A
You
have
the
type
there
which
is
State
mydb,
that's
a
custom,
pluggable
component
I,
don't
know
if
you
know
how
Dapper
series
look
like
we
probably
should
have
put
an
image
here,
but
it
would
basically
change
type
state.mydb
to
something
like
state.aws.sqs.
If
this
was
a
component,
that's
built
into
Dapper
that
you
get
with
the
Dapper,
stable
release,
and
so
just
by
putting
State
money
to
be
here,
we'll
basically
telling
the
upper
hey.
This
is
my
own
custom
component
and
you
can
have
your
own
metadata,
which
really
targets
whatever
underlying
system.
A
You
might
be
writing
this
component
for
and
we
use
a
domain
socket,
so
we
adapter.
Basically
the
Dapper
runtime
looks
at
the
local
file
system,
it
searches
for
a
local
domain
socket
and
then
it
basically
looks
for
other
processes
should
registered
to
it,
which
would
be
the
plugable
components,
and
this
is
really
what
it
looks
like.
So
you
have
the
Dapper
D
binary
here
on
the
left,
and
there
is
a
discovery
mechanism
which
will
basically
listen
to
sockets
on
the
file
system,
and
this
file
system
can
be
mounted
on
kubernetes.
A
It
can
be
an
in-memory
file
system
too,
by
the
way,
and
then
you
have
the
plugable
component
process,
which
is
a
totally
separate
process
to
the
Dapper
D1.
It
can
be
a
separate
container
inside
of
your
deployment
or,
if
you're
running
Dapper
outside
of
kubernetes.
It
can
just
be
a
process
co-located
inside
of
your
VM,
and
the
important
thing
is
that
they
both
have
access
to
the
mounted
file
system
that
you're
giving
it
so
that
the
app
can
basically
discover
these
plugable
components.
A
Once
the
Opera
has
discovered
the
socket
in
the
public,
one
has
listened
to
the
socket.
They
will
basically
connect
and
the
pluggable
components
will
connect
to
Dapper
via
jrpc.
So
Dapper
will
basically
use
grp3
reflection,
The
Jerk
reflection,
API
to
talk
to
the
components
and
discover
all
of
its
different
properties
and
make
sure
that
you
know
it's
actually
a
Dapper
plug,
build
component
to
it.
Now,
just
something
that's
not
compliant
to
the
interface,
the
adapter
expense.
A
So
this
is
basically
how
it
works
and
adding
private
components
now
in
in
Standalone
mode
is
very
simple.
You
basically
just
give
your
a
plugable
component,
the
the
Unix
domain
socket
path.
You
can
see
it
here
at
Unix,
temp,
Dapper,
component,
socket
and,
and
then
the
component
will
basically
just
listen
on
the
grpc
socket
there
pretty
simple.
This
is
how
it
would
look
like
in
kubernetes,
not
certainly
not
in
kubernetes.
This
is
what
the
Dapper
d
site
will
show
once
it
discovered
a
plugable
component
and
successfully
register
it.
A
So
that's
the
lining
right
there.
The
line
at
the
top
base
is
basically
a
Dapper
CLI
command.
We
have
developer
tooling.
Adapter
will
take
basically
your
application.
The
upper
side
can
run
it
together
and
Dapper
will
successfully
register
the
plugable
component
if
it
was
able
to
Discover
It
by
a
geography.
Reflection,
as
I've
mentioned
earlier.
A
Adding
components
in
kubernetes
looks
like
this.
So
the
way
to
inject
Dapper
into
your
deployment
yaml
is
basically
annotated
with
a
bunch
of
annotations
which
you
can
see
on
the
bottom.
There
you
go.
The
upper
I
o
enable
true,
which
means
the
upper
hey.
Wants
you
to
inject
the
upper
side
car
using
your
mutating
web
hook,
and
then
you,
you
have
all
other
every
other
annotation
that
you
can
think
of
like
an
app
ID
to
give
your
application
ID
and
app
port
and
the
very
last
one
at
the
bottom.
A
Is
the
Unix
domain
socket
path?
So
inside
of
your
application,
you
will
Mount
volume
which
will
be
used
to
host
the
socket
that
both
the
pluggable
component
and
damp
releasing
on.
So
it's
a
it's,
a
very
nice
user
experience
inside
of
your
deployment.
Yaml,
that's
something!
That's
a
little
less
nice,
but
we're
working
on
improving
that
experience.
A
That's
what
you
would
need
to
do
on
your
deployment
side.
You
of
course,
have
your
plug
glue
components,
you're
built
into
a
Docker
image.
You
pushed
it
into
registry
and
so
you're,
adding
it
as
an
additional
container
inside
of
your
deployments
back
inside
of
your
pod
spec,
so
you're
mounting
the
volume,
it's
all
pretty
easy
stuff
standard
here,
nothing
special
that
you
need
to
do.
A
B
B
A
B
B
If
you
don't
have
one,
and
you
can
also
use
to
install
the
grpc
tool
for
local
certification
and
as
a
model
that
dependencies
here
depends
on
which
part
of
the
game
I'm
going
to
take,
so
I
have
checked
out
the
code
already
and
then
there's
existing
code
for
the
mem
store.
So
the
same
example
that
we
saw
on
the
slide,
there's
some
Echo
going
on
here,
where
we'll
just
simply
do
a
dyna
run,
but
before
we
do
that,
let's
look
at
the
code.
So,
oh,
let
me
zoom
in
one
more
time
there
you
go!
B
So
if
I,
look
at
our
plugable
components,
folder
you're
going
to
see
the
mem
store,
which
is
basically
a
grpc
service.
In.Net
program.cs
basically
handle
the
socket.
So
in
this
case,
we're
going
to
put
the
socket
in
slash
DMP
handle
the
socket
creation
and
then
we're
going
to
configure
the
socket
with
adding
the
grpc
listening
and
in
this
we
also
need
the
grpc
reflection.
B
B
We
are
writing
new
sdks
for
the
upper
to
compose
components
so
now
you're
not
only
going
to
have
sdks
to
use
the
adapter
apis,
but
we're
also
writing
sdks
for
you
to
make
it
very
easy
for
you
to
write
any
component
in
the
languages
in
most
popular
languages
that
we
have,
which
are
DOT
net
Java,
Python
and
go.
These
are
the
sdks
that
are
going
to
come
up
and
now
we're
going
to
look
at
show
you
how
the
service
is
implemented,
so
the
main
store
implements.
A
Sorry
I
will
just
go
ahead.
Just
one
comment
there,
although
we
are
writing
these
sdks
to
make
it
easier
for
you
to
write
plugable
components,
it's
important
for
me
to
call
out
that
you
can
write
them
in
any
language,
even
without
the
sdks.
You
just
need
to
do
a
little
bit
of
grpc
Plumbing,
which
is
isn't
really
a
problematic
yeah.
B
Thanks
for
the
call
out,
so
these
are
the
interface
that
you're
going
to
implement
based
on
the
grpc
service.
You're
offering
and
you
can
do
like
the
get
to
get
a
key
set
just
had
a
key
bulk
set-
should
have
handle
a
bulk
request
in
it.
So
init
method
is
the
one
that
the
sidecar
will
invoke,
passing
the
metadata
that
yeah
I
don't
show
previously
on
the
slide.
So
all
those
metadata
attributes
is
per
component.
B
Some
components
like
the
mem
store,
for
example,
that
I'm
implemented,
doesn't
require
any
metadata
attribute,
but
you
could
pass
like
a
URL.
You
could
even
pass
a
secret
if
you
want,
and
you
use
a
secret
reference,
a
feature
that
adapter
has,
if
you're
not
familiar
with,
that,
I
recommend
taking
a
look
later
and,
of
course,
paying
for
the
health
check
of
your
components.
So
with
that
we
can
go
to
the
folder
plugable
components.
B
B
There
we
go
one
thing:
I'm
going
to
show
is
I'm
going
to
show
that
in
the
in
the
Dapper
CLI
install
the
folder
for
you
with
components,
and
we
change
the
name,
store
yaml
file
to
handle
the
memory
store.
So,
like
you
can
see
it's
as
simple
as
that
it
doesn't
require
any
metadata
and
in
this
case,
you're
not
going
to
be
using
radius.
We're
going
to
use
be
using
the
name
store.
Okay.
B
B
There
you
go
and
I'm
just
gonna.
Do
npm
install
actually
I've
done
this
before,
but
it
should
be
fast
and
then
we're
going
to
be
able
to
run
the
node.js
application.
So
the
node.js
application,
if
you
haven't
seen
this
example
before
all
it
does,
is
receive
the
call
from
the
python
application
that
we're
going
to
run
in
a
minute
and
save
that
state.
Your
Stage
store
as
simple
as
that
so
I'm.
B
C
A
E
A
Arthur
is
showing
right
now
or
two
applications
of
python
app,
invoking
a
node.js
app
through
the
apparent,
so
it's
invoking
with
Dapper
directly,
and
so
you
get
empty
lots
of
their
ability
to
empty
all
the
Dapper
features
and
that
no
depth
is
going
to
get
that
request
from
the
python
now
through
the
upper
I'm
going
to
save
it
to
the
state
store,
which
is
the
custom
plugable
component
sensor,
which
isn't
compiled
in
the
Dapper
bundle.
Yeah.
B
So
in
this
example,
I
did
not
end
up
running
the
python
by
the
way,
but
I
did
use.
The
adapter
invoke
feature
to
make
the
invocation,
and
you
can
see
here
that
this
date
was
saved.
God
New,
Order,
there
you
go
and
the
save
was
persisted.
So
now,
let's
look
at
a
more
cool
demo.
This
is
just
for
you
to
get
started
on
local
development.
B
So,
if
you
have
seeing
the
Twitter
processing
demo
in
the
past
they're
multiple
demos
online,
you
can
see
that
it
basically
uses
damper
with
the
Twitter
input
binding
to
receive
tweets.
You
make
a
service
invocation
to
the
sentiment
processor
to
the
settlement
analysis
annotate,
the
payload,
with
that
extra
information
saves
to
your
Stage
store,
publishes
to
a
pub
sub
topic
and
there's
another
application
with
a
dashboard
that
consumes
those
tweets
with
the
sentiment,
analysis,
results
and
displays
on
the
dashboard,
okay,
and
so
we're
going
to
do
this.
B
We
did
them
it's
already
running,
but
I'm
going
to
go
through
some
of
the
steps
with
you
guys.
So
there's
also
a
time
if
you
want
to
interact
to
download
to
connect
to
our
Discord
server
for
the
demo.
So
if
you
have
Discord
I'll
give
you
a
few
minutes.
So
what
we
did
is
we
took
the
Twitter
binding
and
we
wrote
a
custom
component
in
Java
that
will
instead
take
messages
from
Discord.
B
B
B
B
B
B
B
B
B
B
So
let's
open
this
code
a
little
bit,
so
the
server
does
the
same
thing:
that's
the.net,
equivalent
where
it
basically
manages
the
socket
for
you
like
how
do
you
start
this
on
the
socket,
how
it
change
the
permission
to
make
sure
another
process
can
read
and
write
to
it.
So
so
this
code
is
what
we
think
it
should
belong
in
a
in
a
SDK
that
makes
things
easier
for
you
because
there's
nothing
specific
for
us
to
handle
here.
B
But
then
the
core
of
the
code
is
actually
in
the
Discord
bind
implementation
where
you
basically
have
they
knit
that
we
discussed,
and
in
this
example
we
do
get
a
token
so
I'm
going
to
show
the
yellow
in
a
minute.
So
we
do
actually
get
the
token
to
connect
to
Discord
through
the
metadata
and
it's
not
hard
coded
at
all,
but
you
still
get
it
here
for
in
your
in
your
code.
So
and
then
we
start
the
client
and
then
we
respond
to
the
message.
B
We
also
have
the
pink
and
we
also
had
the
Reed.
So
the
Reed
we
basically
start
in
this
case
is
using
the
Discord
SDK
behind
the
scenes.
I
don't
even
know
if
this
is
a
girl.
Maybe
there
is
but
yeah
I
think
so
and
then
we're
gonna
keep
forwarding
the
messages
to
build
a
lot
to
make
sure
it's
working
and
then
we're
going
to
create
a
payload
following
the
same
structure
as
a
Twitter
binding
was
working
before
to
make
sure
we
keep
the
compatibility.
B
So
it's
a
plugable,
so
we
can
remove
one
and
put
the
other
one
in
place
with
no
code
change
in
the
rest
of
the
code
and
then
those
messages
are
going
to
be
sent
in
the
response
Observer.
So
this
is
how
we
wrote
a
binding
component
in
Java
and
I'm
going
to
show
you
in
a
moment
right
now.
How
does
the
component
actually
look
like?
B
The
mem
store
example,
you
can
run
a
kubernetes
as
well
if
you
want
a
simpler,
easier
way
to
to
get
this
working.
So
as
you
can
see,
we
have
the
metadata.
It
has
the
token-
and
this
is
a
nice
feature
that
Dapper
has
and
for
those
are
not
familiar
with,
that.
Vapor
has
a
secret
store
and
our
components
are
integrated.
B
Natively
with
that,
and
also
in
this
case
I'm
using
the
kubernetes
secret
itself,
and
you
can
see
how
I
reference
that
without
having
to
hard
code
the
token
on
my
demo,
so
you
can
there's
the
examples
of
how
to
get
this
core
token.
If
you
want
to
do
this
yourself,
but
that's
how
we
manage
secrets
in
the
upper
the
configuration
I
added-
and
you
is
a
new
feature
here,
but
it's
a
different,
a
different
conversation,
the
processor.
B
The
provider
is
the
one
that
we
actually
use
the
plugable
component
and
like
like,
we
saw
on
kubernetes,
it
has
the
crystal
image,
but
it
has
also
the
domain
socket
path
and
it
has
the
container
for
the
provider
and
the
container
for
this
cord,
and
you
can
use
this
image
just
as
well
from
Docker
Hub.
This
is
the
image
I
built
with
this
same
code
and
then
Pub
sub
has
no
difference.
B
A
D
A
So
I'll
start
with
the
Positive
questions,
so
your
question
was
whether
the
merits
of
the
pub
sub
API
yeah
so
many
times
you
would
want
to
create
an
Avenger
of
an
architecture
where
you
publish
a
message,
and
these
Publishers
are
decoupled
from
subscribers
and
it's
very
hard
to
create
on
your
own,
because
if
you
have
multiple
subscribers,
even
multiple
Publishers,
you
need
to
basically
handle
scale.
You
know
how
do
you
handle
error,
handling
or
throttling
from
the
publisher
every
subscriber?
A
You
need
to
start
learning
about
consumer
groups
and
partitions
and
how
you
listen
on
these
and
handle.
You
know
errors
and
faults
coming
in
from
these
Concepts,
and
so
dap
really
encapsulates
all
of
that,
for
you,
it
creates
consumer
groups,
creates
partitions,
it
configures
them.
The
only
thing
you
need
to
do
as
a
publisher
is
just
preach.
B
That
that
depends
on
the
component,
so
that's
a
configuration
that
you
can
have
in
your
radius
or
Azure
service
bus,
but
damper
can
also
add
a
feature
on
top,
which
is
a
message
TTL
that
optionally,
you
can
put
a
metadata
parameter
to
say.
Oh,
this
message
is
in
the
queue
only
for
let's
say
one
day
and
then
the
double
side
card
that
consumes
that
we
understand
that
and
they'll
send
that
to
the
application,
and
you
can
also
bundle
that
feature
with
that
letter.
Q
I
have.