►
From YouTube: Product Analytics stack state discussion
Description
Max, Rob & Jiaan (engineers in Analyze::Product Analytics) discuss the best way to expose the state of an initializing product analytics stack to the frontend.
A
Right
so,
let's
talk
about
onboarding
States
for
analytics
Stacks,
so
I
saw
the
problem
that
we
had
right
now,
as
once,
we've
initialized
the
stack
or
requested
that
we
initialize
the
stack
there's
no
way
of
knowing
what
state
that's
in
until
it
completes
successfully.
If
it
doesn't
complete
successfully,
it
takes
a
while
to
delete
successfully.
We
don't
get
any
feedback
about
that.
So
the.
B
B
We
if
we
don't
have
the
Jitsu
key,
but
someone
has
started
that
process.
We
don't
know
that
that's
finished,
so
if
they
refresh
or
go
somewhere
else
or
another
user
goes
on
and
clicks,
let's
start
the
product
analytics
process.
We
don't
know
like
that
that
started,
so
we
won't
show
them
the
currents
where
they
are
currently,
in
other
words,.
A
So
my
first
thought
was:
okay.
Well,
there's
just
there's
a
there's
a
plaster
here
we
can
stick
on
this
at
least
temporarily,
which
is
we
can
store
in
the
session?
Oh,
not
the
session
in
the
persistent
red
estate
that
that
project
has
had
it
initialized,
and
then
we
can
delete
that
key
from
redis.
Once
we've
got
either
a
positive
or
A
negative
response
from
that,
at
which
point
we'll
know
whether
it's
safe
or
not,
to
show
the
use
of
that
initialization
button
again
question.
B
A
B
A
So.Com
runs
multiple
redis
instances,
but
yeah
the
situation
that
you
describe
as
far
as
unaware
is
not
possible
and
Geo
as
well.
I
think
run
independent
retic
instances
for
different
locations,
I'm,
not
sure
what
they
call
them
zones
yeah,
but
again,
not
something
we
need
to
worry
about
for
this
yeah
we're
using
the
Reddit
shared
State
rather
than
the
session,
so
it
will
persist
for
as
long
as
we
tell
it
to
so.
That's
fine!
A
A
A
Well,
that's
good!
It
hasn't
bothered
you,
so
it
can't
be
too
bad,
so
yeah.
So
my
thing
is
right
because
putting
this
redis
key
add
it
before
we
enqueue
the
job
delete
it
once
the
job.
Oh
no,
delete
it.
Once
we've
received
a
response
and
I
think
from
what
you're
saying
you're
fine
with
that.
But
the
thing
that
we
don't
have
is
any
sort
of
connection
to
the
front.
End
yeah.
So
there's
a
few
different
ways.
We
can
tackle
this
number
one
weekend.
A
B
B
Go
go
in
the
conversation
that
we
I
had
with
yarn
on
the
other
issue,
which
I
think
is
linked
to
further
down.
We
found
documentation
that
mentions
about
it.
Yeah
they
go
halfway
down.
My
comment:
there's
a
link
to
comment,
116
blah
blah
blah
blah
and
then
and
then
docs
interacting
with
sidekick,
Reddit
and
apis
there's
a
whole.
We
don't
expose
any
of
that.
Basically,.
A
We're
not
using
psych
I,
don't
even
know
what
psychic
redis
is
because
no.
This
is
saying
that
we
shouldn't
interact
with
Sidekicks
low
level
rather
than
git
Labs
redis
connection,
so
yeah
we
shouldn't
we
shouldn't
be
interacting
directly
with
sidekick
and
how
about
deals
with
the
redness.
That's
a
different
problem.
Oh.
A
B
So
having
that
state
machine,
we
don't
need
to
store
the
state
on
the
database
level.
We
just
want
to
have
some
kind
of
endpoint
which
go
which
tells
us
where
we're
at
currently.
So
if
we
bring
up
that
redis
thing,
do
we
have
application
settings
which
would
actually
be
a
Hammel
check
anyway?
So
we
can
ignore
that.
Do
we
have
we
created
the
stat
or
is
the
stack
running
which
would
return
whether
we've
got
redis
or
not,
where
the
same
with
the
Jitsu
key
and
maybe
return
the
Gypsy
key.
A
B
Endpoint
anyway,
so
I'm
not
sure
about
the
one.
We
then
need
to
make
a
check
to
see.
If
Cube
has
any
data,
not
the
data,
we
just
need
to
know
whether
Cube
has
data,
because
then
that
tells
us
that
we're
going
to
get
that
the
dashboards
are
gonna
work.
If
that
makes
sense,
and
then
we
then
you,
then
we've
got
the
endpoint
that
you're
building
right
now
for
the
dashboard
widgets,
which
needs
to
be
its
own
thing
anyway,
because
as
soon
as
we
know,
Cube
has
data.
B
We
then
move
on
into
the
second
phase.
This
is
tile,
separate
applications,
two
applications
to
the
onboarding
application
and
then
they're
separate,
which
is
listing
and
viewing
dashboards,
so
that
we
can
probably
ignore
that
point
at
that.
At
that
point,
so
I
don't
know
I,
which
is
why
I
said
the
first
instance
having
that
redis
with
an
API
with
with
an
API
endpoint
is
fine,
but
we
could
also
make
this.
So
it
is
like
a
instant
statement,
a
check,
a
checker,
State
machine
I
know
it's
not
hard.
A
A
B
That's
right
for
now
we
don't
need
to
like
we
can
do
the
cube
with
the
front
end.
Can
query
Cube
yeah?
Obviously
we
don't
obviously
we're
skipping
a
middleman
by
having
the
back
end.
Do
it
for
us
a
round
trip,
but
we
can
do
that
and,
as
the
first
instance
to
keep
the
iteration
small
just
having
creating
that
redis
key
and
then
having
adding
it
to
an
exit
to
the
existing
project.
Endpoint
or
creating
a
new
endpoint
just
for
analytics
either
way.
I
feel
like
that's
yeah,.
A
I
agree,
I,
think,
yeah
and
that
we
can
have
a
status
object
which
allows
which
we
can
add
two
later.
Unless
you
know,
if
you
want
to,
and
that
can
be
a
it
can
be
a
type,
it
doesn't
have
to
be
linked
to
any
active
record
model
yeah.
It
might
just
create
a
ruby
class
as
well
to
handle
the
logic
figuring
that
stuff
out.
It's
all
in
one
place
and
easily
testable.
B
A
B
Could
have
which
don't
we
don't
necessarily
need
to
cover
every
one
of
them,
but
I
mean
you
can
start
off
with.
Do
we
have
project
settings?
Are
there?
Is
it
pronouns
is
DAC
enabled
so
that'd
be
that'd,
be
one
status
then
the
next
status
is
do
we
have
do
we
have
a
stack
at
all?
No
do
we
have
any?
Do
we
have
a
Jitsu
key?
No,
do
we
have
any
data
in
Cube?
B
A
B
A
B
A
B
B
A
B
A
That's
all
right:
we
recorded
it,
you
can
catch
it
later.
Oh
awesome,
we've
just
updated,
we
weren't
miles
off
I,
don't
think,
but
we
just
need
to
make
sure
how
we
were
exposing
that
in
the
best
possible
way
for
youth
frontenders
to
implement
it.
So
we're
going
to
add
a
new
graphql
type
production
status,
meta
which
for
now
we'll
just
hold
the
is
initializing
field.
So
you
can
tell
whether
or
not
we're
waiting
for
a
response
from
a
psychic
worker.
B
So,
for
starters,
the
whether
we've
got
dashboards
or
not
is
a
separate
State
entirely.
That's
got
nothing
to
do
with
the
stack,
that's
entirely
to
do
with
the
project
itself.
If
that
makes
sense,
so
I'd
probably
draw
the
line
at
that
one,
whether
we
have
dashboards
or
not,
because
that's
an
entirely
different
graphql
endpoint
anyway,
isn't
it
that
we
have
to
query.
If
that
makes
sense,
we've
got
to
query
that
to
find,
even
if
the
backend
did
it.
B
We
can
run
it
on
the
front
end,
at
least
for
the
first
iteration,
can't
we
and
then
improve
upon
that,
but
I
mean
first
iteration
of
this
implementation
plan
instance
in
this
sliding
we
will
discussed
no
project
instance
is,
would
just
be
that
their
status
is
initializing
as
false,
and
there
is
no
Jitsu
key
which
is
going
to
be
added
to
the
projects
graphql
input
out
anyway,
and
then
post
initializing
we
just
say:
do
we
have
a
Jitsu
key?
Don't
we
so
it
doesn't
matter
about
the
rest.
A
B
C
A
A
C
That's
what
I'm
saying
if
we,
if
we
do
all
the
State
Management
in
the
front
end,
then
we
don't
need
to
do
this.
Implementation,
like
the
the
the
thing
that
this
issue
is
trying
to
solve,
is
knowing
is,
is
trying
to
prevent
two
stacks
being
initialized
at
the
same
time.
Yes,
if,
if
the
backend
internally
can
tell
us
hey
thumbs
down
I'm,
not
going
to
initialize
it
because,
for
whatever
reason-
and
the
reason
in
this
case
is,
it
is
currently
busy
initializing
for
another
user
requested
this
or
whatever
right.