►
From YouTube: wasmCloud Community Meeting - 29 March 2023
Description
Welcome to the wasmCloud community! Tune in live where we discuss the latest developments in the wasmCloud ecosystem, WebAssembly standards, and break out sweet demos.
Agendas for wasmCloud community meetings can be found at: https://wasmcloud.com/community
A
All
right,
hello,
everyone
welcome
to
the
wasmcloud
Wednesday
Community
stream
on
Wednesday
March
29th.
We've
got
a
pretty
fun
agenda
today
should
be
a
lot
of
great
discussion,
I'm
going
to
go
ahead
and
start
off
just
by
sharing.
You
know
what
I'm
gonna
go
ahead
and
share
my
whole
screen,
because
I'm
gonna
need
to
do
that.
Anyways
so
go
ahead
and
get
some
stuff
moved
around.
So
here
is
the
agenda.
For
today
this
is
still
kind
of
in
our
staging
environment.
A
So
we're
going
to
merge
all
this
into
the
main
website
here
shortly
after
the
meeting,
but
I
actually
have
a
demo
for
you
of
a
a
similar
example
to
wasm
Cloud's
KV
counter,
but
using
webassembly
components
and
running
in
version
62
of
the
wasm
cloud
host.
We're
gonna
have
a
long
discussion
on
the
implications
of
what
components
mean
for
the
Watson
Cloud
ecosystem
and
I've
kind
of
broken
this
out
into
a
couple
of
different
sections
to
encourage
discussion
around
actors
capability
providers,
language
support
all
those
things,
but
this
should
be
a
pretty
fun
discussion.
A
Please
feel
free
to
jump
in
and
ask
questions
and
then,
after
that,
Kevin
is
going
to
give
a
demo
of
cosmonic's
latest
open
source
project
concordance,
which
is
an
open
source
framework
for
building
events
for
systems
with
wasm
Cloud.
So
super
excited
for
that
without
further
Ado
go
ahead
and
get
started.
So
not
everybody
was
lucky
enough
to
go
to
the
wasmio
conference
last
last
week
times
weird,
including
myself,
was,
was
unfortunately
not
able
to
go,
and
so
I
didn't
get
to
see.
A
Bailey's
super
awesome
demo
where
she
showed
a
webassembly
components,
working
in
Wallace
and
cloud,
and
so
I
want
to
bring
that
super
fun
demo
to
you
today.
So
just
to
give
you
an
idea
of
what
this
looks
like
from
the
wasm
cloud
perspective.
A
Webassembly
components
are
mainly
going
to
impact
actors
in
the
short
term
and
the
way
that
this
works
is
when,
when
you're
running
webassembly
modules
within
wasm
Cloud,
you
are
essentially
creating
one
bit
or
this
this
bundle
of
of
a
webassembly
module
that
includes
on
both
ends
our
framework
of
laws
and
bus
RPC.
This
is
how
we
kind
of
do
type
translation,
serialization
and
so
that,
when
you
actually
program
your
actor
you're
doing
it
in
terms
of
the
common
contracts
for
key
value
or
for
messaging,
or
things
like
that.
A
Now,
the
webassembly
component
model
and
I'll
touch
pretty
briefly
on
this
I
I'd
be
happy
to
answer
a
couple
of
questions,
but
essentially
all
of
these
common
contracts
with
the
webassembly
component
model.
This
allows
you
to
compose
different
webassembly
modules,
together
with
a
common
interface
to
talk
between
them,
including
like
interface
types.
You
know
more
than
just
numbers
and
you
can
actually
compose
these
webassembly
modules
into
a
single
webassembly
module.
We've
been
calling
a
fused
component
to
actually
form
your
your
application.
A
A
The
way
that
this
will
work
in
the-
and
this
is
you
know,
labeled
future,
mostly
just
because
you
know
not
that
it's
there
just
because
actually
getting
the
formal
support
for
for
stability
like
nyz,
Preview
2
is
going
to
take
just
a
little
bit
longer.
The
way
that
this
is
going
to
work
is,
you
would
have
a
different
web
assembly
components
based
on
the
Wazi
Cloud
interfaces
very
similar
to
wasm
Cloud
interfaces.
A
It's
just
contributed
to
the
standard
and
implemented
in
the
webassembly
system
interface
standard,
so
we
have
httpserver.wasm
which
implements
those
common
types
for
an
HTTP
server,
key
value.wasm,
and
then
we
would
actually
provide
you
know
something
like
a
wasm
bus
sender
that
does
the
translation
for
wasm
cloud.
So
we
can
send
your
request
off
onto
the
lattice.
It
can
be
handled
by
any
component
on
any
system,
all
the
things
we
do
for
distributed,
and
then
the
actual
piece
of
logic
that
you
would
write
would
just
be
the
small
KV
counter,
webassembly
module.
A
A
A
I
want
to
show
you
kind
of
a
concrete
example
of
what
this
works
with
I'm
I'm,
actually
just
going
to
be
following
some
of
the
steps
that
Bailey
did
for
her
demo
and
I'm,
going
to
kind
of
stitch
together
an
actor
a
wasmcloud
factor,
but
with
the
webassembly
component
model,
so
I'm
working
out
of
her
repository,
the
wasmio
2023
I.
Don't
have
a
link
to
it
now,
but
we
might
be
able
to
get
that
here
in
the
in
the
zoom
chat.
A
If
I
go
over
to
the
let's
see,
where
am
I
right
now
so
I'm,
just
in
a
little
demo
directory,
if
I
go
in
here
and
go
into
the
ping
pong
directory,
this
is
the
actual
development
of
a
webassembly
component
called
ping
pong.
It
takes
a
message
in
over
a
Nats
message,
bus
or
it
takes
a
message
in
over
the
messaging
Wazi
Cloud
contract
and
then
interacts
with
a
key
Value
Store
using
the
Wazee
key
value
contract.
A
The
code
here
is,
of
course,
likely
to
change.
This
is
all
kind
of
put
together
in
the
name
of
the
demo
and
so
like
the
kind
of
abstraction
that
you
get
from
like
wasm
Cloud
sdks
was,
is
soon
to
come,
but
we're
using
the
wit
binding
to
generate
the
interfaces
for
this
webassembly
module
and
then
we're
doing
things
like
creating
a
messaging
broker
and
then
based
on
the
message
that
comes
in
we're
specifically
going
to
be
listening
for
Ping.
We
return
a
pong
and
we
end
up
doing
a
key
value.
Increment
call.
A
So
all
this
is
very
like
base
SDK
e.
A
lot
of
this
is
going
to
be
abstracted
into
the
kind
of
a
similar
model
that
we
do
for
wazum
cloud
now,
but
it's
going
to
be
all
Wazi
Cloud
specific.
But
the
real
point
is
here
all
the
interfaces
here
are
not
wasm,
Cloud,
specific
and
you're
just
still
able
to
work
in
your
business.
A
Logic
Let,
Me
zoom
in
just
a
little
bit,
so
you
can
build
this
using
cargo,
build
you
compile
to
Wazi,
which
is
just
the
other
web
assembly,
Target
other
than
Watson
32
on
no
and
unknown.
And
then
we
use
a
pretty
it's
a
it's
a
longer
command.
But
you
essentially
take
this
webassembly
module
and
migrate
it
to
a
webassembly
component,
which
is
in
the
preview
2
format,
and
once
we
do
that,
we
can
take
a
look
at
the
wit.
A
So
in
order
to
actually
get
this,
what
I'm
calling
a
fuse
component
to
like
build
these
components
in
together?
So
actually
this
super
cool
tool
called
wasm,
Builder
and
I'm.
Sorry
I'm
forgetting
exactly
who
put
this
together,
but
this
was
an
awesome
tool
that
also
was
shown
off
at
the
wazam
io
conference.
I
can
actually
add
a
couple
of
components
and
let
me
go
ahead
and
pull
this
up.
Oh
yeah,
that
was
right.
A
I
can
add
a
few
components
and
actually
Stitch
this
together,
like
in
a
UI,
so
in
components
we
have
the
let's
start
with
the
Wuzzy
ones.
We
have
the
key
value
Wazi
component
and
then
we
have
the
messaging
component.
A
A
This
is
the
wasm
cloud
actor
specific
functionality
in
order
to
get
this
to
work
within
within
wasm
cloud,
and
just
note
for
the
purposes
of
the
demo
that
I'm
following
through
this
readme,
that
this
is
like
all
of
the
base
steps
and
like
stitching
it
together
with
a
UI
for
for
fun,
but
certainly
what
our
goal
is
to
have
the
tooling
very,
very
similar
to
the
way
that
you
do
it
now
or
you
just
run
wash
build,
build
an
actor
Liam.
B
Got
your
hand
up,
you
have
a
question:
Peter
hewan
over
at
fastly,
develop
this
tool
and
if
you
are
visiting
wasbuilder.app
in
the
top
right,
you'll
see
that
there
is
a
GitHub
link
and
it'll.
Take
you
right
to
the
Repository
I'm,
just
FYI,
for
anyone
watching
the
call
now
or
later.
A
Yeah,
thank
you
so
much
Liam
I
should
have
pulled
that
up
ahead
of
time.
So
let
me
show
you
what
this
looks
like
to.
Actually,
this
is
such
a
such
a
fun
tool.
We
can
drag
these
components
onto
the
onto
the
little
canvas
here
and
I'm
just
going
to
kind
of
organize
things
here.
So
what
we
have
the
parts
that
are
making
up
this
actor
are
now
our
ping
pong
component,
which
is
just
the
pure
business
logic.
A
You
know
what
you
as
a
developer,
are
going
to
write
for
for
actually
running
your
application.
A
So
we
hook
up
messaging
to
messaging
types
and
producer,
because
master
is
going
to
be
producing
those
messages.
We
hook
up
the
key
value
component
to
the
ping
pong
component
and
then
on
the
other
end.
I
think
we
have
Handler
go
to
handle
I,
always
reference
back
here
to
make
sure
I'm
doing
it
right.
A
Aha,
so
messaging
also
goes
to
messaging
types
for
the
wasmcloud
actor
and
Handler
is
an
export
that
is
imported
by
the
WASP
Cloud
actor
component.
So
this
composability,
when
when
done
manually,
can
be
a
little
could
be
a
little
verbose,
but
all
this
is
essentially
going
to
be
done
by
automatic,
tooling,
which
is
pretty
neat
and
then
last
thing
we
do
is
we
just
say:
hey
I
need
to
export
this
actor's
exports,
so
the
wasm
cloud
environment
is
going
to
to
import
them.
A
Can
see
here
that
it
has
a
couple
of
imports
from
the
host
and
then
this
one
actor
export,
which
is
what
was
Some
Cloud,
is
going
to
import
on
the
other
end
very
kind
of
webassembly,
primitive,
Style
I
can't
see
the
chat
so
feel
free
to
just
raise
your
hand
if
you
have
a
question
right
now,
all
right
so
now
that
we're
done
with
that,
what
we
can
do
is
I
can
actually
grab
this
fuse
component
that
we've
made,
and
here
it
is
I'm
gonna,
move
this
to
a
more
convenient
location,
so
we
can
actually
operate
on
it
and
then
just
rename
it
really
quick.
A
So
we
have
our
fused
ping
pong
webassembly
component.
This
is
pure
wasm.
It
is
has
nothing
wasm
specific
yet,
but,
as
you
know,
in
wasm
Cloud
we
actually
require
you
to
sign
your
webassembly
modules,
with
the
claims,
the
capabilities
that
it's
going
to
make
use
of
at
runtime,
and
so
what
I
can
do
is
I
can
I
have
my
fuse
ping
pong
component
I
can
sign
that
component
with
the
key
value
capability,
the
Wazi
messaging
capability,
and
then
the
you
know
I
can
give
it
a
name.
A
I'll
call
it
like
immunity,
all
ping
pong,
something
like
that
and
then
so
now
we
have
an
actual
laws
and
Cloud
actor
Let's
see
we
have
an
actual,
was
and
Cloud
actor.
That's
that's
signed
with
our
with
a
private
and
public
key
pair,
and
then
we
have
its
capabilities
and
essentially
the
reason
why
we're
doing
all
of
this
on
top
of
the
component
model
is
that
these
capabilities
that
you're
going
to
invoke
it
could
be
anywhere
in
the
lattice.
A
It
could
be
distributed
across
a
number
of
different
machines,
and
now
this
this
webassembly
component,
that
was
built,
is
able
to
do
things
in
wasm
Cloud
that
we're
used
to
with
actors
just
all
with
the
standard
interfaces.
So
let's
go
ahead
and
make
this
work
so
I'm
going
to
go
ahead
and
launch
wash
I'm
going
to
do
it
with
a
couple
extra
I.
A
Don't
need
to
do
that
all
right,
I'll
go
ahead
and
launch
wash
I'll
do
wash
up
to
get
wasn't
Cloud
running
and
then,
as
soon
as
that
launches,
we
can
actually
come
in
and
grab
our
webassembly
module.
So
this
fused
ping
pong
is
the
one
that
I've
built
and
then
we
can
start
the
Wazi
messaging
Nats
provider
and
then
I'm
just
going
to
start
our
standard,
wasmcloud,
KV,
redis,
KV,
redis,
store
and
I
think
I
still
have
redis
running
yep.
A
A
And
as
soon
as
we
send
that
ping,
we
get
a
response
on
pong,
which
is
actually
the
of
it's
It's
formatted
like
a
cloud
event.
But
it's
a
message
coming
from
inside
of
that
webassembly
module
that
is
built
with
Blossom
components
and
so
I
know
that
this
demo
is
very
like
stitching
things
together,
building
things
with
components,
because
it's
so
early
days.
We're
really
proud
to
have
an
actual
implementation
based
off
of
this.
A
But
it's
really
all
coming
back
from
this
to
this
future
goal
of
we're
going
to
be
taking
away
the
wasm
Cloud
interfaces
that
we
build
and
you
specifically
depend
on
to
build
actors
and
replace
them
with
the
web
assembly
standard
wit
interfaces
for
Wazi
cloud,
and
this
is
going
to
be
really
awesome
from
the
perspective
of
building
actors,
because
you
can
actually
build
webassembly
modules
with
components
and
then
bring
them
to
awesome
Cloud
without
needing
to
change
that
that's
kind
of
all
stitched
together
by
the
Watson
Cloud
host
and
then
there's
a
there's,
a
couple
more
Implement
implications
in
terms
of
our
ecosystem,
but
I'm
going
to
go
ahead
and
pause
now
after
the
demo.
A
C
Get
it
I
promise
I'm,
not
an
audience
plant.
This
is
a
genuine
question.
How
much
of
the
manual
stitching
together
that
you're
doing
through
this
demo
is
going
to
go
away
over
time
as
more
and
more
tooling
becomes
available
for
things
like
the
component
model.
A
Yeah,
this
is
a
great
question
that
I
probably
don't
have
the
the
best
answer
to,
but
the
way
that
I
see
it
is
that
essentially,
all
of
the
stitching
together
that
I'm
doing
manually
is
going
to
be
abstracted
away
by
tooling
the
same
way
that
you
don't
have
to
stitch
together.
A
Individual
interfaces,
the
way
that
I
see
it
is
that
you
would
create
your
webassembly,
your
webassembly
module
and
then
essentially,
declare
and
and
build
in
the
Wazi
Cloud
interfaces
that
you
want
to
take
advantage
of,
and
then
those
individual
components
are
automatically
pulled
down
built
into
your
webassembly
module.
And
then
you
you
go
from
there,
so
essentially
how
you
run
cargo
build,
that's
all
kind
of
included,
Roman
I!
A
D
Yeah
especially
more
details,
so
essentially
we
would
have
this
tooling,
which
could
provide
this
compatibility
layer
for
wasn't
Cloud
right
on
both
sides.
But
what
I'm
working
on
right
now
is
actually
removing
the
need
for
any
of
these
adapters
on
these
sides,
so
basically
supporting
both
models
where
you
do
have
an
adapter
or
when
you
just
have
an
off-the-shelf
component,
which
you
may
not
even
have
written.
It
has
nothing
to
do
with
watching
Cloud
at
all
and
you
simply
sign
it,
and
then
you
can
run
it
in
the
new
host.
D
So
you
don't
actually
need
to
do
anything
any
of
the
stitching
at
all,
because
all
these
interfaces
are
standard
right,
but
is
there
implications
to
the
both
approaches
right?
But
it's
always
going
to
be,
for
example,.
A
For
performance,
so
it
would
be
better
to
use
the
interfaces
directly
rather
than
through
the
quantum
Cloud
apis,
but
for
some
purposes
you
may
want
to
do
that.
So
it's
it's
a
pros
and
cons
everywhere,
so
Roman
just
to
maybe
rehash
that
one.
So
essentially,
you
would
build
your
webassembly
component
using
like
the
language
standard.
A
Tooling,
like
cargo
component
build
or
you
know,
you
may
need
to
install
Watson
tools
or
something
like
that,
but
cargo
component
build
or
like
tiny
go
build,
and
then
all
you
would
have
to
do
is
the
regular
step
that
you
do
for
Watson
Cloud,
which
is
signing
it
and
then
it's
it's
ready
to
go.
D
Yes
will
be
one
one
vector
how
you
could
get
stuff
into
one
Cloud.
You
could
be
different
vectors
right
and
potentially
you
could
even
be
backwards
compatible
with
what
we
have
today
and
one
of
the
reasons
why,
for
example,
could
be
this
way
that
we
can
also
benefit
from
everything
Happening
by
code
Alliance
like,
for
example,
what
the
HTTP
is
something
currently
being
implemented
again
itself,
so
a
lot
of
functionality
for
outgoing
and
incoming
connections.
All
that
could
just
benefit
from
you
know:
Community
contribute
code
lines
thing.
A
Okay,
super
cool.
Let's
see
I
saw
there
was
a
question
in
the
chat,
but
Oren
I
think
you
actually
won.
With
your
your
hand,
if
you
want
to
go.
E
Sir,
would
you
declare
these
dependencies
in
cargo
Tomo
exactly
or
somewhere
else.
A
I
think
they
actually
end
up
coming
in
in
the
webassembly
module
itself
like
at
the
top
of
the.
Let
me
share
my
screen
really
quick
here
at
the
top
of
the
webassembly
module
itself.
We
say:
hey
generate
these
interfaces
based
on
this
wit
file
and
in
the
world
ping
pong,
and
so
the
the
wit
file
actually
has
the
standard
interfaces
in
there
Roman.
What's
that?
Yes,.
D
So
I'm
actually
working
on
removing
the
need
for
any
of
the
width
interfaces
in
your
actual
actor
I'm,
not
sure
if
it's
not
going
to
work
yet
to
get
today,
but
with
punching
functionality,
but
so
far
it
seems
like
we
should
be
able
to
just
have
a
simple
remote
create
like
we
have
already
these
interfaces
different
traits
right,
so
you
would
just
import
from
that's
great
and
just
yeah
implement
the
interface.
So
you
wouldn't
actually
need
to
write
any
width
or
depend
a
little
bit
pinetail
directly.
C
I
think
just
to
put
another
way
when
we're
working
with
components,
your
your
cargo
Tomlin
never
actually
depends
on
another
component.
You
depend
on
the
interface
or
the
contract,
and
so
there's
never
actually
any
tightly
coupled
dependencies.
What
Roman
was
talking
about,
where
you
know,
there's
a
crate
that
you
can
depend
on
it's,
that's
basically
a
convenience
and
a
way
to
simplify
things,
but
the
the
underlying
principle
is
that
the
component
model
frees
us
from
tightly
coupled
dependencies,
which
is
has
a
much
bigger
impact
than
most
people.
B
E
D
Yeah,
so
basically
there
are
so
the
way.
The
time
designed
today
right
you
could
you
could
Define
anybody.
You
would
want
right,
so
you
could
just
have
the
switch
directory
with
your
with
interfaces
right
next
to
your
actor
and
just
run
that
wasn't
cloud
or
you
could
import.
Basically,
those
interface
already
generated
into
a
nice
thrust
code
from
our
crates
right,
which
I'm
going
to
be
you've,
got
the
same
interfaces
right
or
maybe
there's
some
other
page.
You
can
import
with
with
some
functionality,
but
basically
somewhere.
D
Something
is
going
to
call
with
wind
with
by
gen,
to
generate
those
bindings
for
rust,
for
example,
or
go
or
whatever
else
you
use,
and
then
you
import
those
rust
bindings
from
whatever
that's
kind
of
the
idea.
Much.
A
Yeah,
just
as
a
general
note,
I
feel
like
in
wasm
cloud,
and
we
can
touch
on
language
support
a
little
bit
later.
I
would
have
a
soft
preference
for
declaring
if
we're
looking
for
a
standard
way
to
do
it
across
different
languages,
maybe
declaring
it
you
know
in
inside
of
the
code
or
just
like,
not
in
the
cargo.com
specific
format.
A
F
Taylor
yeah
something
I
want
to
point
out
here
too
and
I
know.
I've
talked
to
Rowan
about
this
before
is
the
ideal
future
and
not
what
we're
at
right
now,
but
the
ideal
future
is
that
you
just
you
grab
the
interfaces
you
want
to
use.
You
use
the
whip,
binding
stuff
that
he's
talking
about
with
whatever
language
you're
in
and
then
we
just
take
your
component
automatically
glue
everything
together
for
you
that's
further
out,
but
like
that's,
the
ideal
is
that
these
things
can
be
swapped
anywhere.
F
That
has
the
exact
same
interfaces
so
right
now
we
do
some
composition
outside,
because
that's
just
the
easiest
and
best
way
to
do
it
right
now
in
the
future
I
imagine
we
can
get
to
a
better
state
of
of
that,
and
that's
what
we're
hoping
for,
but
right
now
what's
been
described,
is
how
it
works.
A
D
Yeah,
so
one
really
cool
thing
here
is
that,
because
there
are
things
already
implemented
watching
time,
for
example
the
random
number
generation
right.
So
we
can
actually
wrap
the
this
standards.
What
the
random
interface
and
the
Implement,
for
example
the
Rand
RNG
trade,
and
now
you
can
just
use
all
the
functionality
provided
by
the
rent
crate
using
Wazi
random.
We
shouldn't
the
house
didn't
even
have
to
implement,
because
all
that
was
already
provided
by
it
wasn't
time
underneath
or
it
could
be
provided
by
hosts
as
well
right.
So
there
are
possible,
are
possible.
A
It's
really
cool,
well,
I
I,
think
everybody
you
can
expect
from
this
phase
is
that
getting
a
working
POC
is
really
exciting
and
the
newly
coming
wasn't
Cloud
version
62,
which
we're
about
to
cut
another
release
candidate
for
later
today
has
active
working
support
for
webassembly
components.
A
The
the
remainder
of
the
work
here
really
comes
from
the
the
rest
of
the
wasm
cloud
ecosystem,
so
just
showing
something
that
works
is
is
really
the
first
step
and
is
really
exciting,
but
I
want
to
be
candid
talking
about
some
of
the
things
that
are
planning
to
change
over
the
next
next
couple
of
months.
Wazi
Preview
2
is
planned
with
with
webassembly
components
as
planned
to
fully
stable
release.
I
I
believe
in
the
fall.
I
will
need
Bailey's,
not
here.
A
It's
usually
our
my
marker
for
for
real
deadlines,
but
that's
the
last
thing
I
remember,
but
we
essentially
have
that
future
flash
turned
on
in
wasm
Cloud.
So
it's
it's
working
now
talking
about
what
changes
in
the
wasm
cloud
ecosystem
call
out,
specifically
that
it's
going
to
be
a
a
period
of
time
where
we're
taking
all
of
our
examples
that
are
built
with
Smithy
interfaces
and
wasmcloud
sdks
and
we'll
essentially
migrate
those
to
be
using
webassembly
components.
Instead
from
the
perspective
of
anybody
who's
consuming
these
examples,
it
doesn't
really
change
anything.
A
A
This
actually
should
be
even
lower
friction
than
the
way
that
we
build
planes
today.
So
it's
it's
all
an
improvement
in
terms
of
the
capability
providers
themselves.
We
have
big
plans
for
where
we
want
to
move
with
capability
providers,
but
for
now,
they'll
still
be
built
as
native
binaries.
That
just
interact
the
same
way
with
a
webassembly
component
as
they
did
with
you
know,
essentially
the
the
freestanding
actor
and
when
I
say
webassembly
component
I
mean
a
wasmcloud
actor
but
built
with
components
in
terms
of
wasm
cloud
host,
there's
not
really
much
more.
A
That
needs
to
change
Watson
Cloud
hosts
for
at
least
for
the
amount
of
time
that
we
can
foresee
are
going
to
support
backwards,
compatible
mode
of
running
actors
that
are
built
with
the
current
tooling
and
wasmcloud
interfaces
and
actors
that
are
built
with
webassembly
components.
A
It's
just
the
way
that
they're
stitched
together
the
inputs
and
outputs
are
still
essentially
the
same,
so
at
least
for
the
time
being,
don't
expect
any
huge
breaking
changes
for
the
actors
that
currently
exist
if
you've
written
those,
those
or
webassembly
actors
for
awesome,
Cloud
right
now,
it's
worth
noting
that
there
will
likely
be
especially
on
our
road
to
1.0
with
wasmcloud.
There
will
likely
be
a
point
where
we
segment
and
ask
everybody
to
build
their
new
webassembly
modules
with
components.
A
I
think
that
that
is
a
pretty
natural
step,
especially
adopting
the
standards,
but
I
want
to
mention
that
all
the
changes
that
we're
going
to
require
we're
going
to
try
to
support
backwards,
compatible
things
as
long
as
possible,
and
this
is
a
migration
speaking
truly
selfishly,
where
we
have
an
entire
backend
built
on
wasmcloud
at
cosmonic
like
we
have
to
do
this
same
migration
too.
So
we're
you
know
making
this
as
simple
as
possible
is
really
the
goal
foreign.
A
A
If
you
choose
so
for
wasm
cloud
for
the
wasm
cloud,
specific
components
that
we'll
publish
we'll,
probably
write
them
in
Rust
now
or
you
know,
continue
writing
them
in
Rust,
but
bringing
in
these
standard
interfaces
and
being
able
to
use
wit
binding,
actually
really
opens
the
door
for
us
to
expand
language
support
with
wasm
cloud
and
we've
held
off
on
this
for
a
good
while
due
to
the
effort
that
it
takes
to
write
Cogen
for
a
language
and
continue
to
handle
that
in
in
a
good
way.
A
A
So
that's
really
exciting.
It's
all
kind
of
a
all,
a
community
effort
which
we're
really
excited
about,
and
we
may
end
up
even
contributing
some
of
those
Cogen
libraries
based
on.
If
we
wanted
to
add
a
specific
language,
we
have
experience,
doing
tiny,
go
so
I
think
actually
musaka
on
the
on
the
Deus
lab
side
at
Microsoft
has
worked
on
the
tiny
go
with
bungen
already
and
gotten
that
so
all
that's
all
that's
really
exciting.
A
It's
all.
All
of
this
is
really
meant
to
say
that
there
are
some
really
cool
changes
coming
into
the
wasmcloud
ecosystem.
That
will
really
help
with
our
mission
of
decoupling
business
logic,
letting
you
write
the
language
of
your
choice
and
we'll
be
essentially
updating
you
in
slack,
slash
on
the
community
call
every
week
on
on
our
progress,
probably
start
a
little
blog
series
too
on
on
getting
this
done.
B
Brooks,
let
me
just
ask
this
another
way:
is
it
accurate
to
say
that
for
the
languages
that
support
components,
there's
a
JavaScript
tool
out
of
Shopify
there's
a
rust
component
tool
that
those
languages
are
Now
supported?
On
top
of
the
next
version
of
Bosman
cloud.
A
That's
that's
my
understanding,
I
I
think
that
there
will
always
be
a
couple
things
that
we're
going
to
want
to
run
tests
for
like
before
we
say
boom.
We
have
JavaScript
component
support,
we're
going
to
want
to
build
something
with
JavaScript
components
and
and
take
a
look,
but
that's
the
beauty
of
composing
components,
the
the
language
that
you're
building
it
in
kind
of
sits
in
the
middle
of
of
what
interfaces
with
the
outside
world.
It's
really.
B
Cool,
this
really
seems
like
a
flattening
technology.
If
you
look
at
what
folks
have
been
doing
for
the
last,
you
know,
six
months
is
runtime
specific
language
sdks,
and
it
feels
like
all
that
just
goes
right
away
and
everybody
just
starts
to
Interchange
components
which
is
stupid,
powerful
yeah,
super,
exciting.
A
All
right,
I
did
a
good
good
bit
of
talking
there.
We
do
have
another
exciting
demo
for
the
for
the
second
third.
Third.
Third,
second,
third
of
this
of
this
call
any
quick
questions
on
on
that
stuff.
Before
we
move
on.
A
We'll
continue
to
stall
long
enough
to
give
Evan
co-host
all
right,
then
we'll
we'll
kind
of
wrap
up
that
component
section
as
usual
feel
free
to
drop
more
more
questions
in
the
the
comments
or
or
into
slack.
We'll
obviously
continue
to
talk
about
this,
but
Kevin
I
won't
won't
spoil
anything,
go
ahead
and
take
it
away.
C
All
right,
let's
see
if
I,
can
share
it
without
breaking
anything.
Let's
see
here
all
right,
I'm
assuming
you're.
Looking
at
my
at
a
GitHub
page.
C
All
right,
so
a
little
bit
of
background
before
I
start
getting
into
the
the
details.
C
I
think
it's
important
to
remember
that
wasn't
cloud
is
more
than
just
an
application
deployment
Target,
it's
a
foundation
that
you
can
use
to
build
other
products
or
other
Frameworks,
and
as
Brooks
mentioned
you
know,
the
the
entire
cosmonic
back
end
runs
on
wasmcloud,
and
so
one
of
the
things
that
we
built
in
on
cosmonic
in
order
to
make
that
happen
is
and
event
sourcing
framework,
and
so
we
we
refer
to
this
as
an
opinionated
event
sourcing
framework.
C
So
there
are
some
lines
that
we
draw
in
the
sand
that
we
won't
violate
and
there
are
some
extra
rules
in
there
and
I've
got.
One
of
my
favorite
quotes
here
on
the
page,
which
is
constraints
liberate
and
Liberty's
constraint.
This
is
sort
of
the
The
Guiding
philosophy
behind
some
of
the
opinions
that
are
baked
into
this
framework.
C
As
a
as
a
quick
recap
in
case,
people
aren't
really
all
that
familiar
with
what
event
sourcing
is
or
why
you
might
want
to
do
it
an
event.
Source
application
is
an
application
where
it's
States
is
a
derivation
of
events
that
have
occurred
in
the
past
so
put
in
other
ways.
C
It's
basically
applying
functions
across
an
event
stream
and
the
components
that
sit
inside
an
event
sourced
application
are
aggregates
which
represents
instances
of
entities
and
when
I,
say
entity
here,
I'm
referring
closely
to
the
domain-driven
design,
definition
of
entity
Aggregates
receive
commands,
they
validate
the
commands
and
then
in
response.
They
emit
events
to
the
event
stream.
C
They
handle
incoming
events
and
that's
what
is
used
to
modify
the
internal
aggregate
State
and
in
the
sample
I'm
going
to
show
I'll
illustrate
how
that
applies
to
things
like
maintaining
a
bank
account
Ledger
in
a
in
a
banking
app
another
element,
another
building
block
of
event.
Sourcing
applications
is
a
projector.
C
Another
element
that
I
I'm
not
going
to
talk
about
too
much
here
is
a
process
manager
process
managers
are
the
things
that
coordinate
long-running
processes
in
an
event
sourced
application
and
in
the
bank
account
example.
That's
we
use
an
interbank
transfer
which
requires
multiple
commands
in
multiple
events
to
finish
and
then
finally,
there
are
generic
or
stateless
event
handlers.
So
these
are
the
things
that
you
use
to
perform
your
application.
C
I
o
so
things
that
you
might
use
to
take
an
event
out
of
your
Event
Source
system
and
convert
that
into
an
email
that
gets
sent
to
a
customer
and
so
on
and
all
of
these
components
I'm
going
to
be
discussing
at
my
upcoming
kubecon
presentation,
where
I'm
going
to
talk
about
event,
sourcing
and
then
also
get
into
more
detail
on
the
concordance
framework
that
I'm
talking
about
now.
C
So
I
can't
tell
if
there
are
any
questions
right
now,
but
I'll
keep
going.
Can
you
see
the
the
tab
that
I
just
switched
to
the
Verizon
cloud?
Dashboard
Yep
looks
good,
so
this
is
what
it
might
look
like
if
you
had
a
small
application
running
using
concordance.
So
we
have
the
various
components
that
represent
the
the
fundamental
building
blocks
of
an
MS
of
an
event
source
application.
So
I
have
a
bank
account
projector,
that's
responsible
for
building
the
balance
as
well
as
The
Ledger
I.
C
Have
a
transfer
process
manager
that,
like
I
mentioned
a
few
minutes
ago,
that
does
long-running
bank
transfer
processes
and
then
finally,
I
have
the
bank
account
aggregate
which
is
responsible
for
validating
commands
and
then
emitting
events
and
you'll
see
that
the
aggregate
does
things
like
make
sure
that
if
the
command
is
to
withdraw
two
hundred
dollars,
that
you
have
at
least
two
hundred
dollars
in
your
bank
account
and
there's
a
whole
bunch
of
stuff
that
I
could
go
into
maybe
after
the
demo
on.
C
C
And
look
here:
okay,
I'm
sharing
a
tab
in
my
terminal.
Can
everybody
see
what
it
looks
like
so
I'm
in
a
directory
called
Scripts
yep
that
looks
good?
Okay,
wow!
That's
I
actually
got
the
the
spinning
beach
ball,
trying
to
zoom
in
so
that's
weird,
so
I
have
this
application
running
and
our
concordance
provider
runs
on
top
of
nats,
so
you'll
see
that
the
our
durable
event
stream
is
based
on
Nats
jet
stream
and
the
Aggregate
and
process
manager
state
are
managed
as
Nets
key
value
buckets.
C
So
all
of
this
event,
sourcing
stuff
sits
on
top
of
Nets.
So
if
you're
using
wasm
Cloud,
you
basically
are
already
you
already
have
Nets
or
for
free.
So
there's
there's
no
extra
infrastructure
that
you
need
for
this
in
the
demo
that
I'm
running
the
bank
account
projector
is
using
redis
so
just
to
show
that
it's
still,
even
though
we're
in
an
application
framework
like
concordance,
we
still
have
a.
C
C
So,
in
an
event,
source
application,
what
you
would
normally
do
is
no
concordance
is
open.
Source
I
was
on
the
the
GitHub
page
for
it
a
second
ago,
I'll
make
sure
that
we
drop
some
links
in
there
in
the
chat
later.
C
So
this
is
all
open
source.
Let's
see
where
was
I
I
have
I'm
trying
to
remember
where
I
was
here
so.
C
Yeah,
so
we
would
normally
feed
commands
into
an
Event
Source
domain
or
application,
so
in
a
bank
account
demo.
C
C
It's
going
to
spit
out
the
corresponding
events,
and
then
the
projector
will
deal
with
creating
all
of
the
views
that
I
need,
and
this
typically
goes
by
pretty
fast,
so
there
I
just
ran
I
just
dumped
in
those
four
commands
and
I've
used
Nats
to
query
the
value
of
this
particular
key
value
bucket,
which
is
the
aggregate
State,
and
so
you
can
see
that
my
aggregate
has
a
balance
of
six
six
thousand
and
then
here's
some
of
the
other
details
on
the
account
and
you
can
see
how
that
all
took
place.
C
So
I
have
two
streams,
commands
and
events
commands
is
input.
Events
is
sort
of
the
internal
flow
and
commands
is
a
work
dispatch.
So
as
soon
as
a
command
is
processed,
it
disappears
from
the
stream,
but
because
event
sourcing
is
based
on
a
durable
and
immutable
event.
Log,
we
don't
remove
events,
so
I
can
actually
View
foreign.
C
The
events
that
are
in
my
stream-
and
these
are
Cloud
events
in
Json
format,
so
everything
in
this
stream
is
not
only
you
know
something
that
developers
can
read
but
is
also
processable
by
anything
that
can
read
Json
and
these
days.
That's
pretty
much
everything.
C
C
And
you
saw
the
aggregate
State
contain
the
the
aggregate
state
contains
the
current
balance
and
everything
that
the
aggregate
needs
to
validate
incoming
commands,
but,
like
I
mentioned,
we
also
need
to
be
able
to
provide
consumers
so
whether
that's
an
API
or
a
UI
client
or
something
else,
it
needs
to
be
able
to
access
the
read
model,
and
so,
in
this
case
the
read
model
is
in
redstone,
so
pay
no
attention
to
the
counters.
Those
are
from
our
other
KD
counter
sample.
C
That
I
think
everybody
in
cosmonic
probably
has
KV
counters
running
on
their
machines
at
all
times.
So
if
I
just
want
the
balance
of
my
account,
which
is
a
pretty
common
query
and
I
want
to
be
able
to
retrieve
that
in
Big
O
one
time
so
fixed
cost.
So
you
can
see
that
my
balance
is
six
thousand,
but
I
can
also
do
assuming
this
works.
C
C
So
you
know,
like
I,
said:
I,
don't
have
to
do
a
SQL
join
and
I'm
not
going
to
demo
it
right
now,
because
you
know
it's
a
little
dangerous
I
haven't
tried
it
yet
is.
If
I
wanted
to
do
replay,
what
I
would
do
is
I
would
delete
one
of
these
consumers
and
then
add
it
back
and
then
what
would
happen
is
one
of
is
the
concordance
capability
provider.
C
Would
you
know,
pull
that
data,
and
since
it
was
a
new
consumer,
it
would
point
at
the
beginning,
so
it
would
essentially
just
rerun
all
of
those
events
into
that
aggregate
or
projector
or
whatever.
C
So
I
would
use
that
if
I
needed
to
change
the
internal
state
of
an
Aggregate
and
blow
away
the
state
and
replay
from
the
beginning
by
if
I
decided
to
change
how
I'm
generating
this
Ledger
format
blow
away
the
state
replay
from
the
beginning
and
I'm
good
to
go,
and
you
know
the
replay
is
also
how
we
can
do
things
like
disaster
recovery
and
so
on.
C
Stop
sharing
here
and
then
I'm
gonna
see
if
I
can
share
my
vs
code.
So
you
can
see
what
an
actual
what
a
Event
Source
component
looks
like.
C
C
So
what
you
can
see
here
is
in
the
projector
is
I've
got
apply,
stateless
event,
which
is
part
of
the
contract
and
then
I
do
a
big
match
on
the
event
type,
and
you
see
here
I'm
going
to
a
comment
where
in
phase
two,
which
is
after
kubecon,
instead
of
having
to
build
the
match
statement
myself,
the
code
will
generate
the
internal
match
statement
and
all
I
have
to
do
is
supply
a
strongly
typed
event
application
function,
so
all
of
the
serialization
and
stuff
would
be
taken
care
of
for
me,
but
for
now
I
have
to
do
a
match,
and
so
inside
the
store
you
know
to
to
generate
these
read
models.
C
All
I'm
really
doing
is
using
the
pre-existing,
was
and
Cloud
key
value,
contract
and
so
I'm.
You
know,
writing
an
account,
Ledger
and
writing
a
balance,
which
is
where
do
I
put
the
balance
here,
but
there's
the
balance.
I
just
do
a
key
value
set
on
the
balance
key
with
the
new
data
and
there
we
go.
So
there
are
a
couple
of
really
interesting
points.
C
Process
managers
take
in
events
and
emit
commands,
Aggregates
take
in
commands
and
events,
animate
events,
and
so
those
things
are
what
you
might
call
purely
functional
or
just
pure,
and
then
the
side
effects
are
all
explicitly
managed
in
the
special
stateless,
handers
handlers
called
either
projectors
or
notifiers
or
gateways,
and
all
of
the
plumbing
for
this
is
managed
for
you.
So
what's
another
interesting
part
about
this,
is
that
if
you
build
your
application
using
concordance?
C
For
now
this
is
all
still
in
experimental
mode
and
then
after
kubecon
I'm
going
to
be
converting
the
experimental
stuff
into
less
experimental
stuff,
and
so
it'll
have
more
more
focused
on
a
smooth
and
ergonomic
developer,
experience
better
documentation,
better
tooling,
we're
thinking
about
integrating
with
the
wash
command
line
and
so
on,
and
that's
all
I've
got
for
now
trying
to
get
in
there
under
the
two
o'clock
line,
yeah
Taylor
I
think
was
up
first.
F
Yeah
I
just
wanted
to
point
out
here
something
that
that
Kevin
kind
of
mentioned,
but
it's
kind
of
really
critical
here,
especially
for
anyone
watching
the
stream
and
wondering
why
this
really
matters,
even
if
you're,
even
if
you
don't
care
about
event
sourcing.
F
This
is
exactly
why
we
love
wasn't
cloud
and
why
we're
so
why
we've
all
been
dedicated
this
project
for
so
long,
you'll
notice.
This
isn't
like
a
Faz
solution
or
serverless.
This
isn't
like
entirely
like
robust
used
in
production
architecture.
In
addition
to
the
other
ones,
we've
shown
you
like
microservice
type,
architectures
and
more
monolith.
Type
applications
like
this
is
all
done
like
this
is
an
actual
full-like
event.
F
Sourcing
thing
done
inside
of
wazen
cloud:
that's
not
something
you're
able
to
do
with
the
with
a
lot
of
things
and
what
and
with
webassembly
right
now
is
anything
more
than
that
kind
of
functions
as
a
service
type
of
thing.
So
I
just
want
to
point
out
like
this
is
really
dialing
in
and
showing
like.
You
can
build
all
sorts
of
architectures
on
top
of
web
on
top
of
awesome,
Cloud
right
now,.
E
Yeah,
do
it
I
have
a
few,
but
I
don't
know
if
you
want
to
like
plan
around
the
time
more
so
than
my
questions.
I
could
ask
them
like
something.
That's
some
other
place.
A
We'll
we'll
still
plan
to
to
end
off
here
it's
two
now,
if
you
wanted
to
fire
one
off
and
then
we
can
continue
the
discussion
in
slack,
let's,
let's
go
with
that.
Just
to
respect
everybody's
time.
A
Okay,
yeah
I'll
go
ahead
and
do
that
well,
thank
you,
everybody
for
coming
to
the
stream
today,
Kevin,
the
only
thing
I
was
going
to
say
was
my
hand
up
is
really
like
I
really
look
forward
to
the
some
of
the
documentation
around
this
and
like
comparing
how
you
may
build
this
bank
account
model
without
event,
sourcing
and
with
event
sourcing
celium,
but
this
is
really
cool
thanks
everybody
for
for
coming
today,
we'll
pick
up
next
week
with
more
exciting
stuff.
I'm
gonna
stop
the
stream,
but
we
can.