►
From YouTube: Incremental Delivery Working Group - 2023-09-11
Description
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools. Get Started Here: https://graphql.org/
B
But
yeah
it
looks,
looks
like
it's
going
to
be
a
a
good
event.
B
A
A
Oh
for
for
this
meeting
we
have
agenda
files
in
the
repo
like
for
the
main
meetings,
so
I
think
we
want
everyone
to
add
themselves.
B
C
Just
looking
at
the
the
issue,
Robert
I,
don't
I'm
not
sure
that
I
follow
I'm,
not
familiar
with
with
the
algorithm
that
yakov's
using,
but
in
the
algorithm
that
I
would
use
that
would
just
evaporate,
like
the
defer
would
just
not
be
relevant
anymore.
A
Yeah
I'll
I'll
I'll
talk
through
it
yeah,
so
so,
let's
get
started.
I
I
just
mentioned
if
to
Benoit.
If
you
haven't
already
put
yourself
on
the
agenda,
I
put
the
link
in
the
zoom
chat.
A
By
being
here,
you
agree
to
the
membership
agreement,
participation,
contribution,
guidelines
and
code
of
conduct
and
the
yeah.
The
only
topic
that
I
wanted
to
that
I
had
on
the
agenda
right
now
is
this
foreign.
A
This
query
that
I
put
in
the
Discord
I'll
share
my
screen.
One
second.
A
Yeah,
so
in
collect
fields
in
this
spec
right
now
we
have
a
set
of
visited,
fragments
that
when
we
are
going
through
collect
Fields
here,
if
you
encounter
a
named
fragment
spread,
we
Traverse
into
the
selection
set
of
that
name,
fragment,
spread
and
add
that
fragment
to
the
set
of
name
fragments
the
set
of
visited
fragments.
A
A
A
We
could
just
say
that
if
the
if
a
fragment
spread
does
have
defer,
we
don't
add
it
to
that
set
and
it'll
get
traversed
again,
and
then
we
can.
A
The
selection
set
we'll
get
processes
both
having
defer
and
not
defer
and
later
on.
The
algorithm
would
not
defer
them
because
that's
what
we
do
when
there's
a
mixture
of
both,
but
this.
C
Is
I
think
there's
a
little
bit
of
a
misunderstanding
here:
Rob
there's
a
the
visited
fragments
is
immutable
so
when
you
add
something
to
visited,
fragments
you're
only
doing
that
as
you
recurse
through
there
once
you're
back
out
of
of
the
fragment
so
like
when
you're
then
looking
at
the
next
fragment
positive
fragments
doesn't
include
that
anymore.
A
Yeah,
that's
it's
not
what
graphql
JS
is
doing.
Graphql
JS
has
one
set
that
it
passes
around
and
and
mutates
as
you
iterate
through.
C
Because
the
regular
graphql.js,
not
the
one,
that's
modified
for
streaming
to
fur,
because
that
would
surely
that
would
just
pull
down
immediately.
If
you,
for
example,
had
me
and
friend,
and
both
of
them
browse
the,
let
me
write
a
quick
query
into
the
chat
that
wouldn't
work.
If
that
was
true,
oh
it
seems
to
change
this
chat.
A
But
this
set
is
only
for
the
same
level
like
right
once
you
like
go
into
because
first
you're
going
to
execute
the
fields
under
me
that
has
that
does
like
collect
Fields
there
with
the
with
the
visited
fragment
name
set,
then
that
gets
returned.
Then,
once
you
start
executing
best
friend,
and
then
you
go
into
that
selection
set
that's
a
whole
new
set
right.
C
Well,
I
suppose
I
was
going
to
say,
Skip
and
include,
but
actually
those
would
never
be
added
to
the
to
the
visitor
fragments
anyway,
because
they've
not
been
visited,
because
the.
C
Yeah,
okay,
let
me
actually
load
the
spec.
This
is
a
thing
where,
if,
if
it
is
written
in
that
way,
we
would
have
to
change
it
for
Stream
interfer
So
that
we
didn't
get
this
issue.
C
No,
you
were
right,
it
does
it
on
a
selection
set
basis,
so
it
won't
visit
the
same
selection
set
more
than
once
and
the
Skip
and
include
are
handled
themselves
before.
We
then
consider
adding
things
to
the
visited
fragments,
but
that
that
would
have
to
change
with
stream
and
defer,
in
my
opinion,
because
effectively
if
the,
if
the
fragment
has
a
defer
or
something
like
that,
you
would
still
need
to
browse
through
the
any
fragment
that
didn't
as
you've
demonstrated
here
right.
A
So
this
does
like
protect
you.
C
Sorry
just
to
interrupt
again,
this
is
this
is
an
issue
in
graphql
in
general,
for
where
fragments
have
directives
on
them.
A
C
I
mean
custom
directives,
do
arbit
tree
stuff
right,
it's
not
defined
in
the
spec.
What
they
do,
it's
kind
of
the
point
of
having
them
is
so
that
you
can
have
it
do
something
experimental
much
like
how
relay
do
all
their
different
null
handling
using
them.
That
is
like
effectively
a
different
style
of
execution,
but
it's
client-side
execution
rather
than
server
side.
A
C
Yeah,
that's
what
I'm
thinking
I'm
thinking
that?
Actually
this
is
a
broader
problem
than
just
for
defer
and
actually
what
we
want
is
a
validation
rule
that
says
that
other
than
other
than
Skip
and
include
all
of
the
all
of
the
directives
on
named
fragment,
spreads
of
the
same
position
in
the
document
must
be
the
same.
A
Yeah
I'm
I'm
not
putting
the
way
I'm
thinking
about
this
into
words
and
I'm,
not
communicating
this
well
right
now,
but
I'm
thinking
that,
like
you
know,
you
don't
have
to
follow
these
rules
exactly
as
long
as
you
have
the
same
result,
if
you
have
like
custom
directives
that
are
changing
the
way
that
you
execute,
then
I
think
that
you
necessarily
would
not
be
following
the
execution
rules
exactly
and
you
would
have
to
like
update.
A
Have
your
execution
handle
it
any
way
that
you
want
to,
and
if
we
added
a
rule
that
for
any
directive,
you
can't
have
the
same
directive
on
the
same
fragment,
spread
different
directives
on
the
same
fragment,
spread
that
could
make
someone
that
did
change
how
the
execution
works.
You
have
your
query,
not
work
anymore.
If
they
add
that
validation.
C
Yeah
we'd
effectively
have
to
add
two
classes
because
I
don't
like
special
casing
if
and
include,
which
is
what
we're
doing
currently
so
really
there's
just
like.
We
have
repeatable
directives
where
that
was
a
keyword
that
we
added
later
when
we
realized
we
needed
it.
This
feels
like
a
directive
on
fragment
that
is
allowed
to
differ
versus
one
that
isn't
then
again
I
mean
differing
in
this
regard.
C
If
you,
if
you
step
back
and
ignore
that
at
the
spec
for
a
moment-
and
you
look
at
the
query
that
you've
written
it
seems
fairly
obvious
what
that
should
do
right,
it
should
not
defer
anything
so
the
first
one
you
as
a
human
looking
at
it
would
say
well
I've
deferred
it,
but
I've
also
not
deferred
it.
So
I'll
just
get
it
straight
away
and
the
deferral
go
away.
That's
the
desired
behavior
and
really
the
spec
should
give
us
a
way
to
for
that
behavior
to
happen.
I
think.
C
C
A
A
For
this
case,
what
ends
up
happening
in
yakov's
implementation
is
that
the
nothing
is
deferred,
but
you
do
get
a
pending
and
completed
with
this
for
this
label.
A
I
thought
that
was
a
little
bit
strange.
So
that's
why
I
brought
this
up
and.
A
A
C
It
doesn't
simple
but
expensive,
fix
to
this
problem,
which
is
in
the
collect,
Fields
algorithm
to
effectively
initialize
the
visited
fragments
just
inside
of
step.
Three.
C
The
issue
with
that
is,
it's
less
efficient
right.
It
means
for
every
single
selection.
We
are
having
to
recreate
this
set,
which
is
you
know,
not
a
cheap,
not
a
free
operation,
but
that
would
that
would
solve
it.
Then
you
just
browse
over
the
selection
sets
multiple
times
which
already
works
for
overlapping
selection
sets
if
those
two
fragments
had
different
names,
you'd
already
lap
over
them
twice
anyway,
so
it
doesn't
seem
like
a
disaster.
A
C
I
think
we
I
want
to
say
I
think
we
definitely
need
the
ability
to
both
defer
and
not
defer
a
fragment,
because
that's
not
generally
going
to
happen
in
this
kind
of
situation.
It's
going
to
happen
in
like
deep
down
in
a
component
tree
where
you
know
one
branch
has
deferred
the
Avatar
and
in
a
completely
different
branch
it
hasn't
deferred
the
Avatar
and
I
think,
especially
in
relay
projects.
You're
gonna
see
that
come
up.
C
C
True
with
Skip
and
include.
B
A
A
C
Yeah
I
think
so
and
effectively
that
selection
set
would
be
a
merged
selection
set,
but
it
would
have
both
of
those
fragments
spreads
in
could
be
effectively.
Id
Avatar,
defer
title
and
then
Avatar
again.
A
I
mean
I
think
the
easy
way
to
do
that
and
it's
what
Yakov
already
did
was.
If
the
fragment
spread
has
a
deferred
fragment,
you
don't
add
it
to
visited,
fragment
names.
C
I
I
think
I
would
address
it
a
little
bit
like
how
I
said
before,
but
we
only
actually
need
to
do
it
when
there
is
a
fragment
spread
so
effectively
you
before
you
recurse
into
the
fragment.
C
I
think
we
have
to
have
that
anyway,
because
otherwise,
things
like,
if
you
put
live
on
a
fragment,
for
example,
it
will
matter
which
order
you
do
it
in
whether
or
not
anything
even
sees
it
I.
Guess,
though,
I
guess,
if
you're
writing
a
server
that
has
live,
you'd
have
a
custom
execute,
like
you
said
before,
it's
challenging.
C
If
you
have
right
so
you
asked
about
stream.
If
you
have
stream
and
you
have
a
field
that
is
both
streamed
and
not
streamed
in
completely
different
document
paths,
but
they
result
in
the
same
response
paths.
C
Then
what
will
happen
is
it
will
just
go
into
the
collected
Fields
so
you'll
end
up
with
all
of
those
different
fields
that
are
the
the
streamed
field?
Well,
the
array
field
in
both
it's
streamed
and
non-streamed
forms
so
I,
don't
think
that
causes
any
issues.
It's
because
it's
because
fragments
are
kind
of
ethereal.
I
think
that's
really.
The
issue
I.
A
What
what
we
did
right
now
for
stream
and
what
like
we've
had
for
for
the
past
few
years,
was
that
we
have
the
validation
rule,
that
you
can't
have
different
streams
and
then
we
are,
and
then
the
execution
just
looks
at
the
first
node
to
decide
like
what
the
initial
count
is
and
after
the
fields
are
collected,
we
just
look
at
the
first
one
and
be
like:
what's
does
it
have
stream?
Are
the
fields
collected?
Well,
it
doesn't
have
stream.
A
What's
the
initial
count,
it
could
be
more
complex
and
look
at
all
of
them
and
figure
out
like
what's
the
minimum
number
of
things
that
need
to
be
in
the
initial
payload,
but
for
Simplicity
we
didn't
do
that
again,
thinking
that
if
I
think
we
got
feedback
from
Facebook
that
that
was
what
they
were
doing
and
it
has
wasn't
really
a
problem
for
anyone.
So
we
figured
that
if
it
was
a
problem,
we
could
do
something
smarter
in
the
future.
C
Thinking
more
about
this
and
applying
it
to
some
of
the
other
specs
that
we've
got
coming
up,
there's
Matt
Mahoney's,
fragment
variables,
spec
and
that
again
will
need
this
Behavior
to
be
different
because
it
will
be
a
fragment
spread,
but
it
will
be
as
fragment
spread
with
parameters.
C
So
the
fact
that
you
visited
it
with
one
set
of
parameters
shouldn't
mean
that
you've
visited
with
it
with
another
I
think
what
I'll
do
Rob
is
I'm
going
to
propose
a
change
to
the
spec,
where
we
literally
change
the
collect,
Fields
algorithm
and
we
push
it
down,
and
we
say
this
is
to
make
space
for
stream
to
First,
make
space
for
the
fragment
variables
and
for
various
other
situations.
C
Don't
think
it
will
be
in
step
three,
it
will
be
just
before
step.
D
part
IX,
oh
yeah,
it
will
be
it'll,
be
just
before
dii
effectively
will
create
another
copy
of
visited,
fragments
and
then
add
ourselves
to
that
copy
and
we'll
do
the
same
thing
in
in
e
as
well.
C
A
C
I
have
to
I
have
to
read
up
on
it
and
think
about
it
a
bit
more.
Is
it
bad?
It
is
marginally
inefficient
in
a
way
that
engines
can
optimize,
but
with
the
caveat
that
they
need
to
be
aware
that
the
reason
for
doing
this
was
to
make
it
so
that
when
we
do,
for
example,
the
variable
fragments
fragments
with
variables
or
parameters
that
everything
works,
as
you
would
expect
in
the
case
that
the
fragment
had
variables,
we
would
have
to
walk
it
twice
right.
C
I
think
it
would
be
better
to
walk
it
twice
than
to
do
it
with
the
keys
approach
just
immediately
I
think
how
would
you
break
this
well
you'd
feed
in
like
a
base64,
encoded,
Avatar
image
as
one
of
your
variables
and
all
of
a
sudden.
Your
key
is
now
that
yeah.
C
Can
you
drop
a
link
to
this
into
the
incremental
delivery
chat.
A
C
A
C
A
C
A
A
C
Okay,
I'm
not
going
to
be
about
next
Monday
because,
of
course,
I'll
be
probably
adjusting
to
time
in
San
Francisco.
A
Going
to
be
getting
there
on
Tuesday,
so
I'll
probably
be
at
the
oh,
the
other
conference
towards
the
end
of
the
day
on
Tuesday
yeah,
I'll,
see
you
there.
B
That's
right
have
a
good
have
a
good
conference.
Thank
you.