►
From YouTube: hyper TSC meeting May 4, 2021
Description
In this meeting, we discuss the announcements that occurred on May 3rd, hyper got funding, and Tyler and Trip will be joining hyper the hyper team.
Also, we talked about the idea of creating a bounty system for hyper open source to help build out the adapters and plugins.
We also discussed Graphql, if anyone is interested in using hyper with Graphql, let us know, we would love to work with you.
A
Good
yeah.
B
A
Welcome
guys
may
3rd,
or
is
it
may
4th?
May
the
4th
be
with
you
my
son
enjoyed
that
this
morning
I
actually
beat
him
to
the
punch
on
that
one
so
nice.
A
A
A
Just
a
couple
of
highlights
trip
is
starting
in
may
and
we're
tracking
to
launch
the
website
probably
mid
next
week.
I
was
hoping
to
do
it
friday,
but
probably
mid
next
week,
we'll
we'll
see,
but
my
plan
is
to
try
to
live
stream,
the
rest
of
the
development
effort
on
the
website-
and
you
know,
hopefully
that
has
some
value
for
some
folks
that
are
digging
in
the
tailwind
and
digging
in
the
spelt
kit.
A
And
then
really
targeting
june
for
the
launch
of
the
the
dev
developer
portal
or
are
really
our
free
service
tier
if
you
will
from
the
cloud
product
and
it's
actually
probably
more
like
a
pilot
free
service
tier,
because
once
we
get
we'll
probably
deprecate
that
to
a
more
richer
service.
But
for
now
it'll
still
be
the
same.
Api
it'll
still
allow
developers
to
get
started,
and
you
know
the
the
main
reason
that
we're
trying
to
launch.
A
That
is
so
that,
as
we
build
workshops
and
tutorials
for
people
to
code
along,
they
can
have
an
account.
They
can
have
their
own
place
to
put
data
and
they
don't
have
to
kind
of
run
that
from
scratch,
and
you
know
again
continuing
to
keep
everything
core
open
source.
A
That's
a
huge
part
of
our
mission.
So
as
we
take
in
funding
and
we
bring
on
you,
know,
tyler
and
tripp-
we're
still
going
to
be
focused
on
all
the
general
purpose,
components
to
be
open
source,
and
I
think
that
is
pretty
cool.
A
Any
questions
about
that
announcement,
any
confusion
and
and
thanks
casey,
for
helping
me
proofread
that
a
bit
last
week.
B
That
all
sounds
good-
all
I
have
to
say,
is
excited
to
be
joining
the
team
and
excited
to
just.
A
A
A
Well,
I
I'll
share
it
in
a
minute.
The
the
other
thing
is
just
kind
of
running
through
the
road
map
and
it
just
kind
of
did
high
level.
A
But
basically
in
may
you
know
we're
gonna
launch
the
website
and
I'm
gonna
start
an
api
developer
workshop,
probably
post
that
and
get
people
to
sign
up
and
that'll
be
like
how
to
you
know
kind
of
a
immersive
training
on
how
to
build
an
api
using
hyper
as
your
back
end
and
probably
serverless
and
probably
architect,
mainly
because
it's
pretty
straightforward
and
I
think
I
can
automate
a
lot
of
the
kind
of
get
started
through
gitpod
and
avoid
having
for
anyone
to
sign
up
for
an
account
or
anything
like
that.
A
And
then
june
that'll
probably
be
the
date
of
the
api
developer
workshop
and
as
tripp
and
tyler
comes
in
we're
going
to
start
planning
the
cloud
product
and
and
doing
some
design
sessions
on
that
and
then
just
really
hitting
the
documentation
again,
just
really
taking
a
huge
stab
at
cleaning
up
the
documentation
again
more
on
boarding
friendly,
and
I
really
want
to
focus
on
documenting
how
to
build
an
adapter,
how
to
build
a
plug-in,
which
is
something
kind
of
new.
A
And
I
think
I've
got
a
good
use
case
now
for
for
a
plug-in
that
I'll
talk
about
and
then
some
open
topics
to
talk
about
today,
and
we
don't
have
to
spend
a
lot
of
time.
But
one
one
is
as
we
go
to
build
adapters
and
plug-ins.
A
What
do
you
guys
think
about
kind
of
a
a
bounty
system
where
we
can
document
adapters
or
plug-ins
or
people
can
submit
adapters
or
plug-ins?
They
want
to
build
and
we
can
put
a
bounty
on
it
or
other
people
could
put
a
bounty
if
they
want
it
built.
And
then
someone
can
claim
that
bounty
do
the
work
and
if
the
work's
successful,
then
they
get
paid
the
bounty.
What
do
you
guys
think
about
that
approach?.
B
I've
I've
seen
similar
things
done
on
projects
like
sqlize,
and
I
sqlize
tried
to
do
like
bounty
cent
like
the
bounty
system
for
a
bit
on
their
backlog
and
like
open
issues
from
what
I
could
tell
there
wasn't
a
lot
of
like
interaction
with
that
yeah,
but
perhaps
that's
just
because,
like
sequel
eyes
being
a
like
trying
to
contribute
to
sequel
eyes
a
couple
times
in
the
past,
it
is
a
bit
of
a
beast.
Yes,
that
might
have
been
more
of
a.
B
It
might
have
just
been
the
barrier
to
entry
than
just
people
not
being
interested
in
the
bounty,
and
I
think
it's
worth
trying,
I
mean
there's
definitely
platforms
out
there
that
we
can
sort
of
hook
into
the
repo
and
it
could
like
pull
issues
down
and
it
could
attach
bounties
to
them.
I
I
can't
remember
what
those
platforms
are
off
the
top
of
my
head,
but
they
definitely
exist
as
a
sort
of
plug
and
play
thing
for
github
repos,
yeah.
A
Yeah
and
I
think
it'll
it
would
be
pretty
easy
to
manage
without
a
lot
of
heavy
lifting.
I
think
one
of
the
the
things
about
it
is
is
like
building
out
the
core.
If
someone,
you
know
someone
said
you
know,
came
up
and
said,
I
would
really
like
a
kendra
search,
adapter
right
for
amazon
kendra,
and
you
know
we
would
be
like
you
know-
that's
not
right
in
our
target
right
now,
so
that
might
take
a
little
bit
of
time
and
it
might
be
one
of
those
items.
A
That
is
so.
You
know
specific
that
it
just
kind
of
sits
at
number,
seven
on
your
top
ten
list
right,
and
so
it
never
gets
done.
So
the
the
idea
is
that
if
someone
wanted
that
and
they
were
willing
to
pay
for
it,
then
they
could
post
the
price.
A
And
if
someone
had
the
time
and
wanted
you
know
payment,
then
then
they
could
could
claim
that
and
and
do
it
and
that
would
be
a
way
to
to
mitigate
any
kind
of
you
know,
cool
stuff
that
could
be
built
that
that
we
just
that's
just
not
in
our
fair
way
to
get
done.
Does
that
make
sense.
C
Yeah,
I
have
a
question:
how
would
you
deal
with
the
only
like
conflict
that
I
could
see
with?
That
is
say,
two
developers
want
to
do
this
one.
Is
that,
like
a
first
person
who
claims
it
gets
it
or
maybe
they
like?
Would
the
company
decide
if
two
people
want
it?
Who
does
it
or
would
both
develop
it
at
the
same
time,
and
one
of
them
ended
up
getting
the
bounty
and
one
doesn't.
A
Yeah,
there's
there's
several
ways
to
do
that.
I
would
you
know
we
would
have
some
some
rules,
but
you
know
just
from
what
I've
seen
before
off
the
top
of
my
head
is:
when
you
submit
a
request
to
to
claim
a
bounty
to
to
do
it.
You
know
you
would
be
required
to
provide
some.
You
know
your
github
account
some
credentials,
some
background
on
your
expertise
and
you
know
maybe
there's
a
a
48
hour
kind
of
weighing
period
right.
A
So
multiple
people
can
request
to
claim
a
bounty
in
48
hours
and
if
two
or
more
people
do,
then
the
core
team
would
have
to
kind
of
decide
who's
the
best
one
for
that
particular
one
and
then
within
48
hours,
and
I'm
just
making
that
time
up,
but
some
period
of
time
you
know
the
the
claim
is
awarded
to
one
person
and
and
and
they
they
have
the
ability
to
do
that.
A
The
core
team
checks
on
them
time
to
time
there's
there
is
kind
of
you
know,
kind
of
a
a
time
agreement
from
when
they
start
the
claim
to
when
they
finish
it.
So
if,
for
some
reason,
life
comes
up
and
gets
in
the
way
and
they
decide
to
bail
out
that
claim,
then
then
we'll
reopen
the
claim
and
allow
someone
else
to
claim
it.
A
You
know
type
of
thing,
and-
and
I
don't
I-
I
don't
envision-
that
to
be
super
interactive
or
at
first,
but
I
think
if
we
put
that
kind
of
system
in
place,
it
will
just
refine
our
task
to
the
level
and
just
make
sure
that
we're
not
bleeding
any
boundaries
so
so
that
even
kind
of
the
work
that
we
do
is
maybe
you
know
kind
of
a
claim
kind
of
approach
so
that
we've
got
very
clear.
A
You
know
objectives
very
clear
deliverables
and
and
when
code
reviews
happen,
you
know
it's
it's,
it's
all
the
same
kind
of
process.
So
we
know
you
know
when
something's
ready
to
go
and
when
to
push
it,
etc.
B
Yeah,
I
think
that
all
makes
sense
to
me.
I
think-
and
maybe
this
is
like
a
an
issue
that
maybe
it's
like
pre-optimization
but
yeah
in
the
event
that
someone
claims
a
bounty
and
then
that
adapter
or
whatever
it
may
be,
becomes
like
a
top
priority
for
hyper
such
such.
That,
like
a
core
member,
would
be
willing
to
work
on
it.
Do
we
think
that
how
would
that
work?
Would
we
just
like?
B
Would
we
just
null
out
the
bounty
or
just
and
then
build
it
ourselves
or
or
I
guess,
how
would
that?
A
Yeah
yeah,
I
think
we
can
talk
through
those
scenarios
again.
One
of
the
my
thoughts
is
to
treat
it
like
a
like
a
contract
right.
If
you
hire
a
contractor
to
do
something,
usually
you
you
agree
on
a
timeline,
and
you
know
if,
let's
say
the
timeline
you
know
is
mutually
agreed
on
to
be
one
week
and
for
whatever
reason,
the
person
who
has
the
claim
of
the
bounty
doesn't
deliver
in
that
week.
A
Then
it's
up
to
the
the
moderators
us
in
that
case,
to
make
a
determination.
Do
we
give
them
an
extension
or
do
we?
You
know
revoke
the
claim
and-
and
I
think,
if
we
put
reasonable
timelines
on
that,
you
know
we're
not
we
wouldn't
I
I
I
would
imagine
it
would
be
few
and
far
between
where
you
know
a
priority
changed
at
such
a
rate
that
we
wanted
to
revoke
the
claim
mid
work,
yeah.
A
Yeah
and
and
again
I
think
we
can
put
some
you
know
we
can
put
some
writing
in
place
that
that
we
do
reserve
the
right,
but
but,
like
I
said,
I
think
you
know,
I
I
think
the
the
thought
is
is:
can
we
make
the
the
the
bounties
clear
enough
and
concise
enough
that
they're,
you
know
pretty
pretty
straightforward
and,
and
the
timeline
is,
is
pretty
clear
right.
A
If
we
want
to
open
a
flow
like
that
in
in
place,
and
and
again
I
think
more
so
maybe
for
plug-ins
and
and
one
of
the
things
that
we
haven't
talked
a
lot
about,
is
the
ability
for
hyper
to
have
plug-ins?
A
That
kind
of
can
sit
between
the
core
and
the
adapters
themselves
and
and
a
good
use
case
for
a
plug-in
is
let's
say
we
have
the
data
adapter
with
the
query,
endpoint
and
the
query
endpoint,
you
know
basically
has
several
ways
to
query
something.
But
let's
say
someone
wanted
to
create
a
very
specific
way,
like
a
date,
range
filter
or
pagination,
or
something
like
that.
A
But
it's
not
gene
generic
enough
to
go
into
kind
of
the
adapter
that
that
could
be
a
good
spot
for
a
plug-in
where
they
could
just
plug
in
a
date
range
filter
in
into
the
data.
A
Pipeline
and
all
of
a
sudden
now,
every
time
they
make
a
query
request,
they've
got
you
know
this
date
range
semantic
where
they
can
query
documents
from.
You
know
this
date
to
this
date,
type
of
thing
and
then
that
that
plug-in
could
be
used
on.
You
know
it
could
be
used
on
an
opt-in
basis
right,
it's
not
part
of
the
system,
but
if
someone
wants
that
date,
time,
filter
or
pagination
or
whatever
it
is,
they
could
pull
in
that
plug-in.
B
So
if
I'm
understanding
that
correctly
with
the
current
system
that
we
use
for.
B
Actually,
no,
actually
I
was
going
to
ask,
is
the
current
system
that
we
use
for
composing
adapters.
We
could
use
that
for
plug-ins,
but
I
think
this
fits
on.
The
does
is
what
you're
describing
sits
on
the
front
of
the
express
app
like,
or
is
it
like?
Actually
part
of
the
adapter?
Is
that
with
your
vision,.
A
Yeah,
the
the
original
thought
is
to
to
do
it
in
the
composable
adapter
pipeline,
but
but
but
again
I
think
we
can
figure
out
where
they
go,
but
that's
my
original
thought
is
to
be
able
to
pop
them
in
in
that
pipeline.
B
Yeah,
oh,
I
think
I
mean
that's
kind
of
the
sort
of
use
cases
that
I
had
in
mind
when
was
building
out
the
the
ability
to
compose.
D
B
B
And
I
think
that
would
that
would
open
up
like
a
whole
new
sort
of
a
set
of
like
open
source
tools
that
people
could
build
as
like,
like
hyper
plugins,
that
they
could
just
compose
on
top
of
just
any
particular
port,
maybe
there's
a
plug-in
for
one
particular
port.
Maybe
it's
a
plug-in,
that's
sort
of
for
agnostic.
A
Yep
yeah
and
I
think,
there's
some
cool
things
that
that
really
work
well
for
that,
for,
for
example,.
A
Let's
say,
for
example,
you
wanted
to
run
sql
on
the
data
port.
A
You
could
actually
create
a
sql
plugin
using
a
tool
like
a
la
sql
written
in
javascript,
where
the
the
plugin
takes
in
the
sql
and
then
converts
that
into
you
know,
kind
of
the
selector
query
language,
the
type
query,
language
and
now
you're
kind
of
writing
sql.
C
Cool
idea
for
me,
the
the
plug-in
idea
solves
probably
what
would
be
my
greatest
reservation
to
start
using
hyper,
which
is
a
lot
of
times.
The
20
ends
up
being
a
lot
more
than
20,
sometimes
with
a
lot
of
my
stuff.
The
only
thing
is
at
what
point
would
the
plugins
almost
be
like
negating
the
purpose
of
hyper
at
what
point
would
like?
Am
I,
if
I'm
composing,
all
of
my
own
plugins
and
basically
creating
almost
my
own
domain-specific
language
for
querying
data
when
I
use
that
people.
A
Yeah,
it's
a
great
question
and-
and
you
know,
I
think,
if,
if
you
you
think
in
terms
of
stratified
design,
which
is
a
new
word
that
I
learned
last
week,
so
I
get
to
sound
kind
of
fancy.
A
But
but
the
process
of
stratified
architecture
right
is
to
really
manage
your
your
levels
of
abstraction
and
and
your
your
goal
is
to
layer
them
in
in
in
a
way
that
you're,
only
you
know
kind
of
organizing
the
things
that
frequently
change
or
that
are
more
specific
up
at
the
top
of
your
layer
and
things
that
are
less
likely
to
change
that
are
more
general
down
at
the
bottom
of
the
layer.
A
A
In
general,
you
have
specific
to
my
use
case,
pacific
to
my
app
specific
to
my
domain
right
specific
to
my
technology
or
or
whatever,
and
you
know
try
to
I'll
try
to
unpack
that
more
but
like
like,
for
example,
if,
if
your
app
is
primarily
in
the
kind
of
domain
of
reports
right,
it's
it's
a
report,
kind
of
system,
heavy
read
that
then
you
may
have
a
layer
where
you
want
kind
of
this
date
range
filter
at
that
plug-in
level,
because
it's
really
not
your
your
app
specific
level
and
it's
not
necessarily
your
use
case
specific
level,
even
though
those
use
them,
but
but
you
get
more
reusability
at
that
kind
of
plug-in
level,
because
you
may
have
multiple
reporting
apps
right.
A
You
know
kind
of
thing,
but
you
know
again
it's
one
of
those
things
that
it's
probably
going
to
be
a
whole
bunch
of
guidance
and
and
at
the
end
of
the
day
the
client
will
have
to
make
the
decision,
and
I
think
you
know
I-
I
think
it
would
make
hyper
more
viable,
because
you're
really
kind
of
pushing
some
of
that
code.
That
hyper
is
trying
to
specialize
down
a
layer
and
make
it
more
general
purpose.
B
Yeah,
I
I
think
I
like
there's
definitely
a
a
risk
of
people
that
use
hyper
just
trying
to
put
everything
into
a
plug-in.
I
definitely
think
I
mean,
because
ultimately,
the
plug-in
system
is
effectively
middleware
for
the
ports
and,
as
we've
seen
with
tools
like
redux,
when
people
see
like
a
flexible,
middleware
api,
it
can
kind
of
turn
into
like
a
run-only
train.
So
I
think
there
is.
There
is
a
fair
amount
of.
B
If
there's
a
way
for
us
to
sort
of
coach
and
advise
folks,
whether
that's
through
blogs
or
through
consulting
or
like
just
educational
materials,
on
what
what's
the
use
case
for
a
plug-in
versus
what
belongs
in
your
business
logic,
I
think
that
that
sort
of
gets
us
where
we
can
have
our
cake
and
eat
it
too.
Where
we're
not
cutting
against
we're,
still
encouraging
people
to
not
spread
their
business
logic
out
across
multiple
places,
while
also
providing
a
plug-in
system
for
the
cases
where
it
makes
sense
to
have
a
plug-in.
C
Yeah,
I
have
another
question
about
plug-ins,
and
this
is
this:
wouldn't
be
probably
a
question
that
would
come
up
as
it
began,
but
maybe
it
would
be
one
from
the
future
so
say
I
have.
I
want
to
do
like
a
query
on
a
huge
database
and
I
want
to
put
10
plugins
so,
depending
on
how
it's
implemented
the
order
that
you
do
the
plugins
or
or
like
how
you
stack
them
could
have
like
potential
performance
things.
C
Would
that
be
something
where
you
know
would
hyper
be
dealing
with
figuring
out
how
to
optimize
that
or
is
it
pretty
much
like
all
right?
You
have
this
set
of
plugins,
we'll
start
with
this
select
all
kind
of
thing,
and
then
we're
gradually
applying
these
other
things
like,
I
guess
my
question
is
what
what's
the
strategy
there
is
that
something
that
hyper
is
going
to
handle
or
the
user
needs,
to
figure
out
how
to
do
that
more
efficiently?.
A
Yeah,
it's
a
great
question.
I
think
you
know
right
right
now:
we've
got
kind
of
the
the
hook
service
where,
where
you
can
hook
in
and
and
get
logs
out,
so
you
can
kind
of
see
you
know
the
the
time
it
takes
for
a
hyper
request
to
to
come
in
and
come
out.
A
So
you
can
kind
of
measure
that,
but
you
know
it'll
be
interesting
to
see
it'll
be
interesting
to
see
where
that
optimization
comes
into
play.
If,
if
you're,
if
you're
using
the
open
source
product,
it's
kind
of
on
you,
I
think,
but
if
you're
using
our
service,
then
more
than
likely
it'll
be
part
of
our
service
offering
to
provide
guidance
and
support
on
that
would
be
my
initial
answer.
C
A
Yeah
so
so
I
think
you
know
trying
to
get
some
more
documentation
around
that
some
use
cases
on
how
to
build
a
plug-in
and
really
a
guide
on
how
to
think
about
terms.
You
know
application
design
terms
in
this
stratified
layer
approach.
A
I
think
that
will
will
make
it
pretty
clear
where
you
know
you
you,
don't
you
don't
want
to
turn
hyper
into
an
orm
right
you
you
want
to
still
own
the
business
rules,
but
there
may
be
generic
for
better,
better
said,
general
purpose
pieces
that
are
specific
to
your
use
case
that
you
want
kind
of
in
that
plug-in
middleware.
A
A
B
I
think
it's
just
better
developer.
Experience
has
a
lot
of
things
built
in
like
linting
and
testing
it's
all
there,
and
so
I'm
sold
there.
B
My
my
con,
I
guess
my
question
is:
does
this
produce
a
barrier
to
entry
for
folks
that
are
coming
from
like
like
a
node
background,
or
are
we
just
intending
to
use
dino
as
sort
of
as
like
internal
tooling,
for
what
we
use
to
build
everything
or,
if,
like
someone
wanted
to
contribute
to
hyper
they'd,
have
to
spin
up
an
environment
with
dino,
which,
admittedly,
is
pretty
easy
relative
to
other
tools?
A
D
B
It
seems
to
me
that
dino
adoption
is
just
going
to
go
up
as
as
it
just
gets
more
mature
and
has
a
little
bit
more
of
a
community
behind
it,
and
I
think
we
might
as
well
hop
on
that
train
earlier.
A
If
that
makes
sense,
yeah
yeah
I
mean
to
go
the
node
route
and
to
be
able
to
you
know,
support
it's
just
you
have
to
do
cjs
and,
and
otherwise
you've
got
just
build
steps
everywhere.
So
I'm
with
you
guys,
I'd
rather
take
on
the
growing
pains
and
go
dino.
A
A
Is
they
took
the
the
rust
http
server
hyper,
it's
the
name
of
it
and
did
their
bindings
to
that,
and
now
their
their
speed
and
benchmarks
are
like
through
the
roof
that
they
are
very
impressive,
and
I
think,
with
with
what's
going
on
with
with
rust
and
wasm,
and
all
of
that-
and
you
know
where
dino
sits
is,
is
kind
of
you
know,
kind
of
exciting
to.
B
B
It's
easier
to
transpile
to
common
js
than
to
have
to
try
and
refactor
everything
over
to
using
just
es6.
Like
there's,
there's
tools
out
there
parcel.
There's
webpack,
dare
I
say,
there's
plenty
of
tools
that
could
take
our
es6
and
transpile
it
into
something
that
we
could
use
to
support
in
a
node
environment
and
I'm
sure
we
could
figure
out
the
issue
with
dependency
resolution.
B
A
Yeah,
yeah
and
and
again
you
have
a
really
strong
argument
in
the
sense
that
they've
been
trying
to
port
common
js
to
es6
for
10
years
now,
maybe
not
10,
but
a
long
time.
A
And
and
and
they
are
super
smart-
so
it's
it's
it's
it's
not
not
easy
and-
and
I
think
it's
just
just
going
to
be
a
challenge-
it's
like,
like
the
the
stuff
with
es6
for
node
works.
Now,
but
then,
if
you're,
a
library
author
and
you
do
es6,
then
it's
it's
problematic
you,
you
could
run
into
things
that
don't
work
with
new
builders
like
es
build
our
our
new
platforms,
like
the
you
know,
next
js
or
remix
run
and
those
things.
A
So
it's
just
really
kind
of
you
know
if
you
stay
no
land
right
now.
I
think
you
just
have
to
stay
common,
just
because
that's
where
all
the
tools,
it's
like
the
lowest
common
denominator,
there's
tools
built
to
support
that
up.
So
then
that
means
you're
kind
of
writing
in,
in
that
you
know
older
style
and
you're,
not
using
browser
apis
and
things
like
that,
so
casey.
Any
thoughts
from
your
side.
A
B
I
don't
I,
I
don't
think
we
have
to
have
like
an
in-depth
discussion
about
it
now,
but
something
to
just
keep
in
mind
or
I'd
like
to
have
a
description
on
eventually
right
now,
a
hyper
it
exposes
like
rest
and
a
while
ago
I
contributed
an
app
which
is
kind
of
like
the
consumer
facing
part
of
hyper,
that's
built
in
graphql.
B
I
think
it's
a
very
energy,
but
I'm
also,
I
I'm
mindful
that
I
think
most
people
are
still
just
using
rest,
but
is
like
having
like
a
graphql
sort
of
offering
or
consuming
hyper
something
that
we
think
would
boost
adoption
or
buzz
around
hyper,
and
if
that's
something
we
want
to
do
the
the
graphql
app
that
I
built
was
more
of
like
a
sort
of
like
a.
B
I
would
call
it
like
sort
of
like
a
alpha
or
like
a
proof
of
concept,
even
but
if
it's
something
that
we
think
would
boost
hyper
in
terms
of
adoption,
I'd
like
to
start
thinking
about
how
how
that
would
look
in
terms
of
just
a
graph
and
what
would
its
capabilities
be
with
respect
to?
Would
it
like
mirror
the
same
capabilities
as
breasts?
There's
some
things
that
are
going
to
operate
differently,
like
the
storage
api
jumps
out
at
me,
but
yeah.
A
Yeah,
no,
I
I
think
it's
still
still
worth
experimenting,
and
you
know
again,
I
I've
been
kind
of
taking
the
approach
of
you
know.
A
Working
with
the
the
two
users,
I
have
kind
of
identifying
what
their
pain
points
are
and
and
moving
the
prioritization
off
of
that,
and
you
know
I
I
think,
to
continue
to
build
out
the
graphql,
but
you
know
one
of
the
things
that
I
would
be
asking
us
ourselves
is:
when
do
we?
When
do
we
build
it
to
to
put
it
into
that
support
maintenance
flow?
A
If,
if
it
doesn't
have
any
customers,
I
think
it'll
just
be
hard
cognitively
to
keep
it
up
to
date,
right
but
other
than
that,
I'm
all
for
it.
I
think
that
that's
the
the
only
question
I
have
is
is
if
we,
if
we
can
land
some
customers
that
want
to
use
the
graphql
or
if
we
have
some
opportunities
to
to
use
that
and
put
it
on
a
path
to
production,
I
think
it
has
a
more
opportunity
to
be
be
part
of
our
stable
suite.
B
I
I
100
agree
with
that
tom.
I
think
it's
cool,
but
if
there's
no
customers
or
no
one's
asking
for
it,
then
I
don't
think
we
should
prioritize
building
it.
But
I
think.
B
If
there's
any
sort
of
surveys,
or
something
that
or
that
we
send
out
to
developers
on
what
do
you
think,
would
be
cool
to
have
in
hyper
sort
of
deal
or
what's
stopping
you
from
using
hyper?
If
there's
some
sort
of
like
data
point
on
graphql,
that
would
inform
us
like
hey.
This,
actually
might
be
something
we
want
to
prioritize.
A
Yeah
and-
and
I
think
if
you
know,
since
you
really
know
graphql
really
well-
are
there
use
cases,
because
this
is
kind
of
this
general
layer,
and
you
know
I
can
see
really
a
huge
advantage
of
graphql
at
that
kind
of
api
kind
of
business
domain
level,
mainly
because
you
know
as
a
front-end
developer.
A
I
want
to
get
widgets
and
comments,
and
you
know
all
this
stuff
on.
One
call
right
and
I
can
just
make
one
call
to
the
api,
but
but
at
the
kind
of
the
general
layer
you
know
in
that
business
logic
land.
Is
there
a
lot
of
opportunity
to
to
compose
a
query
to
get
multiple?
A
D
Let
define
probably
a
discovery
process
that
we
can
all
agree
to
when
talking
to
customers
or
potential
customers,
and
then
let
that
inform
roadmap
items
in
the.
A
D
So
I
mean
let
you
know
if
you,
if
you
have
too
much
of
a
surface
area,
to
support
it's
going
to
be
spread,
spread
you're
too
thin.
So
it's
it's
tempting
right
because
we
all
know
graphql
is,
is
you
know
highly
popular
and
it's
tempting
to
pre-optimize
the
solution
without
it
being
informed
by
discovery.
So
it's
not
a
bad
idea.
D
A
D
B
Yeah,
I
think
I
think
you
I
think,
we're
all
on
the
same
page
as
far
as
someone
needs
to
ask
for
it.
First,
before
we
go
and
build
it.
B
Okay
but
yeah,
just
something
I'd
like
us
to
be
mindful
of
as
we
like,
perform
this
discovery
process
for
what
to
build
next
and
how
to
build
a
road
map
just
something
to
have
on
our
have
in
the
back
of
our
minds.
A
Awesome
well
thanks
everyone
for
joining
big
big
milestone.
Next,
two
weeks
we
should
have
you
know
a
little
bit
more
progress
to
report
and
yeah
trip
will
be
one
weekend
to
full
time,
so
that'll
be
cool.
D
A
Yeah
like
people
are
like
is
that
real,
real?
No,
that's
real.
A
Yeah
everybody
have
a
great
two
weeks
and
don't
forget
thursday,
we
got
a
react
meetup
and
if
you
guys
want
to
join
at
five-
and
I
know
casey's
gonna
propose
a
talk
for
an
upcoming
meetup,
but
if
you
guys
want
to
put
together
a
talk,
just
let
me
know,
what's
the
best
place,
to
get
the
calendar
link
to
that.
So
I
can
get
a
reminder:
meetup.com
meetup,
okay,
charleston.js,
yeah,
charleston.js,.