►
From YouTube: hyper TSC Meeting Aug 10 2021
Description
In this technical steering committee meeting we discuss the progress made over the last two months and show some of the hyper cloud architecture and dashboard UX. We also discuss adapters and plugins for hyper
For more information check out
website - https://hyper.io
github - https://github.com/hyper63/hyper
contact - info@hyper.io
twitter - @_hyper_io
A
Cool
welcome
everybody.
It
has
been
some
time
since
we
last
met,
and
mainly
due
to
my
scheduling
through
through
the
last.
You
know
six
six
weeks.
I
know
everyone's
been
hard
at
work
and
you
know
we
are
nearing
the
end
of
summer.
School
is
starting.
Things
are
starting
to
become
more
normal,
which
is
good,
but
after
the
pandemic
we
just
had
a
huge
list
of
travel
requirements
which
was
fun
but
but
yeah
it
made
it
tough
to
nail
down
schedules.
A
A
We
made
the
decision
to
migrate
to
dino,
and
we
were
just
talking
earlier
that
you
know,
even
though
dino
is
still
early
days,
some
of
the
things
or
challenges
that
we're
running
into
the
node
side.
We
don't
have
those
challenges
on
dino
dino
has
linting
built-in
formatting
built-in
testing
built
in
so
all
of
those
are
just
non-decisions
that
we
have
to
make
and
super
easy
to
implement
in
ci,
cd
and
yeah.
I
think
overall,
we've
been
really
pleased
with
dino.
A
It
was,
you
know,
kudos
to
tyler
for
really
knocking
out
the
core
migration
and
we've
all
been
kind
of
working
through
the
adapters,
and
you
know
if
you
know,
as
as
we
test
them
as
we
move
on
this
cloud
project,
it
feels
really
solid.
The
the
adapters
feel
solid
dino
feels
solid,
at
least
from
my
point
of
view,
tyler
any
comments
or
or
thoughts
from
the
migration
standpoint.
B
I
I'd
second,
all
of
that
there
was
a
bit
of,
I
think.
The
biggest
challenges
with
dino
was
some
of
the
like
native
apis
and
the
node
ecosystem,
like
in
particular,
streams,
are
handled
differently
in
dino
and
then
so
that
had
to
be
reconciled
and
then
just
finding
like
dependency
matchups
like
for
certain
adapters
that
use
a
client.
We
had
to
find
something
that
we
could
a
similar
client
on
the
dino
front
or
kind
of
roll
something
of
our
own.
C
A
C
I
think
so
for
the
dynamodb
adapter,
then
it's
possible
that
the
or
at
least
the
version
of
it
now
I
know
the
time
you
talked
about
a
different
one
when
it's
doing
the
the
crypto
hashing
to
get
the
id,
it
would
probably
require
a
different
function.
I'm
assuming
the
web
crypto
does
cryptographic
hash
functions.
Yes,
okay,.
A
Yeah
yeah
the
the
hashings
pretty
solid
and
like
they
just
added
kind
of
the
a
symmetric
encryption
where
you
have
your
you
can
generate
public
private
keys
for
different
crypto,
algorithms
and
and
sign
and
verify
all
those
things,
but
I
haven't
played
around
with
it.
Yet
I
was
very
excited
to
see
it
released
and
it
cited
that
it's
following
the
web
api.
A
I
really
like
dino's
move
there,
because
mdn
has
great
documentation
on
that
and
it's
it's
nice
to
be
able
to
go
to
mdn
and
get
documentation
on
on
things
like
that
and
they
work
in
dino
out
of
the
box.
So
that's
really
the
dino
migration
as
we
started
to
design
and
we
went
through
a
pretty
pretty
good
design
process
with
hyper
cloud
hyper
cloud
dashboard.
A
A
It
was
kind
of
interesting
documentdb
is
a
mongodb
api
compliant
service,
but
then
there's
mongodb
atlas
service
and
we're
building
to
mongodb
and
so
far
documentdb
is
holding
up.
But
if,
if
we
do
run
into
any
challenges,
we
we
are
prepared
to
move
to
atlas,
but
so
far
other
than
a
couple
of
headaches
for
tyler.
I
think
we've
we've
done.
Okay,
do
you
agree,
tyler,
yeah
and
then
elastic
search
for
our
search,
adapter
and
elastic
cache,
the
reddest
version
for
our
cache
adapter.
So
that's
that's
pretty
cool!
A
A
It's
incredible
and
then
the
other
thing
one
of
our
customers,
citybot,
uses
hyper
and
also
has
this
need
for
crawling
documents,
and
we
created
a
new
port
called
a
crawler
which
basically
is
an
api
to
allow
you
to
crawl
websites
and
with
that
api
there's
an
adapter
that
I
called
spider
that
that
actually
does
the
the
job.
So
basically
you
say
you
know,
find
me
all
the
pages
for
hyper.io
and
then
within
each
one
of
those
pages.
It
creates
a
a
tree
of
all
the
pages
based
on
a
depth
level.
A
So
so
this
recursive
tree,
which
kind
of
falls
into
an
array
and
then
for
each
one
of
those
pages.
It
actually
uses
a
tool
called
puppeteer
that
runs
a
browser
and
you
can
actually
execute
javascript
on
each
one
of
those
pages
to
pluck
data
from
it.
Hence
the
the
spyder
process-
and
I
I
don't
know
how
many
people
will
be
excited
about
that.
A
But
but
I
was
really
glad
to
see
that
come
around,
especially
for
for
citibot
who
works
with
government
sites
and
extracts
information
to
create
a
search
engine
so
that
you
can,
you
know,
text
and
say
when's
recycle
day
or
please
come
pick
up
this
trash
stuff
like
that
via
the
text
which
is
really
cool.
But
anyway,
that's
a
new
port
went,
went
through
the
process,
all
in
dino
land
and
and
it
wasn't
too
bad.
A
There
was
a
a
couple
of
places
where
I
you
know
forgot
about
on
on
the
core
to
to
hit
and
all
right.
The
the
good
thing
is
is
our
test
framework
kind
of
directed
me
to
those
places
where
the
missing
bits
were,
which
which
is
a
good
sign,
that
we've
got
some
good
kind
of
unit,
slash
integration
test
in
there,
that's
very
kind
of
focused.
A
A
So
we've
got
that
documented
at
least
started,
and
I'm
giving
a
api
workshop
tomorrow
really
focused
on
kind
of
a
starters
guide
api
hour
workshop,
but
hopefully
that
goes
goes
well
and
yeah.
That's
it
for
me
I'll,
pass
it
over
to
tyler
to
talk
a
little
bit
about
the
hyper
cloud
architecture
and
how
we've
kind
of
really
made
this
product
to
to
be
able
to
scale
as
automated
as
possible.
B
B
That
are,
some
of
them
are
outlined
here,
I'll,
just
gloss
over
them
really
quickly.
We
wanted
something
that,
given
that
we're
a
team
of
three,
we
don't
want
to
be
messing
with
our
infrastructure.
We
don't
want
to
be
messing
around
with
with
devops
a
whole
lot.
We'd
like
something
that
we're
able
to
sort
of
set
up
and
kind
of
depend
on
to
run
are
to
do
things
like
provision
or
infrastructure
or
like
promote
through
environments.
Things
like
that,
so
the
less
sort
of
devops
stuff
at
this
stage,
the
better
for
us.
B
B
B
So
copilot
is
it's
a
cli,
that's
built
on
top
of
ecs,
which
is
the
elastic
elastic
container
service,
then
aws,
and
it
does
a
lot
of
things
out
of
the
box.
It
basically
gives
you
a
cli
for
building
applications
on
ecs
with
sensible
defaults
and
has
a
way
to
push
those
provision
that
infrastructure
push
environments
and
then
promote
through
those
environments
all
through
the
cli.
B
So
it's
it's
pretty
great,
so
we
ended
up
going
with
aws,
co-pilot
and
deploying
all
of
our
stuff
on
ecs
and
then
using
fargate
for
our
container
for
our
container
fleet.
I
guess
I
would
call
it,
but
that
leaves
all
of
our
that's
up
for
all
of
our
backend
services
and
then
for
our
front-end.
We
ended
up
settling
on.
B
Of
course,
we
want
to
use
aws,
so
we
were
like
s3
and
cloudfront,
but
the
less
we
have
to
deal
with
that
stuff
directly,
the
better
and
so
what
we
ended
up
going
with
was
a
tool
called
architect,
which
is
a
tool
that
tom
is
familiar
with
and
he's
used
and
likes
it
a
lot.
Basically,
it
just
is
another
cli
that
we
can
use
to
build
out
our
application.
B
It
can
be
used
to
build
out
it's
just
lambda
based
applications,
all
behind
api
gateway,
we're
using
it
in
particular
to
build
out
our
front-end,
that's
built
on
top
of
sveltkit,
which
supports
the
static
content
and
then
as
well
as
a
lambdas.
So
if
you're
familiar
in
the
react
world
like
with
next.js,
it.
D
B
B
B
Of
like
oh
of
a
publicly
exposed
web
service,
which
copilot
sets
up
the
alb,
it
deploys
the
containers
into
public
subnets
across
availability
zones
for
us,
and
then
it
hooks
into
a
service
discovery.
So
aws
cloud
map.
For
so
our
service
can
talk
to
each
other
within
the
vpc
and
then
the
backend
and
then
copilot
defines
like
a
backend
service
which
is
basically
the
same
thing.
It's
just
not
exposed
on
the
public
internet.
B
So
it's
not
hooked
into
an
alb,
but
they
can
still
use
service
discovery
to
talk
to
each
other
and
whatnot,
and
this
is
all
deployed
in
a
vpc
and
on
ecs.
So
we
went
through
a
couple
different
approaches.
I
won't
go
through
each
of
them
on
what
we
would
actually
what
would
be
the
deployables
where
we
ended
up.
We
went
through
like
okay,
just
containerized
everything.
B
But
then,
after
a
conversation
with
tom,
what
we
decided
on
is
that
we
should
just
do
the
ultimate
dog
food
and
just
use
cloud
that
hyper
itself
to
build
out
the
dashboard.
So
there's
sort
of
a
chicken
in
the
egg
sort
of
dynamic
there.
But
we've
we've
figured
out
how
we're
going
to
do
that
and
where
we
ended
up.
B
D
B
B
All
of
those
we
have
set
up
add-ons
inside
of
copilot,
which
is
effectively
little
bits
of
cloud
formation
and
copilot
takes
care
of
aggregating
all
that
together
and
deploying
that
as
a
stack
inside
of
cloud
as
a
nested
stack
inside
of
cloud
formation,
it
handles
things
like
permissions
and
attaching
managed
policies
to
our
ecs
task
roles
for
security,
so
everything's
bundled
up
in
copilot,
and
this
makes
our
ci
really
easy
because
then
any
merge
any
code,
that's
merged
can
just
be
deployed
all
using
copilot
and
no
additional
tooling.
So
it's
really
nice.
B
B
B
Tyler,
correct
yeah,
that's
a
good
thing
to
highlight,
so
everything
is
set
up
with
auto
scaling
policies,
as
you
said,
with
architect,
it's
just
servalicious
scales
to
the
moon
and
then
with
ecs.
We
have
scaling
policies
based
on
cpu
utilization
that
and
that
gets
set
up
on
the
ecs
task
definition.
So
if
traffic
to
a
dcs
a
service
deployed
on
acs,
the
cpu
hits
a
certain
amount,
it'll
automatically
auto
scale
out
and
then
autos
go
back
down
when
traffic
dies
down
and
that's
all
set
up
through
copilot
as
well.
A
And
I
think
one
key
point
which
you
know
gave
tyler
a
lot
of
props,
because
this
was
a
super
hard
problem
to
solve.
But
with
this
architecture
there
is
a
clean
loose
coupling
between
what
is
aws
copilot
and
aws
infrastructure
and
what
is
hyper
core
so
that
we
can
continue
to
develop
hyper
core
completely
open
source
and
the
boundary
between
that.
B
B
D
Excellent
well
then,
we'll
get
started
so
I
took
some
screenshots
of
the
new
hyper
developer
dashboard,
that's
currently
in
in
progress
and
flight
tyler,
and
I
have
been
working
on
this.
I've
been
mainly
focused
on
the
the
ui
and
requirements
for
it.
So
let's
walk
through
some
of
the
pages,
so
this
is
first
is
sign
in
sign
up
so
right
now
a
user
can
sign
in
using
their
github
account.
D
D
Well,
there
may
be
a
limit
on
teams.
My
memory
fails
me,
but
once
you
switch
over
to
to
a
team,
the
avatar
will
change.
You'll,
see
your
link
to
your
your
relationship
and
your
link
back
to
your
user
account
here
within
the
avatar
for
your
account
and
then
your
applications
will
be
displayed
for
that
team.
D
You'll
have
the
ability
to
to
see
what
level
you
are
on,
whether
if
you're
on
a
paid
level
or
a
free
level.
So
in
this
example
it's
a
free
level
and
that
they
have,
as
you
know,
three
applications
and
right
now,
they're
at
their
limit.
They've
used
all
other
hyper
apps
in
this
case,
so
they
have
the
opportunity
to
prompt
to
go
to
a
paid
account
if
they
wish.
D
Yeah
so
you're
at
the
free
level,
and
you
can
go
to
a
paid
account
if,
in
this
case
we
have
a
a
team,
account,
that's
a
pay
at
the
paid
level.
It's
a
paid
account
at
the
startup
level,
so
we'll
have
different
tiers
of
paid
accounts,
and
in
this
case,
since
it
is
a
paid
account,
you'll
get
10,
hyper
apps
and
they've
used
three
of
those
apps.
So
far,
so
that's
three
of
ten.
You
could
purchase
more
apps.
D
So
when
you
select
an
app
you
click,
one
of
the
tiles
and
you'll
select
an
app
and
once
you've
selected
app
you'll,
be
just
you'll,
see
several
tabs
keys
data
search,
storage,
cache
and
queue
the
default
will
land
on
the
keys.
These
are
your
app
keys
to
be
able
to
connect
to
your
hyper
app,
which
will
give
you
access
to
the
services
related
to
that
hyper
app.
So
here
you
can
see
your
your
keys
key
and
secret.
D
D
D
D
A
A
It
was,
it
was
related
to
tyler.
No,
so
so,
tyler
is
working
with
building
a
graphql
api
for
the
dashboard
to
talk
to
to
the
dashboard
business
logic,
which
is
really
cool,
but
that
kind
of
triggered
the
fact
that
when
we
did,
the
dino
migration
tyler
included
not
only
the
rest
api
but
the
graphql
api
in
the
hyper
migration.
So
out
of
the
gate,
when
you
create
a
new
app,
you
will
have
an
option
to
either
use
the
rest
api
or
the
graphql
api
with
with
no
changes.
A
A
Cool
thanks
for
demoing
that
again
great
work
trip
started
back
in
may
and
tyler
started
in
june,
full
time
and
just
over
the
moon
with
the
progress
that
we've
made.
Pretty
awesome
and
you
know
casey
did
contribute
to
the
dynamodb
adapter,
we're
still
still
working
on
finishing
that,
but
he
he
passed
it
over
in
super
good
shape.
For
for
us
to
potentially
create
you
know,
kind
of
a
free
tier,
possibly
with
dynamodb.
A
A
We
talked
a
little
bit
about
plug-ins
and
tyler,
and
I
have
been
talking
about
plug-ins,
but
we
think
that
over
the
next
few
months
we'll
be
able
to
really
provide
some
solid
insight
on
plugins
tyler's
experimenting
with
a
couple
of
ideas
for
plugins
right
now
and
with
a
plug-in
basically
you'll,
be
able
to
add
logic
that
can
sit
in
front
of
the
adapter.
So
it
doesn't
really
matter
what
the
adapter
is.
A
B
Yeah
that
that
sounds
that
sounds
right
tom
and
I
think,
like
plugins,
are
really
they're
just
built
on
they're,
just
composed
on
top
of
the
adapter
definition.
So
it
can
do
things
like
I
change
what
goes
into
the
adapter.
It
can
change
what's
coming
out
of
the
adapter
and
returning
back
to
the
core
layer,
so
just
experimenting
with
it
right
now
and
dog
fooding
it
to
see
if
it's
a
good
pattern
and
so
far
it's
working
out
pretty
well.
A
A
Awesome
well
thanks
again
for
everyone's
time
and
we're
gonna
keep
cranking
we're
really
shooting
for
october
to
to
have
something
usable
but,
as
you
know,
we're
we're
in
the
early
stages.
So
we'll
we'll
see
how
that
goes,
and
you
know
probably
I
think
I'm
gonna
shift
these
meetings
to
monthly,
because
I
don't
think
we'll
have
much
more
to
show
except
you
know
every
four
weeks
and
yeah
looking
forward
to
the
next
meeting
and
and,
as
you
know,
we're
always
available.
A
B
Absolutely-
and
it
goes
without
saying,
but
thanks
to
tom,
for
you
know,
he's
built
out
a
couple
of
adapters
and
then
just
beefed
up
the
documentation
and
then,
as
far
as
getting
all
this
aws
stuff
set
up.
We
know
that
I'm
sure
we
all
have
gotten
a
little
bit
of
a
taste
of
aws
and
how
much
of
a
beast
it
can
be
so.
B
A
Yay
co-pilot
all
right
guys
well
have
a
great
afternoon
and
we're
doing
a
charleston
js
meetup
august
26th.
Please
tell
your
friends
it'll
be
in
person
at
the
charleston
tech
center.
So
please
let
everybody
know
I
think
that'll
be
a
cool.
You
know
get
together
face
to
face
and
hang
out
so
looking
forward
to
it
see
you
guys
see.