►
From YouTube: 3/16 hyper63 TSC Meeting
Description
hyper63 technical steering committee meeting
* Discussion RFC 008 Queue Service
https://github.com/hyper63/hyper63/discussions/161
A
A
A
A
A
B
A
A
Okay,
so
again
thanks
tripp
and
tyler
for
taking
a
look
at
this
on
friday.
Just
some
background
on
the
q
service,
the
the
q
service
is
kind
of
focused
at
this
point,
but
basically
one
of
the
projects
that
I've
been
working
on
we
were
building
the
api
in
a
server-less
environment
using
versel
and
part
of
the
api
is
to
run
through
a
rules
engine
and
then
return
some
results
back
from
that
rules.
Engine
that
are
matches
right
there
there
are
matches
for
the
submitter
to
review.
A
Then
at
you
know,
kind
of
an
asynchronous
point
of
view.
There's
a
hooks
interface
where
all
of
the
entities
or
partners
that
have
been
matched
need
to
get
notified
via
some.
You
know
kind
of
web
hook
to
to
like
salesforce
or
something
like
that.
So
so
it
kind
of
generates
a
lead
or
a
message
to
them,
and
so
the
the
api
that
sits
in
front
of
hyper
has
this
hooks
interface
on
serverless,
which
was
working
great
except
for
serverless.
Once
you
return
your
response
back
to
the
client,
it
kills
the
process.
A
You
know
at
least
five
kind
of
hooks
set
five
to
six
kind
of
hook
set
when
this
rules,
engine
processes
and
returns
result.
It
needs
to
put
a
message
somewhere.
That
then
gets
invoked
and
actually
five
messages.
If
you
will
that
get
invoked
at
a
later
time,
and
so
that
the
you
know
request
can
can
not
be
a
long
running
request
when
the
rules
engine
runs,
it
returns
back
and
then
those
five
or
six
requests
can
happen
in
a
background
kind
of
process.
A
So
so
I
kind
of
just
put
up
there,
based
on
some
of
the
the
feedback
that
you
know
we're
just
we're
not
trying
to
be
the
you
know,
push
pull
pub,
sub,
end-all,
be-all
kind
of
queue,
service
really
focused
on
kind
of
a
worker
q
service
or
some
people
call
it
a
push.
Q
service,
but
one
of
the
things
is
is
that
we
want
to
use
hyper
to
abstract
all
the
complexity
away.
A
So
it's
it's.
You
know
they
don't
have
to
manage
servers,
they
don't
have
to
think
about
redis
and
think
about.
You
know
I
need
to
install
workers
and
manage
that
etc.
They
really
just
have
a
rest
interface
and,
and
then
the
the
other
side
is,
is
for
right.
Now
it's
mainly
focused
around
short
tasks.
A
You
know
like
sub
three
minutes,
not
long
running
tasks
and
and
then
the
last
thing
is,
is
it's
not
a
scheduling
service?
So
it's
really
just
focused
on
you
know,
handling
kind
of
these
background,
fetch
or
api
calls.
If
you
will
and
then
I
kind
of
broke
down
some
some
background,
you
know
what
is
a
cue
feel
free
to
edit
any
of
that
kind
of
stuff.
A
What's
a
task
or
a
job,
and
basically
I
kind
of
use
task
and
job
interchangeably,
but
but
basically
it's
a
it's
a
document
that
contains
instructions
for
some
process
to
use
to
do
something
it
could
be
send
an
email
could
send
a
text
it
could
be
to
make
a
web
service
call,
etc.
It's
just
a
a
json
document
and
then
kind
of
go
in
and
explain
what
is
a
work
or
task
queue
and
and
basically
the
the
best
way.
I
can
explain
it
is
in
any
queue
process.
A
The
producer
creates
the
job
which
pushes
it
on
a
queue,
and
there
could
be
one
to
many
consumers,
but
the
broker
will
only
assign
one
job
to
a
consumer
and
then
that
consumer
will
tell
the
broker
when
it's
done,
and
then
it
can
receive
another
job.
So
so
there
will
never
be
like
that.
One
consumer
receiving
a
multiple
jobs
concurrently,
but
you
could
have
10
consumers
running
and
then
the
broker
could
take
10
jobs
and
submit
those
to
those
10
consumers.
If
they
were
all
available.
A
A
A
A
A
So
when
a
job
gets
posted,
there
will
be
a
a
worker
running
inside
hyper
63
and
that
worker
will
use
this
url
to
send
the
job
to
to
the
outside
world
and
then
the
secret
and
this
secret
could
be
optional.
But
basically
what
it
would
do
is
create
a
json
web
token
using
that
secret,
so
that
when
the
recipient
of
this
job
they
can
verify
the
token
to
make
sure
that
this
job
actually
came
from
hyper
63..
A
A
Well,
I
can't
find
it,
but,
but
basically
it's
going
to
use
an
encrypted
field
that
matches
the
current
standards
of
encrypting
encryption
for
for
a
password.
So
so
when,
when
the
queue
is
created,
that's
kind
of
a
one-time
thing
and
it's
also
item
potent.
So
what
that
means
is
the
client
can
call
it
many
times
and
as
long
as
it's
the
exact
same
name,
it's
just
going
to
return.
Okay,
it's
going
to
return!
Okay,
it's
like!
A
Then
the
second
command
is
post
job,
so
the
client
will
post
to
the
queue
and
in
that
post,
job
they're
going
to
send
their
data.
So
so
there's
no
really
at
this
point
required
attributes
there.
All
of
the
required
attributes
like
a
job
id
and
all
of
those
kinds
of
things
will
be
kind
of
behind
the
scenes.
A
Just
because
each
kind
of
q
service
could
have
different
semantics
and
we
want
to
abstract
those
away
from
the
client.
They
should
just
post
the
data
that
they
want
to
to
work
on,
and
then
we
can
deal
with
the
rest
of
the
documents
that
that's
required,
whether
it's
rabbit,
mq
or
sidekick,
or
celery
or
bq.
B
Sense
so
quick
question
as
far
as
like
the
system
of
record
for
the
jobs
like
the
like
the
queue
is
the
idea
here
to
just
like
build
adapters
around,
like
let's
say
like
sqs.
That's
like
a
common
one
to
where
like
hyper
63
is,
is
hyper.
63
meant
to
be
the
system
of
record
for
the
for
the
pending
jobs,
or
it's
just
purely
just
an
abstraction
over
something
like
sqs.
A
Yeah,
I
think
each
adapter
would
be
able
to
make
that
decision
right.
So,
for
example,
the
the
bq
adapter,
the
system
of
record
would
be
redis
and
the
q
service
kind
of
sits
on
top
of
redis
and
then
hyper
63
is
just
really
just
keeping
the
abstraction,
simple
and
also
running
a
worker
or
one
or
more
workers
right
in
in
the
background
so
and
I'll
try
to
explain
that
a
little
bit
more
but
then
with
sqs.
A
A
So
you
know,
for
whatever
reason
there
may
be
unprocessed
jobs,
so
they
could
call
that
and
say.
Let
me
find
all
the
jobs
that
haven't
been
processed
yet
or
there
could
be
dead
jobs
or
there
could
be
unprocessed
or
or
I
might
want
to
cancel
an
unprocessed
job
right.
So,
for
whatever
reason
you
know,
I
was
supposed
to
send
five
of
these
things
out
and
the
user
doesn't
want
to
send
any
more
out.
A
A
A
So
that's
why
I
opted
for
kind
of
the
rest
operation,
semantics
and
I
don't
know
if
it's
a
standard
unrest,
but
I
have
seen
it
out
in
the
wild
with
fire
and
couchdb,
so
it
is
used
to
deal
with
operations
that
don't
fit
the
crud
process
and-
and
I
actually
use
it
to
do
like
query,
commands
and
and
other
operations,
I'm
cool
with
it.
Okay,.
C
B
D
B
B
A
A
B
A
A
B
And
so,
if
I
wanted
to
okay,
so
that
sort
of
lends
itself
to
the
question
I
had
earlier
around
like
what
the
system
of
record
is.
So
if
I
wanted
to
cancel
an
unprocessed
job,
it
would
be
hyper
63's
job
to
not
to
overload
the
term
job.
It
would
be
hyper
63's
responsibility
to
find
that
job
on
whatever
the
system
of
record
is
and
get
rid
of
it
before
a
worker
picks
it
up.
A
B
A
A
B
Yeah,
it's
it's
cool.
It's
interesting.
I
mean
with
this
scenario
the
client
could
decide
what
sort
of
schema
they
use
for
like
job
payloads
correct.
So
I
don't
I
don't.
I
don't
know
why
you
would
do
this,
but
perhaps
you
have
a
use
case
for
it
where
your
job
handlers
like
a
graphql
server,
you
could
create
jobs
where
the
payload
is
a
graphql
mutation,
then
hyper
63
would
just
post
that
to
the
endpoint
that
you
provide
when
you
created
the
queue
which
would
just
be
a
graphql
server,
and
that
would
be
so.
A
Yeah,
absolutely
there
should
not
be
a
problem
with
that
and
there's
nothing.
You
know
nothing
saying
that
that
your
endpoint
has
to
be
the
client
api
right.
It
could
be
twilio
or
it
could
be
mel
gun
right.
So
you
could
just
create
your
cue
and
say
you
know,
here's
the
stuff.
You
need
to
send
to
mel
gun.
A
B
A
A
A
We
talked
about
scoping
it
up
at
a
higher
level
and
have
like
a
hooks
crud
interface,
and
I
think
yeah
other
than
it
will
be
interesting
to
see
when
we
have
kind
of
both
those
pieces
how
how
they
can
interact.
But
but
I
I
haven't,
given
it
a
lot
of
thought
other
than
the
fact
that
users
of
hyper
63
could
use
this
q
service
to
push
messages
in
a
century
or
or
some
other
service,
mainly
for
tracing
their
apis.
A
A
B
B
A
A
B
D
A
A
A
A
A
So
what
will
happen
is
when
they
submit
the
form
it
will
run
through
the
rules
and
assign
them
to
the
event
and
then
respond
back
to
the
user
and
says
hey
you're,
registered
here's
your
schedule.
Thank
you
for
choosing
to
attend
this
conference
and
then
behind
the
scenes
for
each
one
of
those
sponsors.
A
A
A
A
A
A
C
A
Yeah
yeah
and
that's
a
good
segue
on
the
client,
so
looking
at
some
other
similar
services-
and
you
know
one
one
service
in
particular
basically
came
up
and
said:
you
know
what
we're
deprecating
our
client,
here's
our
rest
api
and
just
use
it
and
I'm
curious
to
see
what
your
thoughts
are.
I
mean
I
created
a
client
and
it's
very
opinionated
in
terms
of
functional
programming,
but
you
know
I.
B
B
I
mean
I
do
think
there
will
be
some
really
common
patterns
that
emerge
out
of
how
users
consume
the
different
ports
like.
I
would
send
some
data.
I
also
want
to
cache
it,
and
I
also
want
to
index
it,
and
that
seems
like
such
a
such
a
common
pattern
and
I
think
folks
might
want
to
have
something
that
they
can
just
plug
and
play.
D
B
And
there's
like
a
bunch
of
utilities
that
users
like
just
create
in
the
open
source
domain,
and
I'm
thinking
I
don't
know
you-
have
like
a
store,
search
and
cache
like
sort
of
utility
and
then
you
can
compose
that
with
a
bunch
of
other
utilities
and
you
kind
of
build
your
own
clients
but
they'd
be
sort
of
like
not
fully
featured
they'd,
be
like
you'd.
Do
one
specific
thing.
E
A
B
I
think
we
could
have.
Maybe
we
could
have
some
sort
of
instead
of
building
a
client.
We
build
one
of
those
plug
and
play
things
and
it
implements
an
api
and
then
just
say
hey.
If
you
want
to
do
this
sort
of
thing
like
just
implement
this
api
and
then
use
a
tool
like
ramda
to
compose
them
all
together
or
like,
and
then
all
we
have
to
maintain.
B
A
E
B
Yeah,
I
mean,
because
I
mean
I
guess,
it'd
be
very
similar
to
how
our
adapters
work
as
well,
because
when
I
was
putting
together
the
pattern
for
how
to
compose
adapters
like
the
first
place,
I
looked
was
like
how
roll-up
does
it
and
that's
where
I
got
the
idea
for
sort
of
the
life
cycle
for
the
adapters
or
the
plug-ins.
I
should
call
them,
and
so
I
figure
building
a
client
would
work
very
in
a
very
similar
way
and
it
would
prevent
us
from
having
to
maintain
our
own
client
in
a
bunch
of
different
languages.