►
From YouTube: What architecture you should know - Jozi.js July
Description
Join us online 🌍 for a discussion on 'what architecture you should know'. We're going to keep it simple to start, covering what we consider three of the essential architectural patterns for JavaScript developers. Bring your questions, comments and insights.
Agenda:
• 18:30 - Introduction
• 18:45 - Model View Controller (old school is cool)
• 19:00 - Flux pattern (flow data, flow)
• 19:15 - Event-based (pub-sub-what now)
• 19:30 - End
Speakers:
• Ruddy Riba
• Sheena O'Connell
• Lucky Nkosi
• Ryan Kotzen
• Gergana Young
• Mike Geyser
💛 Our Code of Conduct https://docs.google.com/document/d/1j-OfcTwYejEj-WiQq9F9AcVv2L-Ki81RuhFTjquDJyk/edit?usp=sharing
A
A
So
we
have
a
code
of
conduct
and
by
watching
this,
I
suppose
not
by
watching
it,
but
by
communicating
the
chat
and
on
a
meetup
page.
We
expect
you
to
be
nice,
be
respectful
and
constructive
with
one
another
to
work
together,
because
we're
all
here
in
a
common
cause,
I'm
pleased
to
respect
other
people's
space
and
not
be
spammy.
A
If
there
are
any
other
violations
of
code
of
conduct
that
you
think
you
see,
please
feel
free
to
contact
any
of
us.
You
can
do
so
on
meetup
or
via
here.
We
have
to
thank
our
sponsors.
We
couldn't
do
this
without
them.
So
thank
you
very
much
to
innocent
enes,
our
stream
sponsor
and
microsoft,
who
sponsors
our
meetup
page
and
we're
a
part
of
the
tech
community
which
we
appreciate.
A
Thank
you
so
today
we're
here
to
talk
about
architectural
patterns
that
we
think
you
should
know
which
is
really
broad,
and
I
suppose
the
first
thing
we
need
to
ask
about
is
like
well.
What
is
this
thing
that
we're
going
to
talk
about?
What
is
architecture
even
and
it
is
really
ambiguous
and
poorly
defined?
A
Is
the
stuff
that's
hard
to
change
and
I
think
that's
a
really
simple
rubric
to
figure
out
which
parts
of
your
code
is
architecture
and
which
is
not
what
we're
going
to
be
talking
about
tonight
is
mostly
lived
experience
and
you're
not
going
to
find
any
kind
of
book
architecture
here.
So
don't
expect
that
because,
as
we
all
know,
the
collective
noun
for
architects
is
an
argument
of
architects
and
hopefully
we'll
keep
that
to
a
bare
minimum
and
all
of
our
conversation
will
be
constructed
tonight.
A
So
we
thought,
discussed
and
thought
long
and
hard
about
which
architectural
patterns
we
think
are
like
the
three
that
we
can
cover
really
really
quickly
that
are
relevant.
That
are
basically
the
essentials
and
not
all
of
these
are
equivalent.
They
don't
even
play
in
the
same
space
necessarily
but
they're
ones
that
we
feel,
like
you
kind
of,
have
to
know,
and
the
first
one
we're
going
to
talk
about
is
model
view
controller.
A
B
Sorry,
I
was
muted
there
for
a
second
thanks
mike.
I
think
we
probably
have
the
easiest
job
tonight,
and
I
say
this
because
mvc
is
probably
the
most
popular
of
the
architectural
patterns.
It's
the
one
that
I've
seen
the
most
in.
In
my
personal
experience
and
again,
the
kind
of
systems
that
I
I
get
to
look
at
are
very
big
old
systems
that
either
live
in
a
bank
or
some
sort
of
old
government
entity.
Right
and
basically
nbc
is,
is,
firstly
old.
B
So
the
three
parts
of
it
really
are
the
model,
the
view,
as
well
as
the
controller
in
which
the
model
is
concerned
with
the
data
and
how
the
data
itself
is
represented.
On
the
data
level,
the
view
would
be
what
the
user
ends
up,
seeing
and
really
interacting
with,
and
all
of
this
is
brought
together
by
your
controller,
which
is
also
where
you
you,
you
would
generally
facilitate
your
business
rules
or
put
in
your
business
logic
in
order
to
make
sense
of
of
all
of
these
floating
parts.
So
an
example
of
this
jeremy.
C
Oh
there
we
go,
it
was
being
slow.
We
say
we
have
a
model
of
data,
some
sort
of
data,
we
have
students
and
we
have
classes,
and
the
purpose
of
our
system
is
to
assign
our
students
to
classes
the
model
will
be
the
place
that
defines
what
the
student
looks
like.
So
a
student
will
have
a
name:
they'll
have
an
age.
They'll
have
a
date
of
birth.
They'll
have
some
sort
of
registration
number
for
the
school
that
we're
building
and
then
our
class
will
also
have
a
name.
C
C
Our
controller
is
the
brains
like
we
said,
that's
where
the
business
rules
will
go
all
of
the
things
like
getting
the
student
information
from
the
model
of
getting
the
class
information,
adding
a
student
to
a
class.
All
of
that
kind
of
logic
would
go
inside
the
controller
and,
lastly,
we'll
have
the
view,
which
is
the
visual
display
of
those
properties
and
like
we
can
see
in
the
picture
the
view
and
the
model
don't
talk
directly
to
each
other.
C
So,
as
lucky
said,
nbc
has
been
around
for
many
years
and
we've
seen
it
in
use
in
many
sort
systems
and
a
lot
of
different
frameworks
net
for
a
very
long
time.
Java.
All
of
the
famous
frameworks,
even
angular
1,
is
mvc
based
and
here
we've
listed
some
of
the
pros
and
cons
of
mvc
and,
like
you
already
mentioned
a
couple
of
these,
but
you
want
to
talk
through
the
rest
of
the
pros.
B
If
I
need
to
get
that
piece
of
data,
why
do
I
have
to
go
through
all
of
these
other
channels
when
I
could
just
create
direct
link
and
get
that
data?
And
that's
because
I
didn't
really
understand
what
it
takes
to
put
together
a
big
software
system.
Writing
code
is
easy.
I
think
we
can
all
write
code,
but
building
software,
that's
where
the
the
the
difficult
part
comes
in
and
what
mdc
has
has
or
from
my
bit.
B
From
my
perspective,
some
of
these
benefits
include
being
able
to
really
separate
your
your
your
your
concerns,
because
by
decoupling,
what
your
view
and
your
your
your
bottle
sits
and
having
that
business
logic
in
one
central
place.
Some
of
the
benefits
of
that
are
that,
firstly,
you
don't
repeat
yourself
when
you
have
to
change
a
core
fundamental
business
rule,
there's
only
one
place
that
it
actually
lives,
and
all
of
this
information
is
actually
funneled
through
that
one
channel.
B
It
has
proven
to
make
maintainability
slightly
easier
than
if
I
just
written
everything
in
a
monolith
manner,
and
it
also
supports
being
able
to
have
multiple
different
views,
because
they
all
speak
to
that
same
controller.
That
then
still
enforces
those
business
rules
and,
despite
not
working
on
too
many
systems
that
have
full
end-to-end
testing,
it
also
makes
testing
each
one
of
those
components
individually
possible
and
much
easier.
C
Yes,
so
that
yeah,
that
does
make
mvc
what
some
of
the
reasons
why
nbc
is
one
of
the
most
popular
frameworks
out
there,
but
there
are
some
downsides
to
it,
even
though
it's
been
around
forever
and
everyone
uses
it
everywhere,
usually
as
a
first
attempt
when
building
systems,
people
just
go
revert
back
to
nbc.
There
are
some
problems
with
it
and
the
first
one
is
the
complexity
of
it.
Like
lucky
said
you
just
want
to
do
the
thing.
C
You
know
you
don't
you
want
to
skip
all
of
the
steps
and,
if
you're,
building
a
relatively
small
application
or
something
like
that
that
doesn't
need
all
of
this
extra
boilerplate
in
order
to
get
started,
it
can
be
a
little
bit
complex
to
get
done
and
the
inefficiency
of
data
access
in
the
view,
so
the
view
has
to
always
go
via
the
controller.
You
can't
just
you
know,
get
the
thing
onto
the
view
easily.
C
A
So,
like
I'm
going
to
share
my
first
feeling-
and
my
first
feeling
is
that
I
use-
and
perhaps
it's
where
I
come
from
and
how
old
I
am,
but
I
use
mvc
is
like
the
rosetta
stone
between
frameworks
and
languages
so
like
if
I'm
learning
a
new
language,
the
first
thing
I'll
do
is
I'll
find
whatever
the
the
de
facto
standard
mvc
framework
is
and
I'll
be
like,
okay,
cool.
Let
me
use
the
paradigm
that
I
understand
and
then
I
can
get
to
grips
with
like
how
the
language
needs
to
be
used.
A
Idiomatically,
because
I
understand
mvc,
I
think
if
you,
if
you
work
on
web,
you
have
to
you,
have
to
know
mvc
right
and
I'm
going
to
give
other
people
a
chance
as
well.
But
like
the
one
thing
I
I
don't,
we
haven't
scripted
this
stuff
folks,
we
haven't
really
shared
opinions
other
than
who's
going
to
introduce
which
sections.
A
I
don't
agree
that
mvc
is
a
high
complexity
to
start.
I
think
mvc
is
ideal
for
simple
applications.
Where
there's
a
very
well
followed
pattern.
You
don't
have
to
think
about
the
pattern
right
you
just
you
just
do
what
it
says
on
the
box
and
follow
the
drawing
between
the
lines
and
there's
a
very
easy
thing.
I
think
the
problem
with
mdc
is
when
it
starts
getting
complicated
and
you've
got
lots
of
roots
and
lots
of
pages.
A
D
D
This
is
so
great
and
then
you
know
like
if
you've
worked
on
mvc,
specifically
in
something
like
asp.net
you've,
you
know
they've
introduced
this
thing
called
areas
which
is
kind
of
like
well,
I
say
they've
introduced,
it
was
about
five
years
ago,
but
it's
like
a
way
to
sort
of
encapsulate,
separate
domains
and
that
sort
of
thing
and
it's
just
it
just
shows
you
that
that's
that's
one
of
the
symptoms
of
the
problem,
problems
inherent
with
mvc
and
then
kind
of
like.
Is
it
really
worth
it?
D
B
B
E
It's
probably
also
it's
got
different
interpretations,
so
I
think,
like
the
diagram
that
that
you
guys
showed
it
had
all
of
the
traffic
going
through
the
controller
and
that's
cool.
I
think,
like
that's
nbc,
when
you've,
when
you're
dealing
with
the
server
and
client
side
so
like,
if
you
have
so
my
first
introduction
to
nbc
was
django.
So
it's
like
the
models,
that's
the
database
and
then
your
views
are
like
things
that
just
generate
some
html
and
you
and
it
all
makes
sense
and
that's
fantastic.
E
Like
looking
at
how
facebook
used
to
use
mvc.
It
was
like
completely
bananas
in
comparison,
so
they
had
like
the
controller
sitting
over
here
somewhere
and
then
they've
got
the
models
like
lots
of
models
and
then
lots
of
views
and
the
view
all
talking
to
the
models
and
the
models
all
talking
to
the
views,
and
it's
bi-directional
and
weird
looking
and
also,
I
think,
like
a
lot
of
the
yeah.
So
so
I
think
that
with
that
implementation,
there's
a
lot
of
complexity
and
cyclic-ness
yeah.
E
E
A
C
A
I
think,
like
we
use
the
example
of
angularjs.
I
think
they
got
them
into
a
lot
of
themselves
into
a
lot
of
trouble
because
they
relied
very
heavily
on
the
model
view
controller
metaphor
and
then
the
more
advanced
and
more
adopted
angularjs
became
and
the
bigger
applications
people
started
building
the
more
they
realized
that
damn
this
doesn't.
This
doesn't
actually
work
for
how
people
are
using
the
framework
anymore.
I
see
a
really
loving
sister.
F
No,
it's
it's
to
answer
lucky's
question.
It's
just
like
it
first
was
easy
to
start,
and
then
everyone
discovered
that
it
doesn't
scale
so
the
problem-
or
at
least
it's
complex
to
do
so,
and
that's
why
companies
like
facebook
then
decided
to
go
a
different
route.
Is
that
to
answer
you
like,
as
we
all
started,
it's
like
logically
model
view
controllers,
make
sense
to
me.
I
believe
that
they
are
isolated.
I
believe
the
communication
is
happening
as
I
should.
My
view
is
getting
the
information.
F
C
Yeah
one
one
thing
that
I
think
like
what
what
chino
is
saying
and-
and
I
think
it's
one
of
the
problems
with
mvc
actually-
is
that,
because,
when
people
started
growing
out
of
mvc,
they
found
other
ways,
everyone
found
a
different
way
which
wasn't
really
like
documented
in
any
pattern,
and
sometimes
that's
okay
right,
but
but
for
understanding,
something
like
going
from
someone
who's
found
one
way
to
scale
the
mvc
to
going
to
someone
who's
found
a
completely
different
way.
Like
you
struggle
to
understand
that
kind
of
stuff.
You
know
it's
it's
just
like.
D
It's
just
going
back
to
lucky's
que
original
question
about.
Why
is
it
so
popular?
Why
isn't
it
died?
Yet
I
think
if
you
look
at
spring,
if
you
look
at
asp.net,
if
you
look
at
like
ruby
django,
all
of
them
come
with
an
mvc
implementation
out
of
the
box
and
a
lot
of
the
the
beginner
tutorials
are
built
around
that
so
you're
like
okay.
This
must
be
industry
best
practice.
So
you
get
started
on
that
and
by
the
time
you
realize
that
you've
gone
too
far.
A
C
To
as
an
option
today,
because
because
it's
it
is
something
that
we
all
thought
that
it's
a
pattern
that
all
web
developers
should
know:
okay,
yeah
like
when
we
get
to
the
next
one,
the
next
patterns,
flux
and
event,
events-
those
are
a
lot
more
complex,
they're,
not
the
kind
of
thing
you
can
teach
a
student.
You
know
necessarily.
A
C
A
A
F
The
idea
is
that
we
interrogate
the
things
that
we
find
uncomfortable
with
them
and
things
that
we've
learned
out
of
it,
but
but
this
still
has
a
place
and
that's
why
it's
still
used
and
has
a
purpose
with
whatever
skill
that
application
might
be,
but
still
has
the
like
for
people
to
pay
attention
to
it
and
learn
what
it's
about
and
understand.
It.
D
C
Understanding
mvc
is
very
important.
I
think
like
something
that
what
mike
was
saying
earlier
with
nbc
when
you
learn
a
new
language,
you
start
with
the
mvc
framework
and
thinking
about
it.
I've
done
that
too
I've
gone
into
a
language
and
like
if
I,
if
I've
confined
an
nbc
framework,
I'm
like
I
can't
learn
this
language.
A
A
So
it's
it's
taking
a
look
at
the
paradigm,
I
suppose
in
context
of
next
generation
deployment
infrastructure.
So
that's
a
very
good
point
and
a
very
good
question,
because
a
lot
of
people
are
looking
at
because
the
things
that
you
highlight,
barring
potentially
the
api
gateway,
are
largely
free
right.
So
you
can
write
a
close
to
model
view,
controller
application
except
using
free
stuff
or
relatively
inexpensive
stuff,
that's
commoditized
and
cloud
native.
A
I
think-
and
I
don't
know
what
your
feelings
are,
but
I
think
that
I
would
not
I
think,
through
a
lens
you
could
you
could
build
something
that
was
mvc
adjacent,
that
followed
the
pattern
of
mvc,
and
I
agree
with
that
entirely
but
like
when
we're
talking
about
mvc
as
being
the
ready
mix
that
doesn't
taste
like
ready
mix
right.
That
tastes
like
I'm,
I'm
making
my
own
cupcakes
from
scratch.
A
So
one
last
point:
before
we
move
on
and
I'm
sorry
like,
I
love
npc.
I
really
really
do
but
like
it's
it's
a
question
as
much
as
it's
an
opinion
when
I
was
learning
mvc,
one
of
the
idioms
that
was
used
around
it
was
fat
model,
skinny
controller
and
basically,
what
that
meant
is
taking
all
of
your
business
logic
or
as
much
as
possible
outside
of
your
controller
and
putting
it
all
into
your
model
and
having
your
model,
be
an
object
that
knew
how
to
operate
on
itself
and
load
itself,
etc,
cetera.
A
C
That
there
was
actually
something
I
was
I
was
going
to
to
mention
as
well.
I
I
also
feel,
like
other,
like
forms
of
programming,
don't
really
match
the
mvc
pattern
that
well,
whereas
object
orientation
orientation
does
very
well
it
just
it
just.
It
works
the
way
that
like,
if
we
think
about
the
probably
two
most
popular
mvc
frameworks
of
spring
mvcn
and
dot
net
nbc,
they
are
both
object-oriented
languages.
A
A
E
All
right
so
flux
came
about
or
was
popularized
by
facebook.
I
don't
actually
know
if
they
invented
it
or
not,
but
yeah.
So
in
their
architecture
they
had
a
whole
lot
of
troubles
with
a
weird
mvc-ish
thing
that
they
were
trying
to
do
and
that's
all
sorts
of
cyclical
dependencies
and
unpredictable
code
and
that
sort
of
thing.
So
the
main
issue
was
around
having
lots
of
bi-directional
data
flows
that
could
affect
each
other
and
it's
caused
all
sorts
of
trouble
so
flux.
E
E
I'm
sure
they're
different
things
in
like
redux
is
the
most
common
implementation
really
is
going
to
talk
about
that
a
little
bit
later,
but
yeah
in
redux,
like
the
actions,
are
little
tiny,
json
objects
and
that's
quite
nice,
because
they're
they're,
like
very
small,
simple
things
that
you
can
pass
around.
You
feed
them
to
a
dispatcher,
and
the
dispatcher
is
something
that
basically
controls
the
flow
of
of
information.
So
it
doesn't,
it
doesn't
allow
lots
of
things
to
happen
at
exactly
the
same
time.
E
So
the
original
flux
would
only
allow
you
to
have
one
action
at
a
time
and
then
it
would
like,
if
you
try
to
get
it
to
do
too
many
things
at
once.
It
would
just
kind
of
fall
over
and
break,
but
what's
cool
about
that,
is
that,
like
you,
you
can't
like
start
a
new
action
until
the
previous
action
is
finished
resolving,
and
that
makes
your
code
like
much
much
easier
to
to
debug
and
to
test
and
to
reason
about,
and
all
of
that
the
next
part
is
the
store.
E
So
the
store
is
like
kind
of
like
the
model
in
mvc.
So
that's
where
the
data
lives
and
it's
not
super
intelligent.
It
just
kind
of
knows
about
like
how
it
needs
to
update
itself
based
on
different
actions.
So
if
you
had
a
house
that
you
were
trying
to
do
cool
stuff
with
and
you
wanted
to
have
an
action
to
turn
the
light
on,
then
your
store
would
be
like
oh
cool.
I
got
the
turn
light
on
action.
E
I'm
just
gonna
change
that
over
there
to
a
one
and
then
life
is
good
and
then
the
view
is
very
much
like
the
view
in
mvc
as
well.
So
so
with
this,
you
can
have
lots
of
different
stores
and
you
can
have
lots
of
different
views
as
well,
but
you
never
have
data
going
from
the
view
back
to
the
store.
It's
always
like
action
goes
to
dispatch
goes
to
store
and
then
the
view
can
make
more
actions
if
it
wants
to
and
send
them
back
to
the
dispatch.
E
E
So
if
anybody
here
has
worked
with
redux
before
in
the
browser,
you
can
like
almost
time
travel
in
your
app
you.
Can
it
really
helps
a
lot
with
debugging
then,
because
of
all
the
actions
going
through
this,
the
dispatcher?
You
don't
have
any
strange
cycle
things
happening.
Things
are
quite
orderly,
like
you
can
also
add
on
things
in
different
implementations.
You
can
add
on
middlewares
to
add
to
make
your
dispatcher
a
bit
more
awesome.
Then
it's
way
way
more
scalable
than
mvc
so
scalable
in
terms
of
complexity.
E
So
if
you
have
an
app
that
does
like
a
lot
of
different
things,
then
then
this
is
cool
and
then
the
fact
that
the
actions
are
so
simple
and
serializable
that
opens
more
doors.
I
mean
you
could
store
the
actions.
The
actions
are
things
that
you
can
send
over
a
wire
if
you
wanted
to
so
it's
like
quite
yeah.
It's
quite
manual
like
that
over
to
rudy.
F
We
can
make
this
a
little
bit
simpler
by
replacing
the
dispatcher
with
the
reducer,
and
this
is
basically
what
it
still
follows:
the
unidirectional
flow
of
flux,
but
they've
kind
of
made
the
all-around
trip
a
little
bit
shorter
by
using
the
reducer
and
there's
quite
a
lot
of
things,
that's
packed
into
redux,
but
yeah
we'll
get
into
that
a
little
bit
later
on,
and
they
also
have
a
centralized
store.
The
other
three
one
that
you
might
not
know
about-
or
maybe
you
know
about-
but
I'm
just
gonna-
highlight
it
anyway,
so
reflux.
F
It
removes
this
dispatcher
entirely
and
allows
the
actions
themselves.
So
if
ever
you
remember
the
the
diagram
in
the
previous
slide
for
them
to
be
able
to
dispatch
to
the
store
as
needed,
because
then
the
view
will
say
hey.
This
is
what
I'm
doing
and
the
actions
would
be
a
lot
more
smarter
into
carrying
that
data
and
sending
it
to
the
store.
F
And
then
the
other
implementation
of
flux
is
alt,
which
has
a
very
weird
kind
of
concept,
with
their
actions
by
just
firing
and
forgetting
and
not
not
having
to
do
anything
with
it,
be
like
okay,
cool.
This
is
the
action
that
I'm
I'm
going
to
dispatch
or
release,
and
I'm
just
going
to
allow
everything
else
to
take
care
of
itself.
The
store
has
no
setters,
and
maybe
this
might
not
mean
anything
to
either.
F
If
ever
we
are
coming
from
a
world
of
mvc
and
all
of
that,
and
as
the
conversation
that
we
just
had
about
nvc-
is
that
it's
easier
to
start?
That's
not
true
with
flux.
Fluxes
has
a
lot
of
boilerplate,
there's
a
lot
of
things
that
you
need
to
put
in
place
to
make
it
work
all
these
states
and
stalls
and
actions
that
we're
talking
about
if
you've
implemented
an
application
in
a
flat
space.
There's
a
lot,
that's
involved
for
you
to
actually
get
started.
F
It
can
also
get
unnecessarily
complex,
especially
if
ever
you
have
a
view
that
maps
to
a
store,
because
the
lines
are
not
clear
between
at
to
what
point?
Do
you
start
creating
a
new
store
for
a
specific
view
and
all
of
those
things,
so
that
could
also
get
a
little
bit
complex
and
make
simple
changes
a
lot,
a
lot
more
elaborate.
If
ever,
I
might
say,
like
you
can't
just
change
one
thing
and
be
like
okay.
F
The
other
part
is
that
stores
can
be
very
lengthy
and
hard
to
read
at
some
point,
because
people
might
not
know
the
the
part
at
which
they
need
to
split
to
a
different
one,
so
everything
might
be
in
one
file.
Those
files
can
get
to
very,
very
long
lines
and
when
I
started
investigating
about
this
topic
this
I
found
very
interesting
because
even
though
it
might
not
be
a
disadvantage
for
other
people,
I've
actually
experienced
this.
F
F
There's
so
many
problems
with
this,
because
sometimes
you
can
have
multiple
actions
that
are
actually
dispatched
in
parallel
and
you
need
to
figure
out
which
one
has
the
cue
and
is
waiting
for
the
thing
to
run,
and
that
needs
to
end
first
before
the
next
thing
comes
about,
and
this
based
on
a
previous
job
that
I
have
performance
leaks
with
the
the
well
the
redux
of
the
flux
implementation
pattern.
But
we
have
something
called,
should
component
update
and
just
like
a
young
level.
F
Explanation
of
this
is
like
at
some
point
when
a
view
needs
to
change.
Your
component
needs
to
re-render
the
calculation
at
which
you
actually
see
what
has
actually
changed.
What
is
affected
by
the
change
can
propagate
to
different
parts
of
the
of
your
view
and
things
that
don't
necessarily
need
to
update,
will
update
and
this
part
in
this
calculation
and
this
complexity
results
into
a
lot
of
performance
in
your
application
and
last
but
not
least,
because
there's
so
much
involved
in
flux.
F
The
learning
curve,
for
it
might
be
a
little
bit
steep
compared
to
like
other
patterns
like
nvc.
So
it
might
need
you
to
be
a
little
bit
involved
when
you
need
to
start
using
it
so
yeah.
These
are
the
thoughts,
and
now
we
have
to
talk
about
pitfalls,
thoughts,
pick
from
people
and
how
you
can
actually
overcome
these
yeah.
E
So
this
slide
is
just
like,
I
think
everybody
who's
used.
Redux
has
probably
also
misused
redux,
because
it's
like,
as
rudy,
says
it's
it's
a
weird
thing
to
learn.
It's
not
that
intuitive,
like
the
official
tutorial,
is
great
by
the
way
it's
really
lovely,
but
you
start
reading
the
thing.
It's
like
here's,
an
action.
It's
like
okay,
it's
like
what
is
this
for.
E
E
E
E
E
A
survey
and
the
survey
has
questions
and
the
questions
have
like
types
and
this
one
can
have
some
options
and
so,
like
a
form
thing,
and
so
I
was
like
cool
I'll
just
like
represent
a
survey
in
its
entirety
in
this
like
highly
nested
data
structure
and
then,
when
we
press
this
button,
this
piece
down
here
somewhere
is
going
to
change
slightly
and
like
lots
of
ellipsis
dots,
and
that
worked
fine
except
it
was
really
really
slow.
So
there's
some
tricks
around
just
structuring
your
data
nicely
like
making
things
nice
and
flat.
E
E
Is
it
doesn't
really
have
a
good
idea
about
how
side
effects
work
so,
like
asynchronous
things,
aren't
really
that
well
represented
so
like
it's
not
built
into
the
core
product,
and
that's
true
for
redux
as
well,
so
you
have
to
be
like
thanks
exist
and
target
exists,
so
you
have
to
pick
one
of
those.
So
that's
good!
Well,
they
are
useful
things.
My
preference
is
saga
because,
again
flat
is
better
than
nested.
E
One
other
like
another
thing
that
people
bump
their
heads
on
is
the
fact
that
sometimes
you
want
to
dispatch
an
action
that
has
functionality
that
overlaps
with
another
action
and
then
suddenly
your
stuff
isn't
dry
anymore,
and
you
yeah.
It
just
ends
up
being
a
little
bit
confusing.
So
for
me,
a
way
to
overcome
that
is
actually
to
use
something
that
can
deal
with
those
side
effects.
E
So
just
like
have
a
an
action
that
gets
picked
up
by
a
middleware
that
can
deal
with
making
more
actions,
and
then
you
can
just
like
compose
your
actions
and
that
works
pretty
well.
Another
thing
that
people
do
is
sometimes
they'll
make
like
one
gigantic
reducer
and
to
just
like
control.
All
of
the
state
in
like
one
file
and
if
your
application
gets
big,
then
suddenly,
your
like
your
scalability
goes
out
the
window
because
it
becomes
a
bit
hard
to
manage
so
yeah.
E
It
can
become
quite
challenging
so
like
naming
files
and
functions,
and
all
of
that
is
pretty
hard.
It's
like
kind
of
a
challenging
problem.
If
you
want
to
keep
your
code
like
nice
and
clean
and
scalable,
and
it's
kind
of
hard
in
redux
as
well.
So
there's
this
thing
called
the
ducks
pattern
or
ducks
approach
to
redux,
which
is
pretty
cool.
I
recommend
that
if
you're
looking
into
doing
some
like
redux
on
an
application
that
you
want
to
scale,
then
you
probably
want
to
look
that
up.
E
It
makes
it
yourself
like
nice
and
clear
and
cohesive,
but
it
also
adds
a
whole
lot
more
boilerplate,
and
then
I
think
this
was
a
con
that
really
mentioned
like.
If
you
it
can
be
pretty
hard
to
like
reason
about
where
different
reducers
should
go
so
like.
Where,
like,
let's
say,
for
example,
you
have
a
web
app
and
you
have
people
can
log
in
and
different
users
have
different
rights,
and
so
I
know
different
things
show
up
in
different
colors
who
knows
like?
Where
should
that
information
go?
E
You
need
to
do
a
little
bit
of
thinking
about
like
what
which
reduces
you
need
and
which
views
need
to
access
the
stores
that
are
managed
by
the
parts
of
the
store
that
are
managed
by
the
different
reducers.
So
like
it's
something
that
you
should
probably
think
about
early
on
in
your
application
development,
because
otherwise
things
get
a
little
bit
untidy,
yeah
and
then
last
but
not
least,
critical
things
become
complicated.
So.
E
B
E
Like
try
and
keep
your
keep
your
code
like
nice
and
neat
and
dry
and
then
eventually
you'll
be
able
to
like
be
able
to
say,
like
oh
here's,
a
pattern
I
can
just
like,
take
it
out
and
put
it
over
there
and
use
it
again.
So,
just
like
that's
just
like
clean
coating
and
dry
coating
but
yeah,
that
is
something
you'll
dump
your
head
on
most
likely.
C
C
C
C
In
my
opinion,
I
I
think
you
can
do
so
much
with
it
like
you.
Can
you
can
scale
it
to
make
a
system
that
works
really?
Well,
though,
at
least
that's
my
opinion,
but
again
yeah
all
of
these
pitfalls
and
all
of
the
cons
are,
I
think,
based
on
the
fact
that
it
has
a
steep
learning
curve
and
you
have
to
actually
figure
out
how
to
do
it.
First
before
you
can
use
it.
A
Please
so
I
love
redux.
I
really
really
do
and
everything
that
sheena
and
rudy
said
is
correct,
but
redux
is
designed
to
solve
really
hard
problems
simply
and
elegantly.
You
should
not
be
using
redux
as
the
first
thing
like
you
don't
reach
for
the
chainsaw
in
your
toolbox.
Immediately,
like
you
first,
you
first
figure
out
when
you
need
to
use
a
chainsaw
for
that
exact
job
right.
It's
an
expert
tool
that
you're
gonna
run
into.
A
In
fact,
if
you
are
just
making
api
calls
and
showing
data,
you
don't
need
redux,
you
don't
need
anything,
you
don't
need
a
framework,
don't
use
a
framework,
just
use,
javascript,
okay,
end
of
story.
We
can
have
we're
done
with
that
discussion
right.
If
you,
if
you're
dealing
with
forms,
you
don't
need
a
javascript
framework.
You
should
be
in
the
previous
one,
which
is
mvc,
because
mvc
is
really
good
at
easily
dealing
with
forms.
Don't
do
it
in
redux,
okay,
you're,
using
the
wrong
tool
for
the
job.
A
I
think
it's
important
to
know
where
redux
came
from,
because
you
remember
in
the
previous
part
talking
about
facebook's
nbc
sheena
was
like
no
but
facebook's.
Nvc
is
so
confusing
right
because
I
wanted
to
send
data
from
the
view
to
the
model
and
model
to
the
view,
and
everything
was
confusing
and
that's
why
they
created
readers
right
because
their
data
space,
their
interaction
space,
is
so
complicated.
A
One
thumbs
up
like
need
to
change
five
things,
five
things
on
the
page
and
that's
where
redux
is
really
useful.
That
sort
of
like
page
level
cross
component
completely
divorced
from
context
in
my
opinion,
but
you
will
get
people
who
are
like.
Oh
redux
was
the
new
shiny,
so
we're
going
to
we're
going
to
use
we're
going
to
use
it
for
everything
and
no.
A
Yeah,
exactly
it's
not
redux's
fault
right,
it's
still,
as
as
jerry
said,
it's
useful
way
beyond
react,
so
I've
got
two
points
and
the
first
one
I
think
we're
gonna
we're
gonna
go
to
tobiso
again
and
answer
this
question
as
a
react
developer.
Do
you
really
need
frameworks
like
redux
or
patents
like
right
flux?
If
you
can
just
use
react
hooks,
I'm
gonna
address
the
elephant
in
the
room.
Contentiously
react
hooks
are
redux.
A
They
are
flux,
pattern
with
a
whole
bunch
of
niceties
that
facebook
uses
to
to
hide
the
complexity
of
of
a
flux
pattern
from
you,
but
like
they
literally
call
the
hook,
use
reducer
right.
It's
just
like
a
cut
down
version
of
redux
that
doesn't
have
as
much
functionality
and
takes
up
a
lot
more
space
in
terms
of
javascript.
A
F
Far
less
boilerplate,
but
also
there
is
a
cost
to
it,
because
nothing
is
ever
for
free,
we'd
like
to
use
hooks,
and
you
know
it
makes
life
simple
and
it
abstracts
certain
things,
but
introduce
something
in
display
components
of
view,
components
that
shouldn't
be
there,
because
now
there's
a
a
combination
of
your
state
where
your
simple
visual
components
need
to
be.
It
comes
at
that
cost.
F
A
A
C
Because
because
we
all
come
from
object,
oriented
backgrounds-
and
you
know
functional
programming,
so
mvc
is
easy
to
gross
plus,
but
but
while
we
already
was
actually
speaking
about
the
whole,
the
learning
curve
thing
and
and
how
it's
a
bad
thing,
so
we've
already
said
multiple
times.
It
has
a
stupid
curve
right,
but
if
you
think
about
it,
teaching
students
the
mpc
pattern
for
them.
F
F
That
mvc
was
not
such
a
hard
stretch
for
me,
but
and
the
thing
is
that
that
background
was
already
and
instilled
in
me
that
it
I
didn't
have
to
work
hard
at
it.
While
flux
has
that.
So,
if
ever
I
was
given
a
situ
an
opportunity
to
learn
functional
programming,
as
my
inherent
like
learning,
paradigm
or
architecture.
Maybe
this
flex
pattern
wouldn't
have
been
so
hard
for
me
to
reach
to
or
like
understand
or
like
learn,
and
things
like
that.
F
So
there
is
an
inherent
way
in
which
we
learn
that
actually
forces
certain
things
that,
like
force
us
to
think
in
a
different
way,
a
lot
harder,
while
actually
they
are
not
and,
as
you
said
like
you
know,
it's,
they
might
have
been
a
learning
curve
for
mvc.
But
we
all
know
that
we
have
an
object-oriented
background
to
whatever,
where
you
started
coding,
because
everyone
teaches
you
oop.
A
A
So
I
feel
like
in
many
ways
the
context
api
is
sort
of
reacts
escape
lever
for
two-way
data
binding
in
some
contexts.
I
know
that's
a
bad
explanation,
but,
like
that's
how
it
often
gets
used.
I
think
the
context
api
like
when
I
when
I
write
react,
components.
That's
my
go-to,
it's
wonderful
and
I
think
I
think
you
can
get
for
the
react
for
the
reduxy
stuff
that
you
want.
D
Yeah,
I
think
that's
a
great
point.
I
think,
for
those
of
you
who
aren't
familiar
with
the
context
api.
The
place
where
it
often
gets
used
out
of
the
box
is,
if
you
import
some
sort
of
styling
library
and
it's
got
a
theme,
they
often
use
the
context
api
for
you
to
be
able
to
set
the
color
palette
and
the
fonts
and
that
sort
of
thing
on
the
context
api.
So
it's
basically
like
a
giant
value
pair
dictionary,
but
can
also
support
nesting.
F
F
The
the
how
I
got
introduced
to
a
context,
api
was
actually
through
mic
and
the
concept
of
prop
drilling,
which
is,
I
think,
something
that
is
worth
talking
about.
Especially
when
react
is,
is
you
know,
being
discussed
through
flux
through
redux,
and
all
of
that
is
that
if
ever
you
have
seen
yourself
passing
props
to
if
child
components
to
child
components
to
child
components,
especially
if
ever
what
you
only
want
is
actually
a
view
display
kind
of
functionality
like
there
is
no
interaction
in
that
page
of
any
sense.
F
All
you
want
to
do
is
just
get
data
displayed
into
the
page
context.
Api
can
really
help
you
in
that's
in
a
sense,
because
you
can
use
it
to
actually
wrap
all
that
information
that
you
want
to
pass
through
all
those
child
components,
and
they
don't
need
to
be
sending
data
back
and
forth.
So
I
found
it
very
useful
in
that
use.
C
A
C
C
Like
redux
has
a
purpose,
but
let's
let's
remember
that
this
this
pattern,
the
flux
pattern,
the
unidirectional
flow
of
data
pattern
is
is
not
just
redux
I
mean
redux
is
the
most
popular
one,
but
and
if
we
think
about
it,
so
a
lot
of
people
don't
like
redux,
because
it's
gotten
a
bad
name
because
of
its
deep
learning
kind
of
all
those
bad
parts
of
it.
But
if
we
think
about
it,
the
way
that
we
bode
web
things
when
they
become
more
complicated,
they
actually
end
up
following
that
pattern.
A
I
think
that's
a
good
shot
jerry
because
like
and
that's
why
we
didn't
call.
We've
now
focused
on
redux
right,
because
we're
all
intimately
familiar
with
an
implementation
of
flux,
pen
but
rudy.
You
shouted
out
mobx
right,
which
is
a
stateful
state
management
pattern
which
is
as
observable
and
in
many
ways.
The
observable
pattern
in
reactive
programming
is
an
implementation
of
flux,
because
the
way
that
you
push
onto
that
observable
and
the
way
that
you
see
from
the
read
from
the
observable
are
disconnected
right.
C
A
D
No,
I
was
just
going
to
say
I
can
confirm
I'm
currently
working
on
an
angular
1.8
project
at
the
moment,
and
I
had
to
there
was
a
lot
of
knowledge
that
I
had
purposefully
tried
to
forget
and
quarantined
off
in
the
depths
of
my
mind
that
I
had
to
pull
out
and
it's
like
what
is
it?
Oh,
it's
got
this
controller
and
service
at
service.
It's
like
all
sorts
of
crazy
stuff
and
yeah.
A
A
C
A
Thank
you,
so
the
last
one
that
we
just
want
to
touch
on
and
again
remember
that
this
isn't
the
book
definition
of
this
stuff.
Necessarily.
This
is
how
we
see
this
pattern
manifesting
in
in
the
world,
so
we're
going
to
talk
about
event-based,
architectures
and
particularly
something
along
the
lines
of
of
of
pub
sub
right,
which
is
what
people
are
mostly
going
to
think
about,
and
there
are
some
very
specific
examples
of
this,
but,
like
pop
stuff
is
relatively
generic
enough.
A
Now
all
event-based
architectures
revolve
around
there.
There
is
a
message,
bus
right
and
instead
of
like
a
unidirectional
flow
of
data,
we
now
have
a
spider
cardinality
flow
of
data,
where
every
anything
can
be
a
publisher
and
put
something
on
the
bus
and
anything
can
be
a
consumer
of
a
particular
topic
and
say:
hey,
I'm
interested
in
this.
I
want
to
receive
it
and
I
will
receive
every
message
related
to
this
thing
and
in
things,
don't
necessarily
just
have
to
be
one
or
the
other.
They
can
be
both
at
the
same
time.
A
They
can
both
be
a
consumer
of
one
message
and
a
publisher
of
a
completely
different
message
and
without
going
into
some
specific
examples,
it's
going
to
be
hard
to
to
explain
at
like
a
theoretical
level.
So
we're
going
to
start
off
with
the
front-end
example
because,
hey
believe
it
or
not,
the
browser
works
off
of
messages
and
events.
Everything
mass
events,
click
events.
Everything
is
event-based.
A
So
basically,
if
you
look
at
document,
events,
document.body
or
any
individual
part
of
the
page
is
like
a
message,
bus
and
what
you
can
do.
As
for
an
example
for
a
shopping,
cart
right
where
you've
got
a
whole
bunch
of
items
on
the
page.
If
somebody
clicks
the
button,
you
can
just
go,
document.body.dispatchevent
add
and
then
here's
a
json
bag
of
data
that
I'm
adding
and
that'll
go
into
so
so
message
a
will
then
go
into
the
document.buddy,
and
then
anybody
who
goes
document.buddy,
which
is
the
element
it
can
be
any
element
right.
A
So
you
can
scope
this
wherever
you
want,
but
let's
just
document
the
body
as
an
example
so
document.addeventlistener
and
I'm
going
to
listen
to
the
add
event
and
any
ad
event
goes
into
this
function.
I'm
going
to
do
something
with
it.
Okay,
so
whenever
somebody
clicks
a
button,
both
analytics,
which
is
some
amorphous
javascript
file,
that
does
I
don't
know
some
google
analytics
stuff
or
something
and
the
shopping
basket
component,
the
little
icon
in
the
corner
are
both
going
to
listen
to
that
event,
they're
going
to
say
cool
now
on
analytics.
A
A
Add
it
to
the
basket
yeah
they're
tracking
you
completely
and
then
on
the
shopping
basket
component.
You
can
say
well
somebody
asked
to
add
this
thing.
Let
me,
let
me
add
it
to
either
their
session
state
or
make
some
api
calls,
or
something
and
and
operate
on
it,
so
that
I
can
update
the
basket
because
I've
tried
to
buy
a
product
and
then,
when
that's
done,
we
can
say
cool.
Well,
we're
not
finished
our
part.
We
can
confirm
that
we're
done
right,
let's
fire
off
another
event.
A
But
this
is
just
one
example
that
is
not
uncommon
in
a
shopping,
cart
context
and
before
we
move
on.
I
just
want
to
point
out
that,
like
this
is
something
that
you
can
do
without
needing
a
framework.
This
is
in
your
browser,
because
this
is
how
your
browser
works.
When
somebody
clicks
it
publishes
a
click
event
on
that
element
to
everything
that
subscribes
to
click.
Events
on
that
element,
but
but
understanding
the
sort
of
spiraling
complexity
of
message-based,
architectures
or
event-based
architectures
is
not
just
on
the
front-end.
D
Cool,
so
I'm
one
of
the
few
javascript
developers
who
does
almost
no
front-end
development,
so
my
focus
tends
to
be
on
the
back
end.
So
I
figured
I'd
put
together
an
example
and
show
you
just
how
simple
it
actually
is.
So
what
we're
going
to
be
simulating
here
is
a
fairly
standard
use
case
where
you
would
have
a
folder
and
you
would
build
something.
That's
just
going
to
watch
that
folder
for
file
drops.
D
So
this
is
fairly
often
something
that
happens
where
you
integrating
with
the
legacy
system
and
they're
on
the
as400,
and
they
can't
build
the
rest
api
to
do
stuff.
So
you
just
kind
of
want
to
get
it
done
really
really
quickly.
So
I'm
not
going
to
take
you
through
how
to
build
a
file
watcher.
If
that
is
something
that
you're
interested
please
reach
out,
and
I
can
help
you
with
that.
There's
a
there's
quite
a
few
open
source.
D
It
can
work,
but
it's
it's
not
very
scalable,
and
I
I
don't
recommend
it
and,
as
with
everything
in
software
engineering,
a
big
part
of
building
a
good
system
is
knowing
where
those
system
boundaries
are.
So
those
of
you
who
are
familiar
with
domain
driven
design,
you
can
apply
those
same
principles
when
building
your
own
buses
so
that
you,
you
can
separate
out
that
those
concerns
and
remember
you
can
always
rebroadcast
an
event
from
one
event
bus
to
another
one.
D
If
we
can
just
go
to
the
next
slide,
I'll
show
you
some
code
and
my
beautiful
theme,
if
anybody's
interested
in
this
code,
I'll
upload
it
onto
the
show
notes,
put
a
link,
maybe
I'll
dump
it
onto
github.
But
I
just
wanted
to
show
you
that
in
31
lines
of
code,
you
can
get
a
very
simple
event:
bus
up
and
running.
So
it
all
comes
from
the
built-in
events,
library,
which
is
part
of
the
node.js
api.
I
think
it's
been
around
since
the
very
beginning.
D
You
basically
just
new
up
the
event
emitter,
if
you
are
slightly
insane
and
you're
using
classes
in
javascript.
You
can
also
inherit
from
the
event
emitter
and
write
your
own
one.
I
am
a
little
bit
biased
on
functional
versus
classes,
and
if
you
want
to
fight
me
about
that,
we
can
meet
outside
after
school.
D
I
see
mike's
mike's
got
some
strong
opinions,
so
maybe
we'll
do
a
do
a
show
on
that
a
bit
later,
then.
Basically,
the
event
emitters
got
the
dot
on
which
you
might
be
familiar
with
from
the
front
end,
and
it's
just
basically
a
string
that
uniquely
identifies
or
sometimes
doesn't
uniquely
identify.
If
you
don't
put
them
in
a
central
place,
then
you
end
up
with
the
same
event
with
two
different
types
of
payloads.
So
I
would
recommend
that
you
actually
create
a
event
types
file
that
just
has
those
key
value
pairs.
D
You
basically
listen
to
the
event,
emitter
by
saying
event,
emitter
dot
on
and
then
it
receives
a
payload,
and
you
can
actually
pass
multiple
parameters
in
there
or
you
can
lump
everything
into.
One
context
object
it's
up
to
you.
Obviously,
if
you're
using
typescript,
you
can
get
some
type
information
on
that
and
if
you're
just
using
pure
javascript,
you
can
use
jsdoc
to
get
some
extra
typing
on
that
and
then.
D
Lastly,
if
you
would
like
to
broadcast
an
event,
you
simply
call
emit
and
you
provided
the
name
of
the
event
and
the
payload
that
you'd
like
to
pass
and
that'll
actually
broadcast
it
and
you'll
see.
In
this
particular
example,
we've
got
two
two
consumers
that
are
listening
to
the
same
event.
So
the
first
one
on
line
seven
there
is
basically
simulating
the
stats.
You
could
then
pump
that
into
prometheus
or
if
you've
got
an
elk
stack,
running
or
sql.
D
D
Don't
recommend
doing
that
in
production
because
then
you're
going
to
get
an
infinite
loop,
which
is
why
I've
got
the
number
of
times
in
there
just
to
just
to
short
circuit
it
after
it
runs
through
three
times
now.
Important
thing
is
now
in
a
distributed
programming
scenario.
You
might
want
to
listen
to
an
event
bus,
that's
on
another
server,
yeah
running
in
node.
D
D
But
it's
interesting
to
to
note
that
that's.
That
is
something
a
way
that
you
can
handle
it.
It
does
scale
incredibly
well,
you
can
add
as
many
listeners
as
you
need.
If
you
add
a
queuing
mechanism,
you
can
have
those
providers
actually
sorry,
the
consumers
actually
me
processing
the
queue
rather
than
the
event
bus
directly.
D
It's
very
easy
easily
to
extend.
So
if
you've
got
something
that
when
a
user
registers,
we
send
them
a
validation,
email
and
now,
a
couple
of
months
later,
you
need
to
also
send
them
a
validation
sms.
You
don't
have
to
go
and
interfere
with
that
existing
code.
You
can
just
add
a
new
listener
that
listens
for
the
exact
same
event,
and
this
is
one
of
the
most
mature
technologies
around
it's
been
around
for
nearly
half
a
half
a
century.
D
D
Some
of
the
cons
complexity
can
be
quite
high,
especially
if
you
think
about
it,
like
you're,
sending
an
event
off
into
this
message.
Bus
and
you're,
like
how
do
I
follow
the
stack
trace
down
like
what
is
going
to
handle
this?
You
know
you
see
you
like
find
in
solution.
Name
of
event,
you
know
see
if
you
can
do
that.
There
are
ways
to
mitigate
that
like
I
was
mentioning
earlier.
D
D
Handled
doesn't
translate
as
as
well
to
those
of
you
who
are
familiar
with
number
of
rest
requests,
duration
of
request,
because,
if
you
think
about
it,
if
you
send
a
request
to
the
server
and
you're
using
web
sockets-
and
you
say
process
this
message,
it's
going
to
return
almost
immediately
and
say
cool.
I
put
the
message
on
the
bus.
You
don't
know
how
long
the
side
effects
are
actually
going
to
take,
so
it
can
be
quite
tricky
to
figure
out.
We've
got
some
sort
of
performance
bottleneck
in
our
system.
What's
causing
it?
D
D
If
you
are
using
web
sockets
to
interact
with
the
event
bus,
it
can
add
an
extra
layer
of
complexity
and
it
can
also
increase
costs.
You
know
in
a
in
if
you're,
building
stuff
in
aws
lambdas
for
argument's
sake,
you
know
that
you're
only
paying
for
while
that
thing's
actually
active,
whereas
if
you're
using
web
sockets
until
very
recently,
you
had
to
have
the
server
running
the
whole
time
and
keeping
those
connections
alive,
which
can
add
extra
costs.
D
I
do
see
I
was
doing
a
bit
of
research
earlier,
that
aws
has
released
websockets
on
their
api
gateway,
which
is
quite
an
interesting
thing,
because
then
you
can
have
the
websocket
and
have
the
api
gateway
paying
for
that
and
executing
lambdas
to
do
the
logic
in
the
background.
So
that's
something
I'm
going
to
be
playing
around
with
in
the
next
little
bit
and
yeah.
That's
it
for
me.
A
So
it
feels
kind
of
unfair
and
disingenuous
to
have.
The
complexity
is
high
on
this
and
on
the
flux,
pros
and
cons
slide
because
like
to
be
super
clear,
there's
an
order
of
magnitude
difference-
and
this
is
complex
from
flux
to
event
based
architectures,
because
flux
at
least
has
a
pattern
right.
It's
got
a.
This
is
how
thou
shalt
do
things
event
based
architectures,
basically
take
that
and
check
it
in
the
bin.
They're,
like
whatever.
D
A
As
soon
as
you
go
over
a
websocket
or
putting
it
on
a
message
broker.
That's
externalized!
Suddenly
your
your
consumers
can't
guarantee
that
they're
going
to
get
the
messages
in
the
right
order.
So
let's
say
somebody
hit
save
on
on
whatever.
Let's
say
it's
a
full.
You
shouldn't
use
this
for
forms.
Don't
anyone
ever
said
that
mike
said,
you
should
use
this
for
falls.
It's
a
bad
idea,
but
let's
say
you're
using
it
for
a
form
right
and
you
hit
save
and
somebody's
like.
C
Yeah,
so
one
of
one
of
the
things
I
was
gonna
say
is
on.
On
the
one
hand,
one
pro
that
you
forgot
to
mention
is
that
all
of
the
other
patterns
we've
talked
about
is
stuff
that
you
it's
not
it's
so
easy
in
this
kind
of
architecture,
the
event-based
architecture
to
retry,
something
if
it
fails
right,
but
on
the
other
hand,
if
you
don't
write
your
code
properly,
retrying,
something
maybe
very
dangerous,
because
you
might
end
up
paying
for
something
twice.
C
A
C
So
one
thing
I
thought
of
a
question
for
the
group,
so
we're
talking
about
mvc
and
mvc
is
a
pattern
that
can
be
implemented
both
on
the
back
end
in
servers
as
well
as
on
the
front
end.
We
were
talking
about
the
event-based
architectures,
which
is
a
pattern
that
can
be
implemented
both
on
servers
and
on
the
front
end,
but
I've
never
heard
of
flux
being
implemented
on
a
server.
Does
anyone
know
of
examples
or
libraries,
or
I
don't
know,
I'm
asking.
A
Rudy
knows
what
I'm
talking
about,
but
but
like
it's,
because
flux
again
is
to
solve
a
particular
problem
right.
It's
an
opinionated
way
of
doing
this
stuff,
which
doesn't
translate
to
server
side,
and
I
think,
on
that
point
like
there
was
a
question,
a
really
good
question
in
chat,
which
is
is
event
event
based
architectures
related
to
reactive
programming
and,
like
I
think
you
can
put
reactive
streams
on
top
of
events.
A
A
E
I
was
just
going
to
say
with
the
thing
architectures,
I
think
you
probably
have
to
be
very
disciplined
in
your
approach
to
when
you
fire
events,
because,
like
there's
some
serious
problems
that
you
can
have
like,
if
you
like
fire
an
event
and
then
that
triggers
this
event
to
be
fired
and
then
it
cycles,
I'm
sure
that
that
is
something
that's
probably
happened.
A
lot
to
anyone,
who's
ever
used,
event-based,
architectures
and
sucks,
and
so
yeah,
like
with
great
power,
comes
great
responsibility.
Basically,
yeah
really.
F
F
It's
the
artificial
new
one
that
we
don't
know
about
while
event
driven.
We
should
we
it
that's
how
the
the
web
works
like
it.
It
kind
of
feels
like
something
that
we
should
understand.
That
should
make
sense.
It's
just
we've,
never
actually,
or
most
people
have
never
like
used
it
in
in
their
everyday
programming
and
then
the
other
question
that
I
had
for
ryan
and
mike
because
of
the
event
best
driven,
which
I
don't
know.
If
ever
other
people
have
that
question,
but
I
know
the
difference.
F
A
A
C
A
Think
about
it.
Right,
like
it's
phenomenal
like
this,
is
the
pattern
that
you
use
when
you
get
to
the
point
where
you're
like
okay,
my
website
is
janky
and
slow,
because
I
can't
run
enough
javascript
fast
enough,
because
I've
got
one
thread,
I'm
going
to
take
the
next
level
and
when
you
know
you
need
to
take
that
next
level.
This
is
the
thing
that
you're
going
to
reach,
for
it
is.
It
has
to
be
because
that's
how
the
thing
was
designed.
E
A
E
E
Like
you
can
get
a
visual
of
how
everything
related
to
each
other
and
then
wondering
like,
I
was
kind
of
a
bit
of
a
noob
there,
and
I
wrote
everything
myself,
which
was
probably
done.
I'm
sure
that
there's
something
that
does
this
are
there
other
awesome
tools
that
you
can
use
for,
like
making
sense
of
chaotic
decisions.
A
Yeah,
they
definitely
are
not
necessarily
in
the
front
end
space,
so
not
like
javascript
and
stuff
that
you
can
use
in
the
browser,
but
but
like
that
car.
That
concept
is
the
idea
of
correlation
id
like
each
message,
having
unique
identifier
and
being
related
with
replies,
dancing
messages
and
blah
blah
blah.
I
think,
if
you
use
a
message
bus
like
grab
at
mq,
I
think
there's
some
other
visualization
that
happens,
and
there
are
tools
that
you
can
use
on
top
of
rabbitmq
to
visualize
load
messages.
A
Pro
tip
that,
where
the
more
useful
they
are
the
more
expensive
they
are
yeah,
because
it's
a
complicated
space
that
real
software
sits
in,
so
you'll
find
that
when
you,
when
you
reach
this
point
like
you're,
not
gonna
accidentally
reach.
This
point:
there's
not
going
to
be
a
beginner
tutorial.
That
gets
you
to
this
point.
When
you
are
there,
somebody's
probably
going
to
need
to
buy
something,
but
but
it's.
A
Cool
so
to
everybody,
that's
the
24
of
you
that
I've
stayed
on
for
the
hour
and
a
half
that
we've
argued
about
architectural
stuff.
I'm
impressed
that
some
serious
commitment
and
thank
you
very
much
for
listening
to
us
badly,
explaining
architecture
that
would
have
been
a
great
title
for
this
badly.
A
A
So
normally
we
would
tell
you
now
what
the
next
month's
session
is
going
to
be
about.
But
it's
it's
been
a
it's
been
a
week
right,
it's
it's
been
heavy
and
we
don't
have
any
ideas
for
next
month's
session.
So
if
you
folks
have
any
suggestions
as
to
what
you
would
like
to
hear
us
ramble
on
about
and
explain
badly
next,
please
put
them
in
either
the
chat,
if
you're
here
or
put
them
in
the
comments
below
and
we'll
we'll
try
and
grab
them
and
run
with
it
next
month.
C
So
quickly
before
we
say
goodbye,
I'm
wearing
my
microsoft
jacket,
so
I
just
I
just
want
to
say
the
azure
boot
camp
is
happening
at
the
end
of
september
on
the
30th
of
september,
and
if
you
have,
if
you
have
an
interest
in
azure,
please
go
to
azure
bootcamp.com,
submit
the
talk
or
just
attend.
It's
virtual.