►
From YouTube: API Vision working group #5
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
Great
yeah
and
yeah-
hopefully
there
are
no
issues,
I'm
traveling
and
got
stuck
without
a
flight,
so
I'm
borrowing
a
computer
so
bear
with
me.
I
don't
not
used
to
his
computer
or
anything
so
yeah.
I
wanted
to
raise
a
topic
on
rest
versus
graphql,
really
just
kind
of
bringing
it
back
to
the
forefront
from
our
earlier
meetings.
You
know
we
wanted
to
go
out,
get
some
feedback
through
user
surveys,
customer
interviews
and
the
like
and
start
trying
to
make
some
decisions
on
this.
B
So
we've
been
collecting
data
in
the
user
survey.
We've
had
553
responses
in
total
now,
which
I
think
is
awesome
seems
like
a
really
significant,
really
significant
feedback
and
yeah.
I
guess
the
what
kind
of
sparred
this
a
little
bit
is.
Victor,
you
shared,
I
think,
you're
on
the
call
you
had
shared
some
feedback
from
our
terraform
provider.
I
think
it
was
our
python
maintainer,
no
terraform
provider.
That's
right
and
they're
they're
pretty
much
just
asking
for
guidance.
You
know.
Have
we
made
any
progress?
B
B
What's
changing
specifically
in
terms
of
apis,
like
I
think
that
you
know
there
are
the
pages
that
we
share
around
deprecations
and
and
everything,
but
you
know
I
don't
think
it's
really
narrowly
broken
down
specifically
on
the
api
endpoints
or
builds
as
the
sense
that
I
got
or
that
it's
maybe
not
easy
for
them
to
to
identify.
B
So
what
I
wanted
to
do
is
just
share
a
little
bit
of
the
data
that
I've
captured
so
far
and
then
open
it
up
for
for
discussion
and
see
if
there's
some
opportunity,
opportunities
to
kind
of
get
either
policies
or
or
priority
on
things
for
a
milestone
for
the
major
milestone
coming
up,
because
once
that
passes
then
we'll
have
to
wait
a
pretty.
You
know
significant
period
another
year
before
we
can
get
any
any
changes
in
there.
Okay,
so
let
me
share
my
screen.
B
That's,
and
so
this
is
pretty
pretty
sparse
right
now,
I'm
still
starting
to
go
through
in
more
detail
through
the
data,
but
the
first
you
know
first
chart
here
is
just
around
the
question:
do
you
have
a
preference
in
api
format,
251
of
the
like
553
people
that
that
responded
to
the
survey
answered
this
question
and
what
we
see
is:
there's
an
overwhelming
preference.
B
Well,
really
there's
an
overwhelming
overwhelming
preference
and
not
have
neither
there's
not
a
preference
in
45,
but
between
rest
and
gravity.
Well,
41
percent
prefer
rest
based
on
those
who
responded.
D
C
B
Right
so
it's
kind
of,
I
guess
one
way
I
read
that
is
it's
almost
like
if
we
can
total
up
no
preference,
plus
graphql
and
then
no
preference
plus
rest
yeah,
which
is
the
winner
between
that
between
those
two
one
thing
I
did
do
I
haven't
gone
through
and
and
segmented
all
this
in
a
lot
of
different
ways,
but
I
did
have
them.
B
You
know
really
curious
about
the
large
customer
segment,
so
I
broke
that
broke
it
down
by
large
customer
responses
and
and
note
that
of
the
251
only
19
identified
themselves
as
large
customers.
B
So
you
know
it's
a
fairly
small
number,
but
based
on
the
survey
data,
you
know
that
that
preference
jumped
up
quite
a
bit
on
the
rest,
you
know
and
over
no
preference
and
so
far
the
interviews
I've
had,
which
you
know
I
want
to
have
many
more,
but
the
large
customers
seem
to
be
identifying
that
they
they
do
prefer
expressive
or
graphql,
and
only
a
couple
more
slides.
B
Here
I
wanted
to
pull
out
some
of
the
feedback
for
when
users
do
prefer
rest
or
graphql
wine
and
overwhelmingly
the
top
response
around
rest
was
familiarity.
Some
folks
are
saying
I'm
just
more
familiar,
others
are
saying
I
I
just
don't
know:
graphql
don't
want
to
invest
the
time
it's
and
these
aren't.
It's
not
like
these
are
necessarily
in
order
like
that
was
that
was
many
responses
around
that
first
item.
B
Some
of
these
are
just
one
response
or
two
that
were
related
to
the
bullet
but
easier
to
debug,
using
python
scripts,
easier
to
use
rest
from
cli
more
consistent
support
across
the
vendors.
I
thought
was
interesting,
just
kind
of
saying
this
is
one
of
the
more
popular
standard
across
sas
platform
for
platforms
and
sas
products.
So
you
know
it
makes
sense
to
use
that
there
may
be
some
kind
of
company
policy
that
this
is
just
what
my
company
or
employer
uses
for
building
apps,
there's
also
kind
of
a
tooling
around
it.
B
The
support
for
packages,
libraries
easier
to
build
into
custom,
tooling,
simple,
shell
scripts,
this
one's
kind
of
you
know
it's
it's
kind
of
a
challenge
gitlab
for
get
lab.
Specifically,
some
endpoints
aren't
available
in
graphql,
so
maybe
if
they
were,
it
would
bring
those
those
customers
over
to
maybe
preferring
graphql
and
then
the
last
one
is
I've
seen
a
couple
times
too.
It
have
to
convince
management
that
we
want
to.
B
So
a
lot
of
people
did
give
responses
to
this
follow-up
question
if
they
chose
rest
as
their
preference,
not
as
many
responses
of
why
they
they
would
prefer
graphql
when
they
chose
that.
So
the
the
responses
here
were
why
graphql
types
and
complex
requests,
they
were
all
pretty
similar.
The
ability
to
create
precise
accomplished
queries
as
a
reducing
over
fashion
and
under
fetching
and
then
fine-grained
access.
So
I
think
these
were
all
pretty
similar
responses.
B
One
of
the
interviews
that
I
had
is,
I
think,
especially
for
those
that
know
preference
group
is
just
like
if
you
can
just
pick
one
of
these
and
go
with
it,
we
can
at
least
know
what
to
expect
and
plan
around
that,
and
I
think
that's
just
saying
go
out
if
you
can
be
consistent
in
offering
one
of
these
apis
and
supporting
it
really
well,
that's
gonna
help
us
and
I
think
that
they
would
all
this.
B
You
know
this
is
my
own
assumption
here
that
I
think
they
would
all
get
value
out
of
having
support
for
both
apis,
but
we
just
need
to
pick
one
first
and
make
sure
that
it's
very
fleshed
out
well
documented.
D
So
one
question
here:
I
know
that
this
is
kind
of
an
early
question
for
the
stage
where
we
are
at
and-
and
I
don't
expect
you
to
have
an
answer,
but
I
I
love
this
first
of
all,
so
this
is
amazing
cool.
Thank
you
very
much,
and
thanks
for
all
that
that
you
are
showing
us
here
does.
Does
this
direction
that
we
pick
one
and
go
with
it
would
mean
that
slowly
we
would
roll
out
the.
B
My
I
mean
from
where
I'm
standing
I'm
making
a
lot
of
assumptions,
and
I
want
to
learn
from
from
you
guys
who
have
a
lot
of
experience
and
have
been
here
longer,
but
I
I
would
like
to
see
us,
like,
I
said,
build
out
more
robust
support
around
one,
just
making
sure
that
every
feature
is
supported,
that
we
possibly
can
and
then
and
then
work
on
making
it
easier
to
to
then
add
the
feature
to
the
secondary
api
like
if
there
was
a
if
there's
tooling,
that
allows
us
to
say,
add
our
features
first
into
rest,
and
it
makes
it
easier
to
come
back
and
add
a
graphql
field
that
that's
you
know
parody
with
that
feature.
B
That's
that's
kind
of
the
way
I
would
see
that
or
if
we,
for
whatever
reason,
chose
graphql
but
just
based
on
the
data
I
feel
like
there
is
from
a
customer
standpoint.
Of
course
I
understand
that
internally,
maybe
there's
you
know
for
front-end
purposes.
Graphql
is
is
preferred,
but
it
seems
like
for
our
customers.
B
The
the
big
question
I
think,
is
knowing
that
we
have
15.0
coming
up
and
with
this
type
of
data
so
far
that
we
have.
What?
What
does
that
mean,
and
I
don't
have
those
answers-
I'm
I
just
wanted
to
start
with
the
discussion,
but
maybe
we
can
we
can
be
thinking
about
you
know
what
can
we
do?
Even
if
it's
just
marginal,
you
know
iterative
improvements
that
that
help
chip
away
at
some
of
the
challenges
our
customers
are
having.
E
One
thing
that
strikes
me
is
the
list
of
reasons
why
I
prefer
rest
all
those
things
are
actionable
and
we
could
easily
turn
them
into
things
we
want
to
address
so
just
off
top.
My
head,
you
mentioned
there
that
better
command
lines
for
a
better
python
support.
E
Could
we
include
ways
of
automatically
constructing
a
curl
invocation
for
both
graph,
both
rest
and
graphql,
so
people
can
see
those
things
I
mean
not
trying
to
lead
them
down
towards
one
or
the
other.
People's
support
preferences
are
valid,
but
if
we're
trying
to
help
people
see
that
which
tasks
are
easy
and
doable
on
the
command
line,
we
could
perhaps
do
something
to
address
those.
E
I
think
those
list
of
reasons
why
people
prefer
rest
or
for
graphql
can
also
be
seen
as
a
set
of
things
that
people
want
and
we,
and
that
would
be
very
helpful
to
work
towards
some
of
this
documentation.
Some
of
it's
working
on
our
developer,
docs,
so
a
bit
more
code,
but
I
think
we
could
improve
on
on
those
different
dimensions.
B
B
I
think
it's
just
a
matter
of
of
where
we
start.
I
think
the
biggest
challenge
to
overcome
is
consistency
is
what
I'm
hearing.
So
there
are
features
that
are
in
graphql
and
not
in
rest.
So
is
that,
for
example,
something
we
could
start,
you
know
start
with
make
sure
that
we
do
have
everything
in
rest.
First
then
also
yeah,
let's,
let's
you
know
chip
away
at
the
challenges
that
were
cited
there
for
why
they
use
rest,
which
it
doesn't
seem
like
an
education
thing.
E
Apparently,
don't
see
that
well,
I
I
also
don't
want
to
make
it
be
seen
like
I'm
educating
people
towards
my
preference.
That's
that's
not
the
case,
but
I
mean
it's
more
about.
We
have
some
resources
that
exist.
We
want
to
educate
people
how
to
use
them,
but
I
think
your
point
about
helping
people
by
having
an
overview
of
the
of
the
resources
available
and
then
plugging
the
gaps.
E
First
would
be
a
very
good
way
to
approach
15.0
to
make
sure
that
if
there's
anything
missing
on
the
rest
side
fix
that
first,
if
there's
anything
on
the
graphql
side.
Obviously,
if
that's
not
its
preference,
cue-
that
for
later
great.
D
I
I
I
would
argue
to
to
have
drafted
out
first
to
to
pitch
down,
and
I
know
that
I'm
doing
that
against
the
data
that
we
have
today,
but
so
in
a
sense,
I'm
saying
that
probably
what
I'm
saying
needs
more
research.
D
But
what
I
see
is
that
many
of
the
arguments
around
dress
are
around
current
culture,
which
is
almost
impossible
to
change,
but
we
could
solve
it
with
situ
with
solutions
that
alex
just
said,
and
the
flexibility
of
graphql
is
something
that
we
cannot
solve
with
rest
so,
and
I
think
that
we
will
need
that
flexibility
sooner
or
later.
Anyway.
D
We
need
it
for
the
gitlab
ui
and
if
we
pick
one
above
the
other,
it
will
only
work
if
the
whole
github
engineering
starts
to
follow
that
which
means
that
the
front
end
will
start
to
follow
that
enlarge
as
well
and
so
on.
So
it
will,
it
will
have.
It
should
have
a
cascading
effect
throughout
gitlab
and
and
I'm
worried
that
we
dressed
we.
We
won't
have
that
buying
from
gitlab
itself,
and
I
was
super
happy
with
what
you
said
alex
before,
because
without
that
I
would
have
argued
for
rest.
D
Well,
not
critics
or
the
benefit
why
people
favor
rest
over
graphql
and
see
what
our
our
answers
would
be
if
we
go
with
draft
q
and
put
like
10
minutes
of
thinking
to
each
of
them
and
perhaps
on
a
few
interviews
with
people
who
are
favoring
rest
to
really
dig
into
deep
into
that
question
like
okay.
What
what's
behind
your
arguments
for
rest?
What
what
was
there
really.
E
E
You
can't
have
a
bunch
of
rest
endpoints
that
you
then
use
to
implement
graphql
with
not
you
can't
do
that
efficiently.
So
in
terms,
if
you
have
to
choose
one
template,
the
other
has
it.
A
Yeah,
I
think
those
are
very
good
points.
I
think
that
at
the
moment
we
have
a
the
idea
here
that
we
love
that
is
graphql
first,
but
I'm
not
sure
if,
like
how
far
are
we
with
that
idea?
You
know,
because
I
don't
see
like
like
like
we
are
approaching
that
strategy
consistently
and
thinking
like
okay
in
five
years
time.
Let's
say
that
we
only
support
graphql,
you
know,
so
we
are
not
on
following
that.
A
A
If,
because
at
the
end
is
we
have
to
choose
one
or
the
other
right
is
what
I
understand
it
at
the
end,
what
we
want
is
just
go
with
one
approach,
because
otherwise
it's
going
to
be
more
work
on
us
all
the
time
and
there
are
other
problems
like
the
parity
between
dress
and
graphql,
and
if
you
develop
something,
maybe
you
you
only
need
that,
for
example,
for
the
front-end
only
on
graphql
and
you
are
not
supporting
rest.
A
So
I
think
at
some
point
we
have
to
decide
and
then
commit
into
one
strategy
and
make
a
path
in
order
to
move
a
with
that
strategy
and
with
clear
like
due
dates
or
like
at
this
point.
It's
going
to
happen.
Something
at
this
point
is
going
to
happen
something
and
it
could
be
very
long-term
plan,
but
but
I
think
that
at
the
end
I
think
we
we
have
to
to
choose
one
of
these
right.
B
B
B
I,
I
wonder
if
we
can
overcome
some
of
the
challenges
that
we
have
with
with
you
know
the
education,
the
family
like
familiarity
like
how
common
the
rest
standard
is,
but
you
know
what
would
be
the
impact
of
of
say
doing
graphql
only
only
supporting
graphql.
I
think
that's
yet
to
be
quantified,
but
maybe
yeah.
I
don't
know
we're
talking
about
long
term,
but
I
want
to
hear
from
the
technical
experts
on
the
call
as
well.
E
Oh,
I
just
wanted
to
say
that
I
think
it'd
be
good
to
get
a
resource
level
analysis
of
what
our
gaps
are
missing
features
are.
This
should
be
analyzed
on
a
per
group
basis,
so
we'll
just
source
code
wants
to
do.
What
does
code
review
have?
E
What
does
integrations
have
and
rest
graphql
that
each
group
will
be
the
most
equipped
to
provide
that
information,
and
that
would
be
a
really
helpful
starting
point
for
the
discussion
in
terms
of
what's
available,
and
if
we
talk
about
there
there
are
lots
of
things
that
are
available
in
one
side
or
the
other,
but
I
don't
think
we're
talking
concrete
terms,
but
what
those
things
are,
what
the
biggest
gaps
are,
what
most
painful
gaps
are
so
and
watch
things
we
will
never
fill
so
I
mentioned
about
above
ci
tracers
will
never
be
providing
rfql
because
of
the
nature
of
the
resource.
E
B
So
so
listing
so
gap,
analysis
per
group
list
each
of
the
features.
What
do
we
have
in
rest?
We
have
in
graphql
and
then
what's
what
can
only
be
in
rest,
for
example,
or
what
could
only
be
in
graphql
a
bit
precisely.
E
E
Oh,
I
I
was
just
saying
yes,
I
disagree
with
you
and
emphasizing
that
I
think
this
needs
to
be
broken
down
by
product
category.
All
right.
D
I
I
would
go
back
a
bit
to
arturo's
comments
and
because
I
think
that
we
can
actually
make
it
make
the
whatever
direction
we
take.
We
can
make
this
a
priority
for
the
product
teams
to
to
fill
the
gap
if
there
is
a
clear
direction
from
from
you
grant
from
your
team,
so
that,
especially
if
you
can
put
besides
that
an
investment
case,
then
that
shows
that
these
are
the.
This
is
the
one
that
we
spend
today
on.
Maintaining
both
this
would
be
if
you
can
just
focus
on
one
of
them.
D
A
Another
thing
that
is
not
technical
is
that
we
are
going
to
face
all
the
time
like
people
pushing
back,
so
it
doesn't
matter
like
what
is
the
approach
that
you
select
you
are
going
to
have
like
hey.
I
have
a
customer
with
500
5
000
seats
that
wants
to
continue
with
this
path
so
or
even
internally.
Maybe
there
are
things,
and
maybe
we
can
start
like
trying
to
pitch
in
this
internally,
like
hey
what
happen
if
we
go?
A
Yes
with
graphql,
for
example,
and
we
can
see
internally,
what
are
the
problems
that
we
are
having
before,
like
you
know
like
if
we,
if
we
just
say,
let's
go
with
this,
what
is
going
to
happen
just
inside
gilda.
E
You
know
hasn't
the
internal
debate
mostly
taken
place.
Front-End
development
is
entirely
graphql
based
these
days,
but
anyone
from
families
like
to
speak
to
that,
I
think,
there's
not
much
debate
anymore-
is
that.
F
G
I
remember
we
had
this
in
the
documentation
at
some
point
that
we
wanted
to
use
the
rest
api
as
a
wrapper
for
graphql.
So
every
rest
ape
endpoint
would,
in
the
background,
call
a
graphql
endpoint
to
and
then
basically
just
pretend
it's
rest.
But
in
the
background
it's
graphql,
and
maybe
this
could
be
a
path
for
yeah
customers
that
really
want
to
use
rest.
G
B
So
that
makes
sense
in
the
case
that
we
have
some
rest
in
points
today
that
are
missing
to
maybe
do
an
experiment.
G
Oh
yeah,
it
would
be
a
nice
idea
if
we
find
something,
that's
that
we
have
in
graphql,
but
not
in
rest.
We
could
definitely
ask
at
a
rest
endpoint
that
uses
the
graphql
in
background.
B
D
I
I
would
like
to
share
something
here,
because
all
of
this
started
from
the
comment
that
I
had
on
github,
but
I
would
write
back
there
that
the
provider
is
likely
better
off
if
it
starts
to
move
from
rest
to
graphql,
based
on
discussion
we
have.
This
is
my
impression
I
don't
know
if
you
agree
with
this,
so
it's
not
a
very
strong
saying
that
that's
the
direction
we
are
going,
but
my
impression
is
that
we
are
slowly
converging
towards
that
that
we
want
the
traffic
light.
First.
B
Yeah,
that's
been
my
impression
since
starting
with
gitlab
and
what
I
think
of
you
know
what
I
have
been
sharing
with
customers.
That
way.
You
know
there
seems
to
be
a
slight
slight
preference
and
direction
there.
I
think
it's
just
trying
to
understand
how
do
we?
B
How
do
we
get
back
to
rest
or
what?
What
is
our
policy
with
rest
in
the
short
term?
You
know,
I
think
I
think
that's
a
fair
point.
It
sounds
like
you
know
internally,
especially
there's
a
strong
preference
for
graphql.
B
I
think
there's
there's
just
this
clear
discrepancy
between
our
internal
preference
and
especially
you
know
large
customers,
larger
customers
and
and
they're
they're
kind
of
stuck
in
their
ways.
With
with
rest,
I
think
so.
How
do
we
solve
for
that?
But
that
doesn't
mean
using
rest
first
necessarily,
that
may
not
be
the
the
right
way
to
attack
that
problem.
B
Thanks
yeah,
so
I'm
happy
to
respond
in
the
in
that
issue.
Perfect.
Thank
you.
You're
welcome,
but,
okay.
Thank
you
very
much.
Yeah
see
you
yep.
Thank
you
feel
free
to
share
more
comments
in
the
doc.
If
you
didn't
get
a
chance.