►
From YouTube: API Vision Working Group #7
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).
A
All
right
thanks,
everyone
for
joining,
I'm
also
traveling
a
little
bit
so
I'm
in
between
places
and
trying
the
setting
out.
So
I'm
outside
we'll
see
if
there's
any
interruptions.
Apologies
all
right!
Let
me
share
my
screen.
A
And
the
agenda
there's
a
couple
things
I
wanted
to
cover
to
kick
things
off
today.
So
the
last
time
we
met,
we
talked
through
our
api
user
survey,
some
of
the
findings-
and
I
hope
you
all
got
a
chance
to
watch
that
and
I'm
happy
to
jump
in
and
have
some
more
discussion
today.
One
thing
I
did
want
to
highlight:
that's
new.
A
Is
this
gap
analysis,
so
this
is
something
I
shared
just
a
link
to
in
the
last
conversation,
what
I'm
hoping
to
do
is
get
with
the
teams
here,
especially
and
identify
what
features
our
teams
support
and
try
to
map
those
to
apis
and
rest
and
graphql.
A
So
once
you
jump
into
that
sheet,
I
I
need
to
add
a
link
there,
but-
and
I
think
I
have
one
earlier
in
the
presentation,
but
once
you
jump
into
it,
you
should
be
able
to
just
go
to
the
instructions
tab
and
and
give
that
a
try.
And
if
you,
if
you
hit
snags,
you
can
comment
me
if
you
have
ideas.
You
can
comment
me
as
well.
A
B
Are
we
going
to
create
issues
for
for
each
group
to
to
go
through
the
api
endpoints
that
they
maintain
and
they're
responsible
for
and
and
and
go
through
that
or
because
I'm
assuming
that
we
could
do
this
work
and
maybe
spread
the
workload
among
the
members
of
this
working
group,
but
it
might
be
probably
more
efficient
or
like
more
accurate
if
we
get
to
the
dris
of
of
the
hip
endpoints
to
go
through
them.
A
Yeah,
no,
that's
a
good
question.
I
mean
my
my
thought
was
maybe
first
starting
with
this
group.
That
way,
you
know
we're
kind
of
doing
a
little
bit
more
of
the
legwork
to
see
if
there's
a
way
to
improve
this-
and
I
can
put
this
into
an
issue
in
our
board.
If,
if
that
would
be
helpful
and
we
could
start
with
what
are
our
dris
here
and
the
teams
that
we're
working
with
so
we
could.
A
We
could
branch
out
that
way,
but
I
was
thinking
about
if
you
guys
have
seen
this
pajamas
okr
issue
that
we
have
to
track
across
the
company.
Think
about
leveraging
an
approach
like
that,
once
we
have
it
kind
of
nailed
down
to
start
to
spread
it
across
git
lab
as
a
whole
and
get
something
comprehensive
and
then
what
would
be
great?
I
don't.
I
think,
I'm
going
to
defer
to
the
engineering
folks
for
ideas,
but
I
think
it
would
be
awesome
to
not
have
to
do
this
again.
A
You
know
this
is
manual
pretty
manual
to
start
with,
but
once
we,
you
know,
have
a
good
picture
of
it.
Maybe
we
can
get
this
into
into
code,
something
more
programmatic
that
that
we
can
always
see.
You
know
from
feature
to
apis
what
what
we
have
so
I'm
open
to
suggestions
for
that
as
we
get
through
this,
but
this
will
always
give
us
a
start.
We
can
start
to
see
you
know
where
are
all
of
our
gaps.
A
What
do
we
anticipate
in
terms
of
effort
to
close
them,
and
that
gives
us
a
scope
to
work
with,
so
we
can
start
talking
about
it
from
a
business
and
product
standpoint.
Here's
the
capacity
we
have
here's.
What
we
need
to
get
to-
and
this
is
this-
is
of
course
just
one
component
of
it.
There's
a
lot
of
other
work
to
do.
A
Right
and
starting
with
us
and
and
we
can,
what
might
help
is
you
and
I
can
collaborate
in
an
issue
to
see
how
we
want
to
kind
of
lay
this
out
for
our
group
here
and
then
and
then
I
will
want
to
expand
this
out
further
once
we've
validated
that
this
is
about.
You
know
it's
a
valid
approach
to.
C
A
Awesome
all
right,
so,
let's,
let's
jump
into
the
next
item,
so
we
did,
you
know,
go
through
the
user
survey
findings
last
time
and
let's
see,
if
there's
just
I'm,
just
going
to
jump
into
any
discussion
and
questions,
but
I
can
go
into
slides
and
and
try
to
discuss
those
further.
However,
okay,
your
first
question
fabio:
how
do
we?
How
did
we
define
api
support?
A
So
this
will
be
referring
to
this
kind
of
category
analysis
and
and
that's
a
good
question.
We
we
largely
in
this
case
just
had
it
broken
down
with
with
category
titles.
There
wasn't
like
an
in-depth
description
of
each
of
these,
so
it's
kind
of
up
to
the
user's
impressions
ultimately,
but
that
that
does
gives
us
give
us
something
to
dig
into
deeper.
You
know
this
isn't
meant
to
be
a
standalone
analysis
like
we're
using
the
survey
and
that's
it,
but
I'm
moving
forward
now
with
setting
up
conversations
with
with
our
customers.
A
B
Yeah,
so
this
was
related
to
some
discussion.
Some,
you
know
what
should
we
have
like
a
one
type
over
like
I
preferred
over
another
one
and
and,
in
my
opinion,
receiving
the
results
of
the
survey
which,
by
the
way,
they're
they're,
really
awesome,
and
thanks
for
for
running
that,
so
definitely
the
ratio
is
on
the
rise,
but
rest
is
not
declining
and
the
rest
is
the
de
facto
probably
standard
for
automating
for
automations
and
workflows
at
the
moment.
B
So
I
don't
see
like
us
having
a
preference
over
like
which
one
we
should
like
use
more
often
or
something
like
we
could
have
a
preference
internally
for
from
the
front
for
the
front
end,
for
example,
to
lean
towards
graphql,
but
I
think
ultimately,
we
need
to
implement
both
and
maintain
both
in
my
opinion
and
then
boils
down
to
what
can
we
do
to
reduce
this
maintenance
between
the
two
things
and,
in
my
opinion,
is
this.
B
We
should
call
the
exact
same
code,
which
would
be
like
you
know,
a
service
object
or
something
like
that,
and-
and
I
think,
if
we
use
this
pattern
more
strictly,
we
would
be
able
to
have
feature
parity
among
the
rest
and
graphql
and
also
being
able
to
track
if
this
layer,
this
is
called
service.
Object,
is
called
for
from
graphql,
but
it's
not
called
from
rest
api.
B
I
don't
know
so
over
like
a
wrapping
apis
and
things
like,
which
might
might
be
a
little
bit
more
fragile
in
my
opinion,
and
that's
ultimately
would
benefit.
Also,
the
entire
design
of
the
of
the
system
in
their
opinion
by
using
hexagonal
architecture.
A
C
Yeah
I
I
wanted
to
say
that
I
agree
that
we
should
not
have
a
brief
preference.
We
should
support
both
apis
and
it
seems
that
both
apis
are
important
and
are
going
too
important
for
our
users,
and
I
don't
think
that
you
know
suddenly
rest
ip
rest
interface
for
our
api
is
going
to
go
into
decline
and
won't
be
used
as
much
because
there
are.
C
There
are
some
different
principles
associated
with
both
apis
and
some
users,
like
me,
prefer
rest
api
because
in
some
cases
it's
easier
to
use
and
it's
simpler,
and
I
think
that
basically
it
would
be
great
to
have
a
common
abstraction
for
both
to
make
it
easier
to
add
both
implementations,
but
it
might
be
challenging
it
might
be
challenging
because
graphql
organizes
data
differently.
C
C
So
it
if
we
use
abstraction
it
might
be
actually
a
bit
slower,
but
there
might
be
an
overhead
to
that
abstraction.
If
we
we
will
need
to
align
how
we
retrieve
data
from
database
and
for
graphql
it
will
work,
probably
fine,
but
for
us
it
might
be
slower
because
for
the
both
apis
we
will
need
to
find
the
least
common
denominator
right
then,
in
cause
per
case
of
graphql,
you
know
we
will
need
to
have
a
bit
more
elaborate
method
of
retrieving
data
from
our
database.
C
While
for
us
it's
just
select
from,
and
it's
as
simple
as
that,
so
I
think
we
we
just
need
more
technical
research
on
the
topic.
It's
it's
not!
That
simple,
like
I
think,
introducing
a
common
abstraction
might
be
a
good
idea,
but
we
would
need
to
understand
details
because
you
know
world
of
software
consists
of
infinite
amount
of
details
and
details
matter.
Actually,
so
that's
why
it's
it's
tough,
but
yeah.
A
B
I
think
we
should
be
able
at
least
it
should
be
simpler,
to
do
to
find
that
common
objection,
for
example,
for
mutations
than
for
queries.
I
I
agree,
I
think,
for
queries
will
be
more
and
more
difficult
for
mutation.
We
seem
to
have
a
lot
more
equivalent
logic
that
we
could
extract
under
the
same
the
same
obstruction.
B
So
maybe
we
could,
if
we
start
distinguish
between,
like
even
in
terms
of
end
points,
we
could
start
distinguishing
between
mutations,
even
on
the
rest
side.
What
is
this
like?
A
mutation
is
this
like
purely
like
a
query
and,
and
maybe
understanding
there
do
we
have
more
gaps
in
mutations
or
we
have
more
gaps
in
queries,
so
this
might
be
also
another
kind
of
variable.
We
can
look
at.
C
Yeah
and
another
aspect
here
is
the
library
we
are
using.
I
think
that
we
are
using
a
community
maintain
gem.
I
might
be
mistaken,
it's
been
a
while,
since
I
actually
it's
possible
that
we
are
maintaining
it
right
now,
but
basically
you
know
it's
also
something
that
will
come
in
a
way
of
designing
that
common
abstraction.
A
Awesome,
I
I
think
this
is
probably
a
good
one
to
get
into
an
issue
I
think
we've
we
may
have
something
out
there
already
as
like
a
poc
issue
to
try.
You
know,
testing
out
doing
a
rapper
like
a
rest
wrapper
on
on
a
graphql
in
point
that
maybe
we
can
identify
where
possible
approaches
are
and
do
some
pocs
for
each
of
the
approaches
and
come
to
some
conclusions.
Would
that
be
a
good
approach.
A
One
thing
that
I
would
like
to
do,
and
I
appreciate
everyone
that
was
able
to
make
it
to
this
call-
is
start
to
spread
out
the
love
a
bit.
So
is
there
anyone
who
could
take
ownership
of
starting
this
issue
and
help
help
us
break
it
down.
A
So
I'm
not
gonna
be
as
quick
on
the
fly
on
the
call,
but
I
can
follow
up.
I
think
we
have
one
issue
around
exploring
like
testing
a
rapper,
so
I'm
kind
of
imagining
this
would
be
more
of
a
an
epic
that
that
is
a
pfc
underneath,
if
that
makes
sense,
if
an
issue
underneath
the
epic.
C
A
Agreed-
and
I
think
that
this
epic
issue,
that
or
epic
should
maybe
define
the
criteria
by
which
we're
evaluating
these
approaches
and
this
performance
would
of
course
be
one.
So
if
one
approach
is
is
better
in
terms
of
performance
and
usability
and
all
the
above,
then
you
know
we'll
want
to
go
that
route,
so
fabio
you're
open
to
starting
a
new
issue,
a
new
epic,
sorry
and
I'll
point
you
to
the
existing
related
issues.
A
Okay,
yeah
any
other
discussion.
I
think
I
think
one
point
I
did
want
to
double
back
on,
so
we're
talking
about
the
technical
side
of
how
we
might
approach
this,
but
I
do
feel
that
in
the
discussion
last
you
know
two
weeks
ago
and
what
I'm
hearing
on
this
call
and
with
the
feedback
that
we're
seeing
is
that
we
agree
that
just
going
full
on
graphql
is
going
to
isolate
or
alienate
some
of
our
customers
who
depend
on
rest,
so
we're.
A
A
One
second:
do
we
have
any
feedback
on
that.
A
Okay.
Moving
on
to
the
next
item:
api,
v5
gerscores,
you
want
to
speak
to
that
yeah.
C
So
I'm
sorry,
I
moved
that
over
the
last
item.
I
thought
you
know
it
might
be
important
to
discuss
that
before
we
run
out
of
time
and
yeah.
I
wanted
to
thank
you
grant
for
the
the
the
meeting
you
hosted
with
a
customer
recently,
one
of
our
biggest
customers
that
are
using
gitlab.com
and
the
recording
was
awesome.
C
It
might
be
an
aspect,
important
aspect
as
well,
but
what
is
even
more
important,
in
my
opinion,
is
the
consistency
and
that
the
api
is
designed
to
support
the
biggest
customers
that
are
using
that
at
scale
and,
of
course,
rebuilding
our
rest
api.
A
little
bit
to
ensure
consistency
like
every
end
point
using
similar,
pagination
primitives,
and
you
know,
responses
designed
to
make
it
possible
to
actually
make
some
workflows
much
more
efficient.
That
would
basically
require
bumping
the
major
version
of
our
api
and
api
version,
five,
so
yeah.
C
I
will
try
to
find
the
recording,
link
and
paste
it
letter
the
agenda,
because
I
think
it
was
awesome.
So
again,
thank
you
grant
for
facilitating
this
discussion
and
yeah.
What
do
you
think
about
with
api
version?
Five
in
the
you
know,
you
know
designed
around
being
efficient
at
a
scale
and
consistent,
that's
requisite
for
efficiency.
B
B
C
So
you
know
how
it
could
look
like.
We
could
actually,
first
of
all
introduce
pagination
abstraction.
That
would
be
a
consistent,
consistent
across
all
end
points.
Right
now,
some
some
endpoints
are
using
the
like
legacy.
Pagination,
some
some
endpoints
are
using
the
new
pagination
and
there
are
other
challenges
that
are
making
it
difficult
to
use
this
api.
C
C
There
are
many
many
many
things
like
that,
so
building
a
backlog
of
things
we
could
improve
and
introducing
new
api
version
5
to
actually
accumulate
all
the
needs
of
the
biggest
customers
that
I
think
that
that
might
be
an
interesting
way
forward.
But
I
wanted
to
hear
your
opinion.
What
do
you
think
about
that?.
A
I'll
I'll
say:
first,
that's
you
know
spot
on
from
what
I'm
you
know.
I
know
you're
going
through
the
recording
with
with
one
customer,
but
I've
heard
some
of
these
complaints
and
issues
across
a
couple
of
conversations.
I've
had,
and
I
my
intent
is
to
get
these
all
all
these
recordings
shared
in
a
central
place
for
everyone
to
discover
here.
So
apologies
I
haven't
gotten
to
that
yet,
but
from
there
you
know,
I
am
hoping
to
break
it
down
into.
A
You
know
some
of
the
common
feedback,
we're
hearing
in
very
specific
cases,
and
I
think
I
I'm
not
going
to
recall
the
specific
case.
I
know
one
was
around
like
how
to
query
projects
and
that
you
know
you
get
a
list
of
of
projects,
but
you
can't
quite
get
all
the
details.
So
then
you
have
to
query
the
specific
project
so
just
like
these,
like
patterns
that
I
think
a
lot
of
common
like
a
lot
of
customers,
are
trying
to
do
commonly
they're
running
into
performance
issues
where
it
might
take.
A
You
know,
I
think
it
was
seven
hours
or
something
to
span
across
all
their
groups,
all
their
projects.
Just
to
get
one
bit
of
info
and
and
then
I
think,
with
graphql,
there
could
be
some
cases
there,
but
even
our
customers
have
even
tried
using
graphql
and
have
run
into
similar
problems.
So
I
think
something.
One
thing
that's
interesting
to
keep
in
mind
too.
Is
I'm
hearing
feedback
that
that
customers
don't
feel
that
our
data
model
is
best
suited
for
graphql
that
that
this
isn't?
A
You
know
this
isn't
quite
the
same
use
cases
as
someone
like
facebook
and
and
others
that
that
really
depend
on
kind
of
traversing
across
an
edge
of
a
node.
So
these
are.
These
are
things
that
seems
like
we're
trying
to
fit
into
graphql
and-
and
we
just
need
to
explore
further
how
to
make
this
a
bit
more
performant.
A
So
I
definitely
agree
and
thanks
for
mentioning
that
growers
I'll
I'll,
definitely
try
to
get
these
conversations,
that
I've
had
shared
and
I'm
gonna
be
having
a
lot
more
coming
up
soon
and
we'll
keep
everyone
posted.
C
Yeah-
and
it
would
be
great
to
have
some
kind
of
an
epic
or
issue
or
a
google
doc
to
collaborate
on,
because
there
are
some
ideas
like
introducing
bulk
apis,
that
we
don't
really
have
right
now
or
extending
our
group
api
so
that
there
are
bulk
operations
or
or
projects
and
stuff
like
that.
So
these
are
things
that
are
only
important
when
you
are
using
api
in
a
very
high
scale
and
so
far
we
kind
of
were
unable
to
you
know,
introduce
you
know
endpoints
like
that.
C
That
would
make
life
of
the
biggest
customers
much
easier
right
and
there
are
a
lot
of
opportunities,
a
lot
of
things
we
could
do
so
enumerating
that
somewhere.
You
know,
brainstorming
stuff,
like
that.
I
think
it
would
make
it
so
much
easier
for
us
to.
You
know,
prepare
our
api
version,
five
that
way,
and
I'm
saying
version
five,
because
in
order
because
our
current
api
is
kind
of
inconsistent,
you
know
we
need
to
break
compatibility
to
introduce
this
consistency.
So
it
would
be
the
next
major
version
of
our.
A
A
There
may
be
one
actually
all
right,
so
I
think
we're
pretty
well
at
time.
I'm
gonna
leave
this
one
as
read
only.
I
think
it
would
be
helpful
for
everyone
on
the
call
or
not
to
jump
back
and
kind
of
see
what
issues
are
you
participating
in
if
you're
not
maybe
see
where
you
can
and
then
share
some
updates,
because
I
think
we
have
some
good
ones
that
are
in
progress
and
would
be
good
to
see
where
things
are.
A
One
thing
I
did
want
to
leave
you
with
is
something
that
I've
been
brainstorming
as
well
going
through
this
feedback,
not
looking
at
this
as
official
by
any
means.
This
is
definitely
progress,
but
I'm
imagining
that
there's
essentially
a
hierarchy
of
needs
when
it
comes
to
the
developer
experience
and
we
need
to
achieve
the
bottom
levels
of
this
hierarchy
of
needs
before
we
can
really
truly
solve
those
that
are
above
it.
A
This
is
kind
of
my
view,
my
perspective
right
now
and
it's
you
know
influx
as
I
learn
more,
but,
for
example,
it
would
be
pretty
difficult
to
solve
customers
problems
by
focusing
on
automated
documentation
when
we
have
gaps
in
our
apis.
You
know
they're
still
going
to
have
problems,
they're
not
going
to
be
able
to
use
the
endpoints
or
solve
the
use
cases
that
they
have
while
yeah
the
documentation
may
be
great.
There's
there's
a
challenge
when
we
have
gaps
in
the
apis,
so
this
is
kind
of
where
the
way
I'm
seeing
it.
A
If
we're
talking
about
priorities,
how
we
order
our
work,
I
would
like
to
explore
this
further.
I
could
see
this
evolving
and
going
into
our
long-term
api
vision,
as
as
we
define
that,
but
anyway,
this
was
great
discussion
today.
A
If
you
didn't
get
a
chance
to
share
an
opinion
share
it
in
the
notes
and
yeah
look
forward
to
discussing
next
time,
I'm
hoping
to
have
more
of
a
prioritized
list,
maybe
by
the
next
call
that
we
can
start
to
really
break
things
down
for
and
want
to
see
more
more
involvement,
but
great
all
right
thanks.
Everyone
have
a
good
week.