►
From YouTube: API Vision Working Group #8
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
A
So,
first
of
all,
we
have
a
question
for
me
like
whether
we
have
any
progresses
in
the
gap
analysis.
We
have
an
issue
here
to
start
tracking
all
the
differences
we
have
between
rest
and
graphql
and
try
to
understand
their
like
yeah,
where
the
gaps
are
and.
A
On
the
verify
side,
I
spoke
with
some
engineering
managers
to
get
support
from
the
team
directly,
so
each
team
can
look
at
the
based
on
the
feature
category
or
or
relevant
models.
They
can
have
a
look
at
graphql
and
rest
in
the
points
to
to
to
do
this
graph
analysis
and
there
is
like
a
link
to
the
google
sheet
and
we're
wondering
there
is
anything
else
we
can
do.
I
was
thinking,
maybe
sharing
more
broadly
in
engineering
review.
B
Yeah,
I
think,
sharing
in
in
weekly
review
is
a
good
idea,
but
yeah,
I'm
not
sure
if
it
will
the
maybe
it's
better
to
have
like
a
people
responsible
for
it,
because
then
people
are
reading
it
and
maybe
some
people
looking
into
into
the
gap
analysis,
but
I
think
it
probably
won't
help
to
yeah
to
complete
it.
It's
probably
still
a
good
step,
but
I
think
if
you
want
to
to
yeah
get
it
done,
we
need
to
yeah
assign
people
who
are
responsible
for
this.
C
I
think
yeah,
I'm
not
even
sure,
so
we
can
start
with
engine
managers.
I'm
thinking
how
the
openshift
support
was
done
and
visit
there
they're
the
director
of
product
josh,
who
was
the
dri,
and
he
pinged
me,
for
example,
to
say
to
look
into
also
devops
and
as
I
only
own
some
parts
of
autodevops,
I
think
other
product
managers
saying
that.
Please
look
at
these
because
I
have
to
report
to
josh
on
all
of
that.
A
Cool,
so
next
point
is
from
alex,
so
there
has
been
some
discussion
in
in
the
way
of
we
can
share
implementation
between
rest
and
graphql,
and
so
alex
came
up
with
some
with
a
poc
where
we
that
allows
us
to
share
implementation
by
basically
calling
graphql
and
points
from
rest,
endpoints
defining
the
resting
point
through
way.
A
A
lot
of
persistent
queries
and-
and
I
only
had
a
look
like
earlier
before
the
meeting
on
this-
and
it
looks
like
really
promising
there-
might
be
some
yeah,
like
it's
jerusalem
performance
evaluation
to
be
done.
I
just
want
to.
D
A
D
Yeah,
I
think
that
this
interoperability
and
common
abstraction
layer
is
is
definitely
a
a
very
interesting
idea,
something
that
we've
we've
been
thinking
about
exploring
for
a
couple
of
years
already,
and
I
think
that
whatever
approach
we
are
going
to
take,
we
might
want
to
ensure
that
our
performance
does
does
not
degrade
like
a
lot.
D
We
know
that
there
are
customers
who
are
heavily
using
our
api
with
hundreds
of
requests
per
second
and
even
a
small
decline
in
in
in
how
all
performance
can
impact
everyone
gitlab.com,
you
know,
can
be
impacted
like
a
lot.
So
I
think
that
whenever
we
are
talking
about
changes
like
that,
we
should
also
think
about
a
method
to
prove
that
the
performance
will
not
get
reduced
like
a
lot.
So
probably
I
don't
know
if
this
can
be
done
in
like
an
automatic
way.
D
I
mean
that
we
probably
would
need
to
keep
the
rest
implementation
and
graphql
and
make
it
possible
for
both
implementations
to
coexist
at
the
same
time
for
the
same
endpoints,
and
then
perhaps
we
would
have
like
some
kind
of
a
feature
flag
that
would
allow
us
to
switch
between
implementations,
like
with
with
the
scientist
gem
of
githubs,
or
something
like
that
yeah.
I
I
just
wanted
to
add
this
note
about
remembering
the
performance
impact
that
is
possible.
Whenever
you
add
another
layer
in
between
basic.
A
C
Just
as
we
are
basically
generating
the
rest
endpoints,
does
it
open
up
the
possibilities
as
well
to
generate
according
to
open
api
spec
and
then
generally
spec
file,
perhaps
as
well
or
this
should
be
thought
about
totally
separately.
A
Yeah,
this
is
something
we
can
bring
a
point
we
can
bring
into
the
poc,
but
we
can
I'm
wondering
whether
we
can
discuss,
but
we
would
create
an
issue
about
this
reference
directing
the
poc,
so
we
can
put
more
discussions
in
the
issue
and
more
current
implementation
discussions
in
the
in
the
the
merge
request.
So
at
least
we
have
like
a
point
of
discussion.
Maybe
you
can
create
a
lot
of
an
issue
with
that.
If
alex
hasn't
done
that,
I
can
probably
create
an
issue
and
assign
to
the
merge
request.
A
And
the
next
point
is:
the
agenda
is
regarding
the
api
v5
now
I
think
this
mic
also
connected
with
the
discussion
of
of
the
poc,
where
it
might
be
part
of
of
that
of
this
epic,
even
the
pc,
if
we
can
only
implement
like
restful
endpoints
for
graphql
in
the
in
the
v5,
but
my
question
was
primarily
like
how
can
we
okay?
What
is
where
is
this
in
the
list
of
priorities,
giving
we
have
like
a
lot
of
things
at
the
moment
like
a
lot
of
open
issues
for
this
working
group.
A
Like
you
know,
we
have
these
discussions
about
sharing
implementation.
We
have
the
gap,
analysis
and,
and
a
few
other
things
already
in
progress.
So
I'm
wondering
how
much
time
should
we
invest
in
this,
or
is
this?
Do
we
want
to
put
it
in
a
roadmap?
I'm
not
sure
what
your
thoughts
are
about.
That.
D
Yeah,
so
I
think
this
is
interesting
and
you
mentioned
the
priorities
and
I
might
be
mistaken,
but
I
don't
remember
seeing
any
kind
of
a
list
that
includes
the
priorities
or
any
kind
of
description
of
what
is
more
important
than
interoperability
or
what
is
more
important
than
consistency
like.
There
are
a
few
things
that
we've
been
talking
about,
yet
I'm
not
entirely
sure
if
we
all
agreed
on
what
what
the
priorities
are,
and
perhaps
you
know
that's
the
first
thing
we
should
discuss
and
agree
on
before
we
can.
D
You
know,
plan
what
should
be
delivered
first
or
what
is
more
important.
D
I
don't
think
it's
too
much.
We
have
not
even
started
any
kind
of
implementation
yet
so
it's
all
this
explore
not
very
phase,
so
I
think
that
it's
not
too
much
but
yeah.
I
think
it
would
be
very
helpful
to
understand
what
the
priorities
are
here.
A
Yeah
my
concern
is
more
with
like
the
more
issues
and
more
things
we
add
to
the
scope,
the
bigger
the
scope
gets
like,
so
we
end
up
having
a
lot
of
issues
open,
so
should
we
yeah,
invest
more
in
the
gap
analysis,
and
with
this
we
have
like
some
data
that
we
can
use
to
leverage,
also
the
how
we
want
to
share
implementation
between
rest
and
graphql,
because
that
is
kind
of
an
important,
interesting
information
that
we
need
for
that
as
well,
to
see
at
least
you
know
if
we
need
to
upgrade
to
api
v5.
A
What
are
the
end
points
where
we
have
discrepancies
and-
and
that
could
be
solved,
maybe
by
sharing
the
implementation.
So
I
think
these
two
issues
are
probably
the
most
important
at
the
moment
and.
D
Yeah,
I
think
that
the
number
of
work,
streams
or
issues
that
are
in
flight
may
be
actually
relative
to
the
progress
we
can
make
on
it.
So
it
depends
on
the
number
of
people
who
can
toggle
those.
It
depends
on
the
amount
of
time
we
can.
We
can
spend
on
on
them
and
I
think
it's.
The
problem
here
is
more
like
the
capacity
than
the
amount
of
things
that
are
in
flight.
A
Okay,
yeah:
let's
bring
this
to
ground
and
see
next
week;
okay,
what
kind
of
change
which
change
we
can
make.
A
Cool
anything
else,
any
other
discussions
points.