►
From YouTube: Incremental Delivery Working Group - 2023-02-06
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/
A
A
B
Just
I
I
mean
I'm,
not
even
sure
that
those
temperatures
exist.
I
would
say.
A
I
know
it
was
a
little
bit
crazy
I.
The
funny
thing
is,
we
have
you
know,
there's
multiple
weeks
a
year
where
we
get
to
watch
the
Canada
geese
leave
our
country
because
they're
smart
and
we
should
all
just
like
do
what
they
do
and
leave
the
country
but
yeah.
Instead,
we
have
minus
40
days
where
we
stay
inside
and
think
long
and
hard
about.
Why
did
we
not
leave
with
the
geese.
B
I
can't
imagine
the
the
energy
consumption
that
you
need
to
do
to
balance
that
arrows.
A
Really
high
yeah
the
yeah,
the
the
area
that
we
live
in
in
the
province
that
I
live
in
anyways,
the
the
building
code
regulations
are
pretty
high
when
it
comes
to
insulation
for
houses.
For
that
exact
reason.
A
So,
for
the
actual
inspections
to
pass,
you
have
to
have
certain
ratings
of
insulation
put
in
all
new
houses
so
that
they're
trying
to
help
with
energy
consumption
but
yeah.
It's
high,
absolutely.
A
But
let's
see
see
if
he's
I
think
he
was
anyways.
I
was
interested
to
see
if
he
made
any
progress
on
his
prototype
stuff.
He
was
working
on.
A
What
how
is
everybody,
though,
this
Monday?
Where
do
we
want
to
kick
things
off.
D
I
just
edited
the
this
discussion.
I'll
put
it
in
the
chat
to
just
I
think
list
out
all
the
options
that
we
discussed
yep
so
far,
so
we
have
it
in
writing.
A
Yeah
and
I
saw
that,
oh,
you
edited
the
actual.
The
initial
discussion.
D
D
Did
some
work
on
in
graphql.js?
Yes,
maybe
you
want
to
update
us
on
that
too.
E
Yeah
sure
so,
I
I
just
put
up
as
a
straw
man
the
implementation
that
that
I
have
for
total
deduplication.
E
It
relies
heavily
on
on
weak
Maps,
essentially
creating
each
each
node
in
the
response
is
associated
with
with
a
with
with
its
path
which
can
then
you
know,
be.
You
know
across
all
the
initial
payloads
and
all
updated,
payloads
yeah.
You
know
it
can
point
to
a
stable
object
which
then
keeps
track
of
whether
it's
been
delivered
or
not.
E
It
relies
heavily
on
weak
maps
to
do
that.
Without
increasing
memory,
consumption,
meaning
Benji
was
pointing
out
how
we
might
want
a
stream
brother
languages.
F
E
Of
data,
and
so
instead
of
using
a
map,
we
use
a
weak
map
in
order
to
retain
that
ability.
E
If
we
were,
you
know,
you
can
easily
translate
to
other
languages
just
by
using
a
map,
but
then
you
run
into
memory,
consumption
issues
and
so
I
think
it's
it's.
You
know
it's.
It's
sort
of.
It
shows
that
it's
definitely
possible
to
implement.
You
know
theoretically
possible,
but
it's
going
to
require
I.
E
Think
a
lot
of
refactoring
to
to
get
I
mean
and
definitely
possible
to
do
it's
just
going
to
require
a
lot
of
refactoring
to
get
rid
of
the
weak
maps
and
to
to
to
you
know
to
have
the
the
you
know,
an
implementation
that
doesn't
use
that
they
might
be
more
easily
translatable.
So
that's
I
mean
so
that's
what
I
got
so
so
far
I
mean
I,
don't
know
if
that
helps
us
make
a
decision,
but
it's.
A
It's
something
yeah
interesting.
You
know
it's
interesting
that
when
we
consider
graphql.js
as
being
there
reference
implementation,
do
we
actually
consider
that
the
technology
used
to
build
the
library
needs
to
be
carefully
weighed
because
other
libraries
are
using
graphql.js
as
the
reference
implementation
they're
mirroring.
So
you
know
talking
about
the
weak
Maps
being
supported
with
JavaScript,
for
example,
like
is,
that
is
that
type
of
technical
detail,
something
we
should
keep
in
mind
when
we're
trying
to
add
new
features
to
graphql.js
that
other
languages
might
not
support
it.
F
Yeah,
so
I
I
would
be
more
worried
about
not
not
about
other
languages,
but
the
other
implementation
of
execution.
So
we
have
like
a
free
main
one.
One
is
like
I
I
would
say,
like
interpretation
style
thing
using
like
compiler
Theory
graphql
tests,
its
interpretation
thing,
it's
work
with
ist
it
based
on
IC.
It's
like
executed
everything
in
runtime.
F
It's
one
approach.
Second
approach
is
like
query
points.
It's
basically
like
Advanced
version
of
interpretation.
It's
in
interpretation
to
us
was
planning
ahead
of
time,
and
the
third
approach
is
like
co-generation
and
so
like,
for
example,
with
this
approach.
If
you
generate
in
code,
you
need
to
generate
quotes
that
have
like
option.
F
If
something
is
generated
could
need
to
how
I
can
stay
it
now
and
inside
the
states.
It's
need
to
understand
if
stuff
is
already
sent
or
not,
and
based
on
that,
it's
need
to
have
IFS.
If,
if
like
this
thing
was
already
sent
in
this
case,
I'm
not
sending
it.
If
this
thing
is
like
not
sent
I'm
like
and
I'm
executing
it
right
now,
I
need
to
send
it
and
Marcus
wagonist
state
so
like
for
code
generation
for
people
who
try
to
do
exit.
F
Oh
boy
generate
other
thing
and
execute
that
thing.
It's
a
little
bit
different
from
like
interpretation
approach
where
we
don't
have
anything
specific
to.
We
don't
generate
like
stuff
specific
tourism
or
we
just
like
GoPro
IST
and
like
maintain
Maps
of
what's
shaped
and
whatnot,
so
I
I
would
be
worried
more
instead
of
like
because
in
other
languages,
maybe
not
weak
Maps,
but
you
can
use
Global,
think
and
you
can
manually
destroy
it
after
the
query
is
finished,
for
example,
so
you
can
imitate
weak
Maps.
F
Okay,
so
service
query
pointers,
ideas,
the
same
implementation
is
different,
so
we
think
basically
change
the
model
a
bit.
So
previously
we
we
was
this.
We
knew
everything
about
the
shape
before
we
could
knew
everything
about
this
shape
from
a
query,
so
we
can
do
like
predict
all
the
shape
and
do
like
quite
a
panel
generate
code.
Now,
it's
weird
like
around
time,
I
think
in
the
mix.
A
E
Yeah
so
so
then,
let's,
let's
just
for
a
second,
then
maybe
we'll
want
to
get
somebody
else
want
to
get
back
to
it.
But
if
we're
putting
aside
the
weak
Maps
detail
for
a
second,
was
there
a
different
way
of
implementing
this?
That
you
think,
would
not
have
some
of
the
translatability
that
issues
that
you
mentioned-
yeah
I
mean
so
meaning
yeah.
So
this
is
basically
again
I
put
it
up
as
a
straw
man,
because
it
wasn't
exactly
sure
the
direction
that
you
might
that
you
might
take
so
yeah.
F
Yeah
in
ideal
scenario
we
have
like
they
have
like
last
time.
We
discussed
like
free
constraint
constraints
either
like
and
you
had
that,
like
basically
four
focus
on
it,
it's
like
it's
a
square
right
now
you
can
easily
is
have
like
predictable
response
format
so,
like
you
know,
for
sure,
like
what
path
get,
what
and
from
acquiry
and
you
can.
Another
requirement
is
to
have
one
pay.
F
What
per
path
my
proposal
break
but
requirement
your
proposal
breaks
requirement
of
knowing
what
ship
ahead
of
time
was
shipped
under
what
path
there
is
another
think
when
you
can
break
the
duplication
you
can
you
can
ship
One
path
or
one
period
per
pound
and
you
can
and
you
can
have
predictable
shape
of
that
period,
but
you
need
to
have
duplication
of
fields
so
I'm
like
and.
F
The
fourth
option
you
can
have
like
one
per
word
per
path:
you
can
have
4G
duplication.
You
can
have
like
a
predictable
shape,
but
you
need
to
you
need
to
work
some
of
responses
until
you
know
for
sure
that
other
responses
already
shipped
so
I
think
it's
like.
Now
we
have
like
we
Square.
F
A
That
makes
sense
so
with
that
in
mind,
because
I
think
that
captures
things
really
well
do
we
agree,
first
and
foremost,
here
I'm
going
to
share
my
screen.
A
Maybe
let's
just
start
and
all
agree
that
we
have
five
options
on
the
table.
Let's
just
make
sure
we
don't
think
there's
a
sixth
or
a
seventh
is
this
so
as
Rob
broke
out
here.
Do
we
all
agree?
These
are
our
options
right
now,
so
no
deduplication
we're
going
to
make
it
optional
versus
further
duplication
is
optional.
I
can't
say
that
word
today,
for
whatever
reason
or
I
believe
Yakov
is
what
your
PR
is
demonstrating.
A
That
fold
deduplication
is
possible
and
then
five
is
the
the
option
that
you
were
talking
about,
Ivan,
where
there
are
certain
constraints
that
we
could
get
rid
of,
so
it's
fully
duplication
but
removing
the
one
payload
per
path
constraint.
So
it's
a
little
bit
less
intensive.
E
A
D
It
and
it's
not
what
you're
I
have
the
Locking
payloads
like
in
a
separate
comment
on
the
bottom,
because
just
that
we
discussed
it
and
yeah
it's
it's
all
the
way
at
the
bottom.
That
second
to
last
comment
yeah
so
like
we
talked
about
it
last
time,
but
pretty
much
ruled
it
out.
I
thought
so
that's
documented
here,
but
I'm,
not
gonna,
didn't
have
it
listed
in,
like
the
other
options
that
at
the
top
okay.
B
B
E
F
D
B
C
Or
it's
kind
of
three
option:
A
is
like
EU,
we
don't
say
what
happens
below
the
initial
payload
and
option
b.
Is
we
have
some
static
analysis
rules
on
what
happens
with
the
or
a
is?
We
know
what
happens
with
the
initial
payload?
We
don't
know
on
subsequent
B.
Is
we
don't
know,
or
we
know
on
initial
we
might
know
on
subsequent
if
it's
statically
analyzable
there's
some
rules
still
about
what
that
is
on
further
payloads.
A
Okay,
so
it
sounds
like
Robert.
F
E
F
Can
agree
to
the
base
ground
like
that's
what
I
was
gonna,
say,
Okay,
options
that
make
sense
as
a
like,
at
least
as
a
backup
plan
for
in
most
cases
and
in
investigate,
like
Whatley
basically
said
like
last
time,.
F
Is
it's
like?
We
can
evaluate
bunch
of
options,
but
it
would
be
great
to
have
like
a
list
this
Troublesome
option
or
the
best
out
of
once.
We
discuss
right
now
and
we're
all
kind
of
very
I'm,
Mike
I'm
I'm,
for
example,
for
partial
deduplication.
If
we
cannot
agree
what
other
trade-offs
like
make
sense
like
having
I'm
for
having
like
algorithms
back
meaning
server
servers,
behave
like
predictable
as
much
as
possible
as
as
much
as
it
makes
sense
so
know
the
duplication.
For
me,
it's
like
it's
create
a
problem
optional
deduplication.
F
It's
like
it
would
be
weird
if
you
get
like
some
servers
will
try
and
some
not
especially
since
we
can
document
with
algorithms.
It's
not
super
complicated
algorithms,
so
I'm
like
waiting
for
option
free
plus,
like
what
bunch
of
propose
like
they
duplicate
as
much
as
possible
and
to
maybe
in
the
eliminate
Option,
One
and
Two
from
a
list.
D
And
so
so,
I
do
have
listed
out
for
both
three
and
four
that,
like
this,
we're
specifying
that,
like
this
amount
of
deduplication,
has
to
happen.
But
but
servers
are
allowed
to
do
it
even
more
efficiently.
Maybe
they
do
Implement
yakov's
algorithm
with
weak
Maps
or
something,
and
is
that
like
is
that
is
that
okay,
like
we,
should
leave
that
optimization
open
in
this
back.
D
F
Look
how
I
constraints
and
I'm?
What
is
it
if,
if
we
leave
constraints
unspecified,
if
they
constrain
or
not,
some
servers
will
assume
that
constraints,
but
some
coins
will
assume
about
constraints
based
on
working
with
particular
coin.
So,
for
example,
graphql.js
Implement,
like
will
break,
will
not
break
we'll,
have
predictable
shape,
but
graphql
tools
will
have
modifications
that
Implement
and
like
using
weak
map
implementing
different
shape,
and
if,
if
somebody
will
do
like
accordion,
we
will
have
a
client
working
with
only
graphql.js
risk.
F
C
And
that
we
have
some
form
of
test
case
or,
like
example,
shape
and
graphqljs,
even
if
it's
like,
oh,
not
even
at
the
necessarily
executor
level
but
like
the
like,
hey.
This
is
an
allow,
a
permitted
response.
I,
don't
know,
I,
don't
know
how
you
do
that
in
graphql.js,
unless
we
like
had
two
different
implementations
which
maybe,
while
we're
in
like
stage
four
or
even
like,
while
the
spec
does
not
specify
what
the
algorithm
is,
it
might
even
make
sense
to
have
both
like
and
have
both
algorithms
and
a
flag
or
something.
F
F
And
option
four
is
like
represent
this
branch
of
thought:
yeah.
C
Think
go
ahead,
so
I
talked
with
Kawaii
about
option
six
about
Yvonne's
proposal,
and
one
of
the
things
that
came
up
was
like
at
the
limit.
If
you
put
a
defer
on
your
single
root
field,
this
essentially
allows
infinite
responses
to
come
back
or
as
many
responses
like
one
response
per
field
and
so
or
per
path
and
like
I,
don't
I
think
that
would
be
very
surprising
to
end
up
with
like
a
server
that
justifies
decides.
Oh
once,
I
hit
defer
now
I'm
streaming
in
every
field,
because
that
would
be
spec
compliant.
F
Yeah
we
discussed
it
was
working
group,
so
updated
version.
I
will
write,
updated
version,
saying
saying,
like
server
should
batch
batch
up
like
yeah.
F
D
C
But
unless
there's
an
at
defer
on
a
field,
it
would
be
very
surprising
to
basically
get
that
in
basically
at
defer
tells
you
what
the
like
locations
of
the
batched
response
should
be,
and
so
right,
if
you
have
at
defer
on
every
single
field,
then
you
you
are
expecting
essentially
a
stream
of
responses
and
that's
fine
but
you've
you,
as
the
client
person,
have
explicitly
asked
for
that.
In
that
case,
yeah.
D
A
D
Oh
sorry,
for
for
option
four.
What
what
I'm
imagining
is
that
the
spec
like
describe
the
spec
describes
an
algorithm
that
does
is
to
do
deduplication
between
the
initial
payloads
and
defers
and
deferrers
that
have
this
parent-child
relationship
and
that's
basically
the
ones
that
we
said
had
to
be
delivered
in
a
certain
order.
I
think,
but
there's
a
note
that
says
that
you're
allowed
to
optimize
further
and
that
any
any
defer
any
Fields
could
be
dropped
as
long
as
those
fields
were
sent
in
a
previous
response.
D
C
I
think
I
think
so.
The
the
other
thing
there's
the
flip
side
of
that,
which
is
that
we
are
enabling
servers
to
not
depend
on
like
servers,
do
not
are
not
required
to
block
on
a
on
fulfilling
a
defer
that
is
like
ready
to
go
just
because
a
a
different
one
that
they
might
be
able
to
duplicate
with,
isn't
right.
That's
basically
yeah.
F
One
qualification
if
we
say
that
stuff
can
be
dropped
from
my
payload
if
it's
fulfilled
in
parallel,
not
child
but
intervention,
but
in
parallel
sequence
of
like
differ.
So
that
means
we
force
client
to
merge
everything
into
one
tree.
It's
the
same
requirement
as
my
proposal
help,
but
I
want
to
make
it
clear
that
now
you
cannot
do
like
getting
a
path.
Why?
F
If
client
registrate
for
particular
fragment
without
my
and
like
Jaco
proposal,
you
can
get
this
certain
path
from
initial
response
and
you
get
like
with
by
what
from
from
incremental,
you
can
match
it,
and
you
get
a
result
now
you
need
to
now,
since
your
data
can
be
shipped
under
different
path
so
like
in
Robo
example,
if,
if
I
can,
if,
if
you
have
like
a
branch,
a
and
Branch
b
and
branches,
so
field
a
executed
faster,
it's
mean
you
get
with
data
in
in
wet
Branch,
under
like
different
path.
F
So
now
this
with
like
shorter
pop
is
satisfied.
Yeah
like
like,
for
example,
so
field
B,
is
faster,
a
is
faster
and
you
get
it
so.
F
Your
E
and
F
is
shipped
under
above
A
and
B,
but
but
it
satisfies
before
under
path
under
empty
path,
and
this
makes
sense
only
if
you
maintain
one
one
tree
and
do
merge
into
three.
F
If,
if
you
get
like
empty
path
from
initial
response,
meaning
like
object
with
just
seeing
the
and
you
apply
stuff
that
you
receive
under
empty
path
which
is
GH
and
but
and
so
field
B
you
receive
I
can
complete
data.
F
You
miss
E
and
M
and
I'm
like
for
for
every
every
budget
to
understand
this,
and
we
also
need
what
document
button
is
back,
because
clients
need
to
be
cautious
that
that
contain
not
only
under
like
wet
path
inside
the
initial
response
and
wet
pump
on
the
incremental,
but
also
in
other
parts.
Inside
incremental.
A
F
Yeah
go
out
for
us
to
understand
and
for
like
first
document
and
spec,
like
specifically
saying
like
have
example
and
explain
it's
possible
and
you
should
call
the
client
in
a
way
that
supports
that.
Basically,
you
do
like
patching
you
patch
initial
response
and
you
get
the
whole
data
for
particular
path
from
web
budget
3.
F
you
you're,
not
not
trying
to
like,
be
clever
and
use
like
initial
response
or
part
of
initial
response,
and
one
one
incremental
purpose
that
you
get
yeah.
Okay,.
E
F
Yeah
yeah
because
like
if
server
can
decide
that
server
already
sent
that
on
the
different
part
it
can
drop
at
zero
and
you're.
Not
even
you
cannot
even
predict
if
it
was
dropped
due
to
in
one
fragment
condition
like
on
some
type
or
it
was
dropped
like
for
some
other
reason
so
like,
and
you
cannot
without
like
complex
query.
Analysis
should
not
know
like
which
path
to
work,
so
basically,
like
simplest
solution,
is
to
maintain
patch
initial
response,
with
average
incremental
we
get,
and
if
you,
when
you
get
particular
path.
F
So
when
you
get
like
first
before
from
example
under
path,
a
b,
you
need
to
you
need
to
patch
everything,
and
you
need
to
go
to
like
patched
increment
patch
the
initial
response
and
get
stuff
on
the
a
b.
F
So
everything
should
go
through
like
store,
not
store,
but
like
representation
of
of
by
what
that
you
patch.
A
Okay,
well
sounds
like
we're.
Leaning
towards
four,
but
I'll
just
play
devil's
advocate
for
a
second
here
yakov's
work
is,
is
pointing
towards
the
fact
that
number
five
is
possible.
There's
complexity,
there's
a
lot
of
work
that
would
need
to
be
done.
There
are
possibly
limitations
in
other
programming
languages
if
they
try
to
refer
to
graphql.js
as
being
what
they're
mirroring.
F
F
So
like,
if,
if
I
correctly
understand
option
four
I
want
you
to
do
option
five,
if
you
want
so
basically
can,
but
it
doesn't
require
you
to
do
it,
so
it
doesn't
say,
should
it
say:
can.
D
F
Like
we
kind
of
assume,
graphql
is
written
in
a
way
that
should
be
easily
replicatable
and
it's
a
simplest,
no
I
kind
of
simplest
implementation.
If
you
want
to
have
like
some
other
trade-off
or
some
Advanced
option,
you
do
your
own
stuff.
So
if
you
implement
option
five,
it's
mean
like
technically,
anybody
can
do
option
five,
so
yeah
I'm
like
it
would
be
weird
if
you
implement
option
five
but
recommend.
A
D
F
D
I
mean
I
feel
like
that.
Graphql.Js
should
literally
be
doing
what's
in
the
spec
algorithms.
Exactly
if
we're
specifying
four,
then
that's
what
it
should
do
or
if
it
does
want
to.
If
we
do
figure
out
how
to
do
five,
but
it,
but
it
requires
weak
Maps.
It
should
probably
be
opt-in
with
an
option
or
a
flag
or
something
or
if
we
figure
out
a
really
easy
algorithm
to
do
five,
that
it
has
no
trade-offs.
D
B
But
I'd
like
to
also
keep
in
mind
that,
as
Ivan
was
talking
about
earlier,
with
the
the
different
approaches
that
servers
take
to
resolve
in
graphql,
it
may
be
that
certain
types
of
servers
may
never
want
to
implement
five,
because
it
means
that
they
have
to
do
this
Dynamic
tracking,
which
they
may
not
want
to
do
so,
I
think
taking
the
option
where
we
specify
for,
but
we
allow
five
allowing
five
is
just
basically
an
enhancement
on
four
where,
when
you
output
the
field,
you
just
put
a
if
you've
already
delivered
this,
then
you
may
choose
to
not
include
it,
and
it's
literally
just
one
statement
almost
as
part
of
the
algorithm
that
way,
the
client
would
always
need
to
support
both,
which
should
be
good
in
general.
B
It
allows
us
to
do
the
most
efficiency
if
we
absolutely
need
to,
but
I
think
efficiency
for
the
sake
of
efficiency
or
pushing
efficiency
to
its
absolute
maximum
conclusion
is
not
necessarily
the
best
thing
to
do,
and
perhaps
the
computation
that
is
required
to
achieve
five
is
actually
more
expensive
than
just
delivering
the
duplicate
data.
In
some
cases
so
I'm,
my
preference
is
for
but
I
think
allowing
five
is
reasonable,
and
mostly
that
is
saying.
F
F
Ideally,
we
executors
over
once
and
and
with
just
cash
response,
even
if
we
duplicate
so
execution
of
resolver
is
not
the
problem,
but
the
way
size
of
response
is
a
problem.
So
with
currently
current
algorithms
for
query
complexity,
you
see
one
field,
so
Sy
group
said
you
can
you
can
write
a
query
by
hand
which
have
a
lot
of
duplication
with
Pro,
which
provokes
a
lot
of
duplication
in
in
like
in
parallel
here
here
and
but
since
it's
one
field
or
like
series
of
fields,
cost
can
be
like
whoa,
but
duplication
is
high.
F
D
A
Yeah,
it's
probably
okay,
that
that
is
the
case,
though,
because
you
know
query.
Complexity
is
not
something
that
the
specification
is
touching
on,
so
anybody
that
has
their
query,
complexity,
algorithms
or
products
or
Solutions
they're
going
to
have
to
understand
that
as
the
spec
progresses
they're
going
to
have
to
consider
updating
their
implementations.
F
In
some
way
with
which
like
predicts
it,
so
basically
it's
not
not
a
question
like
it's.
A
A
A
Yeah
yeah
David
Glasser
is
the
person
to
bring
in
for
sure,
and
I
can
ping
him
on
that
and
Ivan
definitely
feel
free
to
Ping
him
as
well.
He
has
lots
to
say
on
this
for
sure.
B
Yeah,
okay,
so
I've
been
Yakov
asked
like
for
an
example
of
the
the
like
parent
child
stuff
and
effectively
because
I'm
trying
to
think
about
how
this
would
relate
to
stream
as
well,
which
obviously
makes
things
a
little
more
complicated
and
keep
in
mind
I've
written
this,
whilst
on
the
chat,
so
there's
almost
certainly
some
issues
in
here
but
effectively.
This
is
what
I'm
thinking
from
a
reasonably
complex,
statically
solvable
thing
with
lots
of
nested
defers
and
streams
and
whatnot
going
on
that.
B
You
can
effectively
convert
it
into
the
later
thing
now,
as
we've
discussed
before,
we
won't
actually
be
doing
query
rewriting.
This
is
just
for
us
to
think
about
it
in
terms
of
this,
but
I
think
that
the
the
upper
query
can
be
converted
into
effectively
the
lower
query,
and
it
still
gives
us
those
guarantees
that,
when
a
particular
fragment
comes
through,
I
haven't
actually
bothered
naming
the
fragments
but
I've
put
that
all
Matt's
Dunder
type
name
hacks
in
them,
so
that
you
can
see
what
they
would
have
been
called.
B
If
they'd
have
had
those
things
you
can
see
at
each
point
which
ones
of
those
are
solved.
There's
some
interesting
things
in
this.
For
example,
some
of
the
fragments
actually
get
the
the
fragment
aliases
actually
get
resolved
at
a
later
time
than
all
of
the
data
that
they
care
about
is
present.
B
So,
for
example,
the
the
a
b
e
f
is
available
pretty
early,
but
because
we've
got
the
house
fragment
2
in
there
that
actually
doesn't
get
resolved
until
the
defer,
even
though
the
F
itself
was
actually
previously
resolved,
but
I
think
that's
a
problem
we're
going
to
have
anyway,
so
I'm
not
too
worried
about
that,
but
yeah
this.
This
is
how
I
would
like
to
see
it
effectively.
B
It's
merging
all
of
the
defers
that
happen
at
any
one
particular
path
and
doing
anything
that
we
can
to
statically
ensure
that
every
bit
of
data
that
you
need
before
a
certain
time
is
already
going
to
be
present
should
significantly
reduce
the
amount
of
duplicate
data
that
you
receive,
but
without
going
quite
as
far
as
to
do
100
full
deduplication.
D
Yeah,
so
the
the
caveat
of
four
right
now
is
that
no
one
has
written
an
exact
implementation
of
that
yet
so
there
definitely
could
still
be
some
surprises,
but
this
is
a
very
good
test
case
and
yeah.
Very
much
I
want
to
spend
some
time
with
it
in
the
implementation,
see
what
that
looks
like
and.
A
Who's
writing
the
initial
implementation
work
for
graphql.js.
Is
that
something
you're
going
to
rob,
or
is
that
continuation
of
your
work,
Yakov
or.
F
Yeah
well,
that
would
be
great,
especially
since,
like
now
Jacob's
proposal
is
basically
like
a
option.
Five
in
it,
it's
got
like
a
some
stuff
from
Android
stuff
that
we
already
decide
like
removing
the
labels,
so
it
would
be
great
to
like
remove
labels
and
move
move
towards
option
for
so,
even
if
we
experiments
I
try
to
do
option
five
option
six,
so
maybe
it's
somebody
came
up
with
option.
Seven
we
have
like
a
at
least
Baseline,
so,
like
zpr,
is
shorter.
F
D
A
E
F
Or
we
can
do
like
whatever
would
make
your
wife
easier.
We
can
do
like
the
duplication,
with
initial
response,
for
example,
if
it
would
be
easier
to
implement.
So
it's
like
purely
based
on
implementation,
but
yeah.
If
you
all
agree
that
we
moved
towards
option
four
and
I
like
much
proposal
that
we
agree
on
option.
Four
is
the
best
one
and
we
we
try
option.
Five
is
the
spr
on
top
of
it
or
like
flag
or
like
something.
F
A
Top
so
I
I
don't
know
if
this
is
just
me.
But
it
seems
a
bit
odd,
though,
that
if
you
know
picturing,
not
people
that
are
implementing
other
libraries
similar
to
graphql.js
but
picture
users
of
graphql.js
like
if
I'm
a
user
of
graphql.js
I
just
want
graphqljs
to
do
the
best
thing
it
possibly
can
so.
Hiding
the
full
duplication
behind
a
feature
flag
seems
a
little
odd
for
most
people
who
are
using
the
library
because
they
literally
just
want
to
grab
it
and
have
it
do
the
best
thing
it
can,
which
is
five.
A
So
that
seems
odd,
but
the
feature
flag
is
there
because
graphql.js
is
a
reference
implementation
and
we
want
to
make
sure
that
we're
matching
the
spec,
which
is
option
four,
and
we
want
to
make
sure
that
other
people
that
are
using
graphql.js
as
a
reference
point
can
Implement
along
the
lines
of
four.
So
it.
It
just
seems
odd,
though,
like
there's,
two
different
ways
that
we're
looking
at
graphql.js
here
but
I
think
the
vast
majority
of
people
that
would
want
to
use.
It
would
want
five
without
a
doubt.
I'm.
D
Still
not
sure,
if
that's
the
case,
that
five
is
like
actually
the
best
option,
because
I
think
that
if
we
run
benchmarks,
it
could
be
that
it.
F
Yeah
and
second
point:
we
treated
it's
like
finished
product,
but
they
have
like
some
some
work
to
do.
Even
even
this
pink
aside,
we
need
to
work
on
pendant
and
we
need
to
I
think
like
also
think
about
stream
and
like
done
in
the
Stream
and
some
other
things
so
I
expect
like
we
still
have
a
a
Baseline
and
we
do
of
experimentation.
F
Okay,
so
I
I
would
treat
with
speecher
Park,
not
not
as
like
a
stayed
for
one
years
ahead
of
us,
but,
as
Samad
said,
like
our
attempt
to
do
a
better
have
like
a
good
thing,
but
attempt
to
do
a
better
thing
and
figure
out
like
trade-offs
and
Kevin.
Can
we
make
it
like
into
Sparkle?
Can
we
make
it
golden
standard
option?
Five,
so
I'm,
like
yeah
in
ideal
scenario,
we
moved
towards
option
five
as
a
without
any
fact,
but
as
a
growth
to
that
we
have
like
option
four
and
we
will
experiment
on
option.
B
I
should
also
like
comment
that
graphql
itself
already
has
duplication
issues
and
it
doesn't
care
so,
for
example,
if
you
request
the
you
know
a
list
of
blog
posts
and
then
the
author
of
those
blog
posts,
you
might
get
the
same
author
come
up
in
your
response
like
20
times
right
and
that's
not
an
issue
like
graphql,
doesn't
really
care
about
that.
So
I
think
that
we
shouldn't
really
care
about
that
too
much
as
part
of
this,
like.
Obviously,
we
don't
want
the
exploding
issue
that
I
raised.
B
You
know
originally
that
kind
of
started
this
conversation,
but
that
doesn't
necessarily
mean
that
we
have
to
go
as
far
as
we
possibly
can.
Otherwise
we
should
probably
be
optimizing.
The
actual
whole
graphql
output
anyway,
and
another
thing
is
this-
could
be
seen
like
if
you
want
to
go
further
in
the
deduplication
step,
you
could
see
that
as
a
transport
optimization
rather
than
a
spec
level
data
optimization.
B
So
we
already
have
things
like
graphql
crunch,
for
example,
that
like
take
the
various
keys
and
map
things
through,
and
you
could
do
a
similar
thing
to
like
stream
and
defer
so
I,
don't
think
it's
necessarily
most
valuable.
We
generally,
we
generally
prefer
simplicity,
so
I
personally,
am
still
very
much
in
favor
of
option.
Four
and
I
don't
see
option
five
as
being
Superior,
it's
Superior
only
in
forms
of
the
actual
size
of
the
data,
but
it's
not
simpler
to
understand.
B
If
you
look
at
one
of
those
payloads
in
isolation
like
sometimes
it's
got
three
Fields.
Sometimes
it's
only
got
one,
that's
weird!
Why
is
that
you
know
there's
various
things
about
that
that
make
it
less
good.
The
one
thing
it
is
better
at
is
the
ultimate
size
of
the
data,
and
that
isn't
really
as
important
as
we
might.
You
know.
F
One
thing
I
will
clarify,
though,
because
like
we
have
duplication
like,
for
example,
in
Json,
in
some
some
formats,
you
can
request
data
with
the
reference
like,
for
example,
gzip.
When
it's
fine,
like
repeated
point
it's
just
with
the
reference
or
in
yamu,
you
can
have
like
references
to
two
values,
but
then
Jason
you
have
like
duplication
and
there
is
no
like
way
to
remove
them,
but
at
the
same
time
Json
itself
doesn't
have
duplication
on
on
its
level.
It's
mean
like
it.
It
doesn't
provide
you.
F
It
doesn't
provide
you
mechanisms
to
remove
the
duplication
inside
your
own
data,
but
it
doesn't
duplicate
itself.
I
mean
Json.
You
shouldn't
have
like
the
same
key.
If
you
can
add
twice,
it's
like
incorrect
in
in
the
same
way
in
krakil.
F
Currently
it
doesn't
give
you
instrument
to
reduce,
to
like
reference
values
or
like
other
mechanism,
to
reduce
your
payload,
but
at
the
same
time,
currently
it
doesn't
duplicate
like.
If
you
have
one
field
inside
the
query
you
you
will
have
one
value
in
response
for
for
web
path,
like
obviously
puffing
through
the
race.
You
will
have
as
many
as
item
scenaries,
but
you
will
not
have
like
two
values
for
one
value
inside
the
query.
Even
if
it's
inside
multiple
fragments
inside.
C
F
Yeah
I
agree,
but
it's
based
on
a
structure
so
the
same
way
it's
like
you
can
have
the
same
value
in
Json
at
the
different
key
and
there
is
no
like
waiter
and
said
yeah
most
of
the
problem.
Json
and
graphql
doesn't
solve
it,
but
yeah.
We
don't
have
like
we're.
E
F
It
even
further
like
here
we're
not
only
not
providing
a
way
to
deduplicate.
We
start
duplicating,
even
if,
if
you're
not
changing
the
path,
basically,
which
in
which
is
a
new
thing,.
A
Yeah
yeah
and
I
I
think
at
some
point.
We,
you
know
users
developers
who
are
building
their
applications
and
using
graphql.
They
do
have
to
take
some
responsibility
for
the
choices
and
understanding
what
they're
sending
into
their
their
servers.
So
when
it
comes
to
deduplicating
I
think
option
four
is
great,
but
I
don't
think
we
should
ever
try
to
take
away
the
responsibility
completely
from
the
developers
that
are
building
things.
A
So
I
we're
almost
out
of
time
but
I
don't
know.
I
saw
your
comment.
Yakov
saying
you
think
you
could
modify
your
a
PR
into
option
four,
so
I
guess
the
one
thing
we
should
just
all
align
on
before
we
got.
The
call
is
who's
doing
that
work
because
it
sounds
like
it
could
be
you
rob
or
you
Yakov
or
even
you
Ivan
who's,
tackling
that
one.
D
Yeah
I
can
coordinate
with
Yakov
and
and
we
can
figure
it
out
awesome.
So,
okay,
so
sounds
like
we're
on
board
with
option
four.
There
could
be
some
surprises
when
we
implement
it,
which,
if
so,
we'll
we'll
regroup.
D
E
A
See
where
we
are
next
week
on
that
Matt
did
you
want
to
invite
I
I,
don't
know
how
to
say
her
name
properly.
Sorry
wait.
Yeah.
A
At
these
calls
happy
daughter
to
the
invite,
if
so,
yeah.
B
Don't
want
to
open
a
discussion
into
this
now
because
we're
right
at
the
end
of
the
meeting,
but
I
do
want
to
flag
it,
which
is
we've
talked
about
removing
the
labels,
which
is
great,
but
we
will
definitely
want
to
have
a
way
of
saying
that
these
two
things
at
the
same
path
should
be
executed
independently.
We've
talked
about
using
named
fragments
as
a
way
of
doing
that,
but
I
think.
If
we're
going
to
rely
on
that,
then
we
need
to
potentially
put
the
pressure
on
getting
that
into
the
spec
higher.
B
A
B
Then
we
should
be
okay
because
then,
as
especially
if
the
client
doesn't
need
to
understand
where
the
deferrs
were
so
one
of
the
things
you
might
see
in
my
solution
is
that
the
paths
don't-
oh-
maybe
that's
not
true,
but
anyway,
the
the
IDS
proposals
that
I
raised
you
know
six
weeks
ago
and
whenever
it
was
basically
told
you
the
server's
doing
stuff,
it's
not
necessarily
stuff
that
you've,
specifically,
you
know
which
things
it
is
of
what
you
requested,
that
it's
doing
it's
just
saying
there
are
open
promises
or
open
whatevers
and
so
long
as
there's
something
like
that
that
the
client
can
see
the
stuff
in
progress,
then
I
think
will
be
okay.
D
Yeah
so
like
once
once
we're
pretty
set
on
the
deduplication,
then
the
next
thing
that
I
want
to
discuss
is
it's
discussion,
66
and
that's
where
we
can
Workshop
the
specific,
like
I'm
assuming
we're
gonna
have
some
kind
of
pending
indicator
and
we
can
Workshop
exactly
what
that
looks
like
that'll,
be
that's
the
next
thing
on
the
on
my
agenda
for
this
meeting.
A
Perfect
yeah
that
sounds
great.
Okay,
anything
else
to
cover
quickly.
Sorry
Yakov,
you
just
messaged
something
the
Implement
is
a
separate
layer,
got
it:
okay,
cool
all.
F
A
Well,
is
that
it
that's
all
seems
like
we're.
Making
progress,
agree.
C
A
Yeah
step
on
in
the
the
battle
winning
the
battle
right,
so
shh
awesome
all
right!
Well,
thanks
all
enjoy
the
rest
of
your
Monday
and
we'll
talk
again
very
soon.
Thank.