►
Description
Max, Jiaan and Rob (Analyze::Product Analytics) discuss product analytics stack initialization via GraphQL mutation
A
Better
right,
then,
so
this
is
part
two
of
how
are
we
planning
on
exposing
the
state
of
and
initializing
product
analytics
stack
to
the
front
end.
So
we
started
yesterday,
but
we
were
all
kind
of
under
time
constraints
and
I
think
we
got
a
bit
further,
but
I
don't
think
we
actually
nailed
down
an
actual
solution.
So
I'll
show
my
screen
and
hopefully
we
can
begin
to
collaborate
on
something.
C
The
main
thing
that
we're
trying
to
solve
is
we're
trying
to
Black
stop
the
initialize
job
from
running
successfully
more
than
once.
That's
like
at
its
core.
That's
really
what
this!
What
this
issue
is
about,
also
that
spring
sprinkle
in
some
I
guess
past
experience
and
advice
about
like
how
the
State
Management
can
be
done
easily,
because
I've
seen
it
work
quite
nicely
where
you
basically
have
this
and
I
call
it
this
simple
State
machine,
but
it
really
doesn't
have
to
be
a
proper
State
machine.
C
I've
seen
it
work
both
without
and
with
where
you
just
have
a
method,
and
that's
what
I've
thought
we
could
get
started
with,
but
the
implementation
plan
that
you
guys
have
here
I
think
would
work
I.
Think
it's
still
open
to
the
edge
case
that
we're
blocking
it
in
the
front
end
only
and
not
in
the
back
end,
because,
presumably,
which
we'd
be
able
to
call
it
back
in
VSM
API
and
without
the
backend,
having
checks
in
place
to
actually
block
that
initialization
job
from
ever
starting.
C
So
we
don't
need
like
that
would
be
the
most
simplest
boring
solution
in
my
mind
as
a
first
iteration,
where
we
only
block
it
in
before
we
call
initialization
service
the
front
ends.
Experience
would
be
that
if-
and
this
is
on
the
rare
occurrence,
that
if
a
job
is
running
and
they
land
on
that
page
and
I
click
that
button,
they
would
get
an
error
which
I
think
would
be
perfectly
reasonable
and
the
error
could
be.
C
C
A
B
A
A
C
A
What
happens
if
you
initialize
the
job
you
in
queue
the
job
the
job
hasn't
been
executed
for
10
20
seconds,
there's
no
way
of
knowing
right,
so
it
should.
You
should
do
it
once
it's
enqueued,
because
then
you're
saying
hey
right,
the
job
is
going
to
happen,
even
if
it's
not
happened
yet.
We
know
it
it's
going
to
happen,
hopefully
fairly
soon,
but
there's
no
guarantee,
especially
for
self-manage,
that
that
will
happen
incredibly
fast.
So.
B
A
C
C
A
So
I
think
the
thing
you're
referring
to
there
is
the
documentation
says
not
to
not
to
fiddle
about
with
psychics
own
redis
implementation
because,
like
essentially
uses
redis
quite
heavily,
we're
not
doing
that
we're
using
gitlab's
shared
Reddit
state
which,
as
far
as
I'm
aware,
is
fine
to
access
as
part
of
a
worker.
What
we
can't
do
is
write
a
sidekick.redis
command,
which
then
goes
in
and
manually
Alters.
The
queue.
C
C
A
Yeah,
so
that's
why
so
redis
allows
you
to
set
the
key
with
a
timeout,
so
we
can
set
the
key
and
say
sorry,
not
a
timeout,
an
expiration,
so
the
T,
the
key,
is
automatically
deleted
after
a
certain
number
of
minutes,
but
we'd
have
to
set
that
quite
High
which
could
be
annoying
if
you've
run
the
job.
You
know
it's
failed
for
some
reason
and
there's
nothing
you
can
do
about
it.
C
C
B
I
am
happy
to
do
this
as
an
initial
approach.
My
thinking
with
this
issue
was
to
fold
one
preventing
someone
from
rerunning
the
job,
but
two
also
from
to
know
on
the
front
end,
whether
in
which
state
we're
in
to
show
the
loading
screen
for
the
initialization
state.
If
we
know
that
we're
initializing,
which
we
would
know
from
the
redis
key
or
whether
to
show
the
you
haven't
done
anything
about
this,
yet
do
you
want
to
set
this
up?
B
B
Yeah
I
guess
well,
we
have
to
it
just
won't
very
be
very
ideal
from
a
user
experience
perspective,
that's
all
but
I
guess
for
initial.
It's
fine
in
terms
of
a
longer
term
idea
of
a
state
machine.
We
need
to
have
a
conversation
about
that.
Just
because
we've
built
half
the
apis
already
for
a
lot
of
what
the
state
machine
is
going
to
query
which
might
end
up
being
redundant
and
whether
how
we
want
to
handle
that.
But
that's
a
future
us
conversation.
C
But
that
does
bring
up
like
why
I
suggest
that
the
state
machine
or
a
simple
version
of
it
at
this
stage
is
because
yeah.
This
is
something
that
I've
seen
really
simplifies
an
onboarding
process
from
the
start
yeah.
It
is
something
that
we
can
iterate
on,
because
it
is
not
the
most
boring
solution,
but
you
know
the
most
important
solution.
Isn't
always
the
most
sensible
one.
Let's
say
it's
it's
it's
it's
it's
a
good
rule
of
thumb
to
think
about,
but
you
know
it's
not
something
we
need
to
follow
like
or
a
holy
book.
A
A
So
it
kind
of
depends
what
you
guys
want
on
the
front
end
to
be
available
in
the
first
iteration.
If
you
just
want
an
error
where
someone
can
hit
that
button
as
many
times
as
you
want,
and
it
just
doesn't
work,
that's
fine.
We
can
just
return
an
error
in
the
API
I'm
trying
to
think
now.
Is
there
currently
an
API
that
allows
you
to
initialize
the
stack
or
does
that
only
happen
in
the
console.
A
C
Yeah
I
mean
that
makes
that
that
makes
sense
to
me,
like
my
my
suggestion
that
I
have
like
at
on
on
this
call
and
at
the
end
of
yesterday's
call,
is
really
just
following
what
I
feel
like
the
implementation
plan
that
you
guys
came
up
with,
is
just
to
try
and
simplify
this
as
much
as
possible
for
a
first
iteration.
So
my
thinking
is
kind
of,
like
you
know,
can
we
simplify
this
even
further
I'm,
still
very
much
in
favor
of
going
the
state
machine
route?
A
That
that's,
where
I'm
leaning,
because
we
want
to
like
the
state
machine,
is
going
to
take
longer.
There's
going,
you
know
it's
going
to
be
a
a,
not
insignificant
amount
of
work,
whereas
what
we've
just
discussed
will
be
possibly
something
I
can
get
in
review
by
the
end
of
this
week,
which
would
be
nice.
B
From
my
perspective,
I
do
want
to
eventually
see
a
state
machine.
I
think
the
state,
the
state's
defined
so
far
in
the
as
in
the
issue
are
too
far
the
disabled,
you
just
you,
wouldn't
we
wouldn't
render
the
page
in
the
first
place
and
that's
a
Hamill
check,
whether
it's
disabled
or
not
right.
Now
we
don't
we.
We
don't
render
anything
if,
if
it's
disabled,
there's
no
menu
item,
there's
nothing
it's
a
404,
so
there's
no
need
for
that
to
be
in
the
state
machine
and
the
no
dashboards.
That's
where
it
goes
too
far.
B
In
my
opinion,
because
we
move
on
from
onboarding
into
a
completely
separate
API
structure,
which
is
the
listing
concept,
which
is
a
graphical
endpoint
anyway,
but
the
whole
do
we
have
an
instance.
Are
we
creating
the
instance?
Do
we
have
any
data
that
the
other
three
things
at
the
back
end
is
best
able
to
handle
and
that's
where
a
single
sort
of
Truth
starts
to
come
in
for
me,
but
to
do
that,
first
and
foremost,
we
need
to
have
this
redis
key
anyway.
B
So
having
this
having
a
redis
key
as
a
first
point
of
call,
with
a
404
with
an
error
on
the
front
end,
if
you
try
to
make
this
call
via
the
API
works
for
me,
we
can
then
create
that
state
machine
to
then
check
to
see
check
these
queries
on
the
front
end
as
the
next
step.
If
that
makes
sense,
do
we
have
are
we
do
we
have
an
instance
at
all
created?
No,
do
we
have?
B
C
B
A
Next
Step,
it's
not
as
of
now
the
first
step.
Is
this
reddish
key
there?
We
need
that
anyway,
to
be
able
to
do
the
state
machine,
so
we
might
as
well
get
that
in
and
do
what
you
suggested
with
the
simplest
thing
of
creating
that
error.
If
someone
tries
to
hit
that
API
endpoint
just
occur
at
all,
then
we
can
move
on
the
next
step.
B
After
that
it
says
you
suggest
going
into
that
state
machine
too,
because
we
still
need
to
add
the
Jitsu
key
anyway
for
us
to
be
able
to
create
all
these
different
screens
and
tie
them
together
using
the
router.
Don't
we
on
so
we
still
there's
still
work
back
in
work
to
be
done
on
top
of
just
a
redis
key
right
now,
okay,.
A
B
A
A
A
Yeah
so
I
I
guess
this
would,
but
this
mutation
would
it's.
Its
only
purpose
would
be
to
attempt
the
initialization
of
the
products
analytics
stack
and
it
would
return
I
guess
the
current
state,
which
in
this
case
would
either
be
it's
already
initializing,
so
I've
not
done
anything
or
I've
been
queue,
the
job.
That's
all.
It
would
be
aware
of.
At
that
point,.
A
There's
no
reason
that
afterwards
we
couldn't
create
a
meta
type
like
we've
got
here
or
a
status
type
or
whatever
it's
called,
which
would
then
combine
all
that
information
and
say:
hey
bro
right
now.
I
know
the
state
is
that
it
is
initializing
all
that
it
is
not
currently
initializing.
All
that
has
been
created,
for
example,
that
would
be
fine
again,
I,
don't
know
if
we
can
technically
call
it
a
state
machine
because
I'm
not
storing
the
state
explicitly
anywhere,
but
we
can
in.
We
can
infer
it
from
the
other
information.
We've
got.
B
B
C
C
C
C
A
A
B
No,
we
front
end
wise.
We
need
to
capture
the
fact
that
we
need
to
return
an
error
on
the
screen,
so
I'll
update
the
issue
for
the
creation
screen
to
reflect
that
we
need
to
make
sure
that
we
render
any
errors
from
the
API
and
then
we
need
to
I
guess
refine
what
we
want
to
show
in
this
next
iteration
the
state
machine
process.
So
that's
a
future
problem.
Us,
okay,.