►
From YouTube: GraphQL Working Group - May 5, 2022
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
D
A
A
Then
also
when
I'm
like
miles
behind
with
the
chat
with
the
taking
notes,
people
spot
that
maybe
help
out.
F
E
H
D
D
B
K
If
your
name's
not
on
the
agenda,
yet,
please
just
go
ahead
and
send
up
a
request.
I'll
keep
refreshing
that
in
case
I
spot
anymore.
I
K
Yeah,
I
just
merged
the
vons.
I
don't
see
him
here
yet,
but
I
suspect
oh
yeah.
I
do
see
him
there.
You
are
a
lot
of
a
lot
of
squares
on
the
screen
today,
easy
to
lose
track
of
books,
17
folks,
here,
fantastic,
all
right,
everybody,
let's
kick
things
off,
so
welcome
to
the
may
2022
graphql
working
group
as
we
all
join
here.
That
means
we
agree
to
the
membership
agreement,
participation,
contribution,
guidelines
and
code
of
conduct
as
per
usual.
Those
are
all
linked
from
the
agenda
file.
K
In
case
you
ever
want
to
go
read
through
those.
I
wrote
some
of
them.
I
think
they're,
pretty
good.
You
should
take
a
read
sometime
as
we
always
do.
Let's
do
a
quick
names
to
faces.
I
think
almost
everybody
here
is
a
familiar
face,
but
there
may
be
a
couple
folks
who
are
new,
either
way,
always
good
to
get
quick
name
to
face
and
make
sure
we
have
the
right
attendance.
K
We
will
go
in
the
order
that
it
appears
in
the
agenda
file,
which
means,
if
your
name
isn't
there,
we
send
a
pull
request
to
add
it.
My
name
is
at
the
top,
so
I'll
start
hello,
everybody.
My
name
is
lee.
C
B
Hi
I'm
matt
hi,
I'm.
K
I
will
get
those
two
merged.
Thank
you.
Both
awesome
welcome
everybody
great,
showing.
Let's
make
sure
we
have
good
note.
Takers,
benji
you've
got
a
crazy
background,
which
shows
us
all
your
notes.
That's
very
cool
benji,
of
course,
always
our
note-taking
champion,
but
benji
tends
to
participate
in
discussion
as
well.
So
if
we
couldn't
get
a
handful
of
extra
folks
to
volunteer
to
help
take
notes,
that
would
be
fantastic.
K
I
see
some
hands
floating
around
in
the
screen.
Thank
you
for
that.
Those
notes
end
up
being
incredibly
helpful.
K
Let's
take
a
quick
look
through
our
agenda.
Make
sure
we
know
what
we're
doing
we're
gonna
talk
about
the
intersection
type
proposal,
an
update
on
defer
and
stream,
and
some
subtopics
to
dig
into
there
looking
forward
to
that
ccn
status,
update
and
a
rollout
plan,
and
coming
back
to
the
one
up
proposal,
all
right,
fantastic
before
we
do
that.
K
Let's
take
a
look
at
action
items
if,
in
fact
we
have
any
it
does
look
like.
In
fact,
we
have
a
few.
K
We
have
three,
let's
go
through
them
in
reverse
order,
so
we
talk
about
the
most
recent
ones:
first,
unions,
implementing
interfaces.
This
was,
I
think,
last
meeting
next
actions
and
this
one
is
set
up
for
ready
for
review
yak
off
any
extra
color
here.
M
Basically,
we're
gonna
be
reviewing
a
little
bit
of
that.
I
guess
with
the
discussion
intersection
type
because
that's
sort
of
the
continuation.
K
Very
cool:
okay,
thanks
for
making
progress
there
closed,
implementing
the
one-off
input
objects
in
graphql
js,
so
we've
been
floating
for.
A
Quite
some
time
it
has
indeed
the
pull
request
for
that
is
up
thanks
to
eric
kessler.
A
K
That's
awesome,
okay,
fantastic
work,
closing
that
and
the
last
part
is
defining
processes
for
reporting
and
dealing
with
security
vulnerabilities
benji.
You
flagged
this
a
couple
of
months
ago
and
looks
like
you
have
something
up:
oh
we
merged
a
security
policy.
Does
that
mean
that
this
is
just
basically
wrapped
up.
A
A
A
Applications
into
the
right
places,
we
just
add
a
security.md
file
to
that
dot,
github
repository
and
it
then
will
just
effectively
appear
everywhere.
It
won't
actually
be
there
as
a
file
it'll
be
there
as,
however,
github
integrates
the
security
announcement,
but
it
will
at
least
be
present
in
some
form.
K
That
certainly
sounds
like
a
good
thing
to
do.
Hopefully,
that's
a
pretty
easy
follow-up
task
for
us
sounds
like
a
good
action
item
sounds
good.
Let's
take
that
as
an
action
action,
but
this
one
is.
A
Separately,
can
we
add
an
action?
There
was
the
deprecation
of
input,
values
that
I
think
evan
raised
and
I
think
it's
ready
to
be
merged.
It
just
needed
that
final
editorial
review.
So
do
you
mind
if
I
file
an
action
item
for
you
that
lead
to
have
a
look
at
that?
Please
do
yeah.
K
All
right,
I
don't
see
any
other
ones
that
need
our
direct
attention.
Thank
you
benji
for
helping
keep
us
honest
and,
on
top
of
those,
hugely
valuable
we're,
not
quite
shy
of
closing
any
of
our
past
actions.
Oh
no,
that's
not
the
case.
There
is
in
fact
the
one
action
from
last
meeting
which
we
did
that
one
gets
to
be
closed,
very
good,
very
good.
Okay,
I
think
that's
all
in
terms
of
reviewing
our
action
items.
K
K
M
Okay,
can
everyone
see
where
I
am
sorry
my
screen,
I'm.
M
So
this
is
from
the
graphql
working
group
discussions.
We
started
a
new
discussion
discussing
the
intersection
thanks
to
everyone
for
their
feedback.
I
just
wanted
to
go
back
to
the
motivating
case,
and
I
also
want
to
reiterate
that
I
came
to
this
motivation,
not
from
really
personal
experience,
but
just
from
perusing
some
of
the
open
issues.
So
I
don't.
I
can't
really
say
how
urgent
this
is,
if
at
all,
but
here's,
basically
the
motivating
example,
as
I
best
saw
it.
M
Let's
say
we
have
some
generic
interfaces,
we're
using
from
what
I
understand
this
generic
kind
of
relay
interfaces
here,
node
connection
edge
and
let's
say
we
have
a
type
called
a
pet
here.
We
have
it
as
an
interface
okay,
and
then
we
have
two
types
that
implement
that
interface
pet
and
they
also
happen
to
interface
node.
M
I
see
over
here
that
you
could
also
say
that
pet
also
implements
node
and
the
question
is:
how
can
we
construct
an
edge
and
how
can
we
construct
a
type
that
satisfies
that
will
implement
edge
where
edge,
where
edge
has
a
type
that
us
fields
are
that
implements
node?
So
we
have
basically
two
types:
cat
and
dog
which
are
both
house
pets,
and
we
want
to
say
that
these
house
bets
are
our
nodes.
M
So
how
can
we
define
house
pet
node
to
allow
this
so
and
I
put
over
here-
you
know
blank
house,
pet
node
and
the
simplest
example
is
probably
to
make
a
union
maybe
of
house.
Oh,
there
are
a
couple
simple
examples,
but
one
option
going
down
to
our
options
over
here
is
just
used
to
use
regular
unions.
So
if
we
define
a
house
pad
node
as
a
union
of
house
fed
node,
dog
or
cat
since
dog
and
cat
both
implement
node,
we
could
have
the
type
symptoms
simply
deduce
right.
M
That
house
bet
edge.
Note
type
does
implement
edge
because
remember
what
goes
in
here
has
to
implement
node,
but
if
housepad
node
is
only
defined
as
the
type
possible
types
dog
and
cat
well
that
satisfies
that,
and
that
should
be
enough
currently
graphql.js
or
graphql.
The
spec
doesn't
allow
you
to
do
that,
because
there's
no
knowledge,
if
you
would
put
a
union
there's
no
knowledge
that
that
is
defined,
that
to
say
that
that
union
specifically
implements
nodes,
even
though
it
does
in
this
case
it's
not
recognized.
M
So
we
could
change
that,
and
we
could
say
that,
because
housepad
node
only
includes
types
that
implement
a
node,
then
it
does
satisfy
that
interface.
So
the
pro
here
is
that
it's
simple,
relatively
simple:
if
we
can
get
through
the
example,
but
the
con
is
or
the
con
that
was
raised,
you
know
before
I
got
to
this
issue-
is
that
if,
for
some
reason
we
introduce
another
type
of
house
pet
like
that,
for
some
reason
doesn't
implement
node?
Maybe
it
can't
maybe
it
doesn't
have
a
concept
of
an
id.
M
This
would
somewhat
surprisingly
break
house
pet
edge,
meaning
it
wouldn't
simply
be
that
that
type
could
no
longer
be
a
housepad
edge.
Couldn't
represent
the
new
type,
let's
say
a
fish
type
that
for
some
reason
doesn't
implement
node,
but
it
would
actually
break
break
the
type
system,
because
if
we
tried
to
introduce
fish
nothing
you
know
we
would
get
a
validation
error
that
well,
actually
that
we
wouldn't.
We
wouldn't
quite
get
a
validation,
er
error.
Well,
actually
we
would
that
housepad
node
would
I'm
sorry
would
would
no
longer.
M
This
type
would
no
longer
all
the
types
would
no
longer
implement
node,
and
so
therefore
house
at
edge
would
no
longer
implement
edge,
and
so
we
would
get
a
validation
error.
So
the
suggestion
was
made
to
previously
again
before
I
came
to
this
was
to
add
a
constraint,
and
this
was
the
language
of
the
constraint
and
we
could
change
that
keyword,
but
basically
the
keyword
that-
and
this
is
what
we
discussed
at
the
last
meeting-
we
could
add
the
constraints
or
that
pet
that
housepad
node
specifically
implements
here.
M
I
wrote
pet
endnode,
but
you
know
the
key
at
this
point
is
that
it's
implementing
node
and
and
at
that
point
the
pro
is
that
you
cannot
introduce
type
to
housepad
node
that
doesn't
implement
node.
The
con
might
be
that
that
implements
keyboard
is
a
bit
misleading.
We
talked
about
that
last
meeting
that
the
member
types
don't
are
the
ones
that
implement
the
interface
of
node
and
not
really
the
union
itself,
because
it
has
no
fields,
you
know,
and
that
could
bother
you
more
or
less.
M
But,
generally
speaking,
we
could
change
that
keyword.
I
mean
that's
just
a
question
of
syntax,
but
basically
the
idea
is
to
add
some
sort
of
annotation
to
housepad
node,
to
show
explicitly
that
it's
constrained
and
the
the
pro
again
is
that
we're
protecting
against
the
con
from
before
now
you
can
no
longer
introduce
a
a
new
type,
let's
say
again,
fish
that
that
to
to
house
pet
node,
because
you
would
immediately
would
break
you
know
that
that
constraint
that
has
been
added.
M
So
that's
the
the
the
plus
and
we
talked
about
last
week.
We
talked
about
maybe
trying
to
find
examples
from
other
type
systems.
Where
this
you
know,
a
similar
constraint
was
found.
So
you
know
with
my
limited
experti
experience
and
knowledge.
I
basically
came
upon
the
use
of
intersections
based
on
my
again
limited
background,
which
is
itself
limited
within
typescript,
so
we
could
introduce
two
types.
M
Basically,
we
could
introduce
here
over
here
a
regular
union
of
house
pet,
that
are
dogs
and
cats,
and
then
we
could
have
an
intersection
between
those
house,
pets
and
the
nodes
and
so
and
so,
and
the
type
node
and
basically
our
new
type
or
of
house
pet
node,
would
only
be
the
set
of
types
that
satisfy
all
of
these
constraints,
that
are,
that
are
house,
pets,
pets
and
nodes,
and
I
put
over
here
and
pet
just
because
we
have
that
idea
by
by
interfaces
that
we
should
explicitly
list
out
the
parent
interfaces.
M
Anything
that's
a
house
pad
would
also
be
a
pet,
so
you
know
we,
and
in
fact
I
mentioned
above
anything,
that's
a
house
pack
could
also
be
oh,
actually
anything,
that's
a
pet
would
could
also
be
a
node.
I
mean
you
could
divide
it
over
there,
but
but
basically
the
idea
is
that
we
could
use
intersections
instead
of
instead
of
a
separate
keyword
on
the
union
type,
we
could
use
a
separate
type.
M
M
You
could
have
have
a
house
pet,
it
would
go
into
like
a
fish
and
it
would
go
into
that
union,
but
it
wouldn't
end
up
going
to
house
pet
node
and
nothing
breaks,
so
the
con
of
using
intersections
is
basically
the
pro
is
that
we
solved
all
of
our
other
problems,
but
the
con
is
that
we
basically
have
a
new
type
and
all
the
complexity
that
comes
with
it.
M
I
think
I
skipped
over
the
con
for
having
this
additional
constraint
is,
if
you
tried
to
add
fish
to
the
union,
you
couldn't
right
because
there's
that
constraint.
So
if
you
needed
to
add
fish,
you
might
have
to
come
up
with
another
union
that
wasn't
denote
anyway,
so
you
might
in
this
scenario,
you
might
end
up
having
one
union
of
house
pet
nodes
and
one
union
of
house
cuts,
whereas
in
this
scenario
of
intersections
you
have
two
different
types,
but
you
you,
they
clearly
define
why
they
exist
as
two
different
types.
M
You
know
your
house
bet
is
a
union
and
then
it's
clear
that
the
house,
that
node
is
the
intersection
of
those
unions,
so
you
wouldn't
even
have
you
wouldn't
have
to
like
manually,
do
a
housekeeping
to
keep
those
lists
in
sync,
the
housepad
node
would
automatically
be
all
housebets
that
also
implement
node,
and
finally,
we
could
use
a
lot
of
interfaces.
M
I
think,
michael,
I
touched
on
this
last
meeting
that
now
that
we
have
this
whole
issue
was
originally
raised
in
in
before
we
had
interfaces
implementing
interfaces,
but
now
that
we
do
have
that
we
could
enter.
We
could
introduce
an
interface,
that's
the
same
as
node
called
house
cut,
node,
meaning
so
again
now
we're
thinking
of
now
using
a
union
either
with
a
constraint
or
without
a
constraint
and
not
using
an
intersection,
but
going
back
to
using
our
other
abstract
type
interface,
and
that
would
be
a
housefet
node.
M
That
specifically
says
that
interface
node
and
it's
the
exact
same
signature
as
node,
and
then
we
would
just
have
to
make
sure
to
add
the
housepet
node
to
the
list
of
types
that
would
have
been
in
that
union,
so
the
dog
and
the
cat.
So
the
pro
of
this
solution
is
that
it's
extremely
simple,
no
additional
syntax
is
required.
The
con
is
that
we
have
a
lot
of
we.
We
may
end
up
with
a
lot
of
types
that
are
essentially
duplicates
of
themselves,
meaning
a
housebed
node
is
the
same
thing
as
a
node.
M
So
while
it's
true
that
a
dog
implements
in
this
scenario,
node
and
house,
pet
node,
that's
basically
the
same
interface,
and
so
our
type
system
in
this
or
which
is
our
current,
you
know
this
is
currently
allowed,
is
not
so
expressive.
On
the
other
hand,
the
huge
pro
is
that
we
have
added
no
complexity.
M
So
thanks
for
listening
to
that
summary
to
all
of
you
who
have
gotten
through
with
me,
I
think
those
I
think,
michael.
I
asked
for
sort
of
an
rfc
and
a
document,
and
I
think
this
could
be
like
the
additional.
M
E
Now
we
now,
we
have
the
cases
like
okay,
this.
These
are
the
solutions
to
this
problem,
or
these
are
possible
solutions
to
this
problem.
These
are
the
cons
and
the
pros
that
that's
what
we
had
with
input
unions,
and
this
helps
to
reflect
on
the
problem
and
if,
if
this
is
really
something
we
want
to
solve
in
one
of
the
ways.
M
Yeah
yeah,
and
this
could
definitely
be
a
I
could.
You
know,
I
think
it
might
be
a
good
idea,
then,
to
to
shift
it
off
into
an
actual
rfc,
and
if
people
want
to
then
have
a
more
formal
way
of
editing
it
if
they
have
other
ideas
and
other
pros
and
cons,
they
want
to
add.
I
just
you
know,
I'm
basically
done
with
my
presentation.
I
think,
after
going
through
all
of
this
and
thinking
about
all
all
this,
I'm
in
favor
of
the
intersection
type.
M
I
I
think
it
you
know,
solves
the
problem
and
it
also
points
the
way
you
know
having
second
order.
Abstract
types
like
this,
you
know
solves
a
similar
problem
that
we,
you
know,
I
think
it's
linked
somewhere
I'll,
try
to
post
it
in
the
chat
later
of
another
issue,
with
unions
and
subunions,
and
also
again
do
they
could
types.
You
know
really
fulfill
an
interface,
but
our
system
doesn't
represent
that.
I
think
it
would
be
great
to
have
you
know
a
robust
type
system.
M
That's
you
know
very
strong,
so
I'm
in
favor
of
the
intersection
as
the
best
solution
to
this
problem,
but
I
don't
know
that
it's
quote
unquote
worth
it.
Yet
I
mean
again,
these
are
the
pros
and
the
cons,
but
to
actual
put
a
pulse
on
how
necessary
this
is
that
I
can't
do
for
the
group
and
would
have
to
rely
on
others.
L
I
would
like
to
talk
about
if
there's
possibly
another
con
here
with
the
intersection
type
compared
to
the
just
having
unions
implementing
interfaces,
I'm
not
exactly
sure
what
the
intention
is
and
what
the
behavior
should
be
here.
But
you
know,
could
you
scroll
up
a
little
bit?
Please
yeah,
so
we
can
see
the
that
too
yeah.
Thank
you.
So
if
you
added
you,
say
khan,
if
an
additional
type
is
introduced,
the
house
that
does
not
implement
node
this
would
break
housepad
edge
and
what
we
would
get
is
a
validation
failure
right.
L
So
if
you
added
fish
to
the
house
pet-
and
it
was
not
something
that
implemented
node,
then
you
would
get
a
validation
error
right
there,
whereas
with
the
unions
with
additional
with
the
with
the
intersection.
Excuse
me,
if
you
add
fish
to
the
house
pet
union,
nothing
breaks
there,
but
the
house
pet
node
intersection
does
not
include
fish.
L
That
may
not
actually
be
your
intention
and
you
may
have
missed
that.
Oh
I
need
to
not
just
make
add
fish
to
the
house
pet
union.
I
need
to
also
ensure
that
fish
implements
node
and
you'll
fail
silently
there
until
somebody
later
down.
The
line
like
tries
to
you
know,
query
this
and
realizes
that
their
query
is
failing
to
validate
because
fish
isn't
in
the
house,
pet
node
intersection
or
I'm
not
sure
what
the
validation
rules
are
even
going
to
be
like
here.
L
Perhaps
they
go
housepetnode.onfish
and
they
just
never
get
an
object
back,
because
fish
is
not
in
the
house,
but
no
intersection,
but
that's
failing
silently.
So
I
want
to
make
sure
that
we
are
trying
to
we're
understanding
what
the
way
people
are
going
to
use.
This
is
and
what
the
intention
of
it
is
because,
if
you're
you're
going
to
have
that
additional
overhead
of
like
the
graphql,
you
know,
schema,
parser
and
lex
are
having
to
like
figure
out
what
things
are
in
each
intersection.
M
I
think
that's
a
great,
I
think,
that's
a
great
point.
What
I
would
say
is
to
clarify
one
thing:
one
of
the
possibilities.
Basically,
if
you
would
include
on
fish
because
fish
isn't
part
of
the
intersection
you
would
get
in
at
the
query
time,
you
would
get
a
validation
error,
because
it's
not
one
of
the
possible
types
so
that
at
that
point
you
would
get
a
validation
error
and
because
you're
using
because
you're
using
an
intersection,
you
have
to
use
a
fragments.
I
I
mean
we
could.
M
If
the
intersection
included
an
interface,
we
could
add
additional
logic
to
to
let
you
query
on
housepad
node
directly,
but
I
don't
think
that's
a
good
idea.
I
think
the
and
I
I
I
did.
I
did
all
the
way
at
the
top
of
this
discussion-
there's
a
list
of
like
open
issues,
but
I
thought
for
this
at
this
point
it
might
make
and
that
I
guess
could
go
into
an
r.
M
J
M
To
include
fragments
you
might
you,
might
you
know,
get
that
at
query
time.
You
might
not,
if
you
only
query
on
if
you
happen
not
to
need
any
of
the
subtypes
from
fish,
and
you
query
on
the
interface
because,
like
like.
M
Pet,
so
you
have
you,
might
you
might
encounter
that
error
and
failing
silent
silently
at
that
point?
That
is,
that
is
a
potential
foot
gun.
L
So
if
you
have
a
field
of
the
type
house,
pet
node-
and
you
query
that
field
and
you
you're,
you
know
querying
selections
inside
of
that
field.
You
you
cannot
then
query
fields
on
node
like
I
can't
go
house
pet
node
dot
and
then
in
curly
braces
put
id.
I
have
to
go
to
housefet
node
dot,
dot
on
node
id.
E
Well,
I
exactly
had
this
because
the
intention
was
that
you
can
leave
the
fragments
away
for
certain
properties.
That's
what
I
thought.
M
We
did
discuss,
we
did
discuss
that
last
week,
as
I
think
there
was
actually
some
disagreement.
I
think
ivan
was
against
and
I
think
most
people
were
were
for
with
unions
implementing
interfaces
if
they
d
and
did
indeed
implement
the
interfaces.
We
were
okay
with.
At
that
time
we
were
talking
about
a
union
called
cat
or
dog
node.
I
think
we
were
okay
with
aquarium
directly.
I
think
it
intersections
are
are
because
they
don't
have
to
include
any
interfaces
at
all.
E
E
M
Yeah,
you
could
also
have
an
intersection
of
two
unions
without
any
interfaces
that
it's
only
the
the
subset
I
mean,
that's
also
actually
implemented
already
you
get
that
you
know
quote-unquote
for
free,
which
is
either
good
or
bad.
E
I
would
find
that
very
confusing.
I
thought
the
intent
of
the
whole
thing
is
that
you
query
with
that.
You
essentially
can
constrain
your
or
that's
why
I
said
that
you
can
constrain
your
union
so
that
you
know
so
that
the
language
server
knows
that
certain
fields
are
always
there.
I
M
I
First
of
all,
I
completely
agree
100
with
anthony
anthony's
concerns
about
this
that
essentially
it's
it's
confusing
and
it's
regarding
validation
at
startup
time.
Let's
say
validation
of
the
schema
itself.
I
don't
think
that
replacing
it
with
validation
at
runtime.
When
actually
query
fails
it's
a
good
enough
replacement
and
in
general
I
have
we
had
a
long
long
discussion
of
this
intersection
thing
in
on
on
on
the
side,
and
I
still
can
get,
cannot
make
sense
of
it.
I
Just
because,
as
you
say,
you
can
add
fish,
but
it
doesn't
implement
this
node
interface
and
then
it's
okay.
The
validator
will
swallow
it,
but
then
I'm
looking
at
it
a
human
I'm
looking
at
it
and
it
doesn't
make
sense.
It
says
it
includes
fish,
but
actually
fish
is
out
and
to
understand
this.
For
me,
I
have
to
actually
look
at
the
fish.
Oh,
it
doesn't
implement
node.
So
it's
out
so
declaration
says
yeah.
It
can
be
fish,
but
it
cannot
how
confusing.
M
I
mean,
I
think,
that
I
think
that's
that's
that's
fair.
I
mean
we're
it's
definitely
more.
It
definitely
adds
additional
complexity
versus
the
intersection
implementing
interface
to
me.
It
doesn't
seem
to
matter
much
whether
you're
allowed
to
query
for
fields
directly
on
the
union
when
it's
implementing
the
interface
versus
whether
you
have
to
you
know
use
a
fragment
specifically
for
that
interface,
I
mean
it's,
it's
a
few
extra
characters,
but
it
doesn't
seem
to
me
to
make
it
I'm
having.
L
M
Sure
meaning
that
well
when
I
started
with
this,
what
work,
what
what
I'm
talking
about
is
this
example
over
here
we're
trying
to
make
a
type
that
satisfies
an
interface
and
we
weren't
able
to
do
that
previously
to
me,
I
don't
get
too
excited
about
losing
you
know
a
wrapping
fragment.
I
mean
that's
just
a
few
characters
of
text.
You
know
whether
we
have
it
don't
have
it.
You
know
it
doesn't
unlock
any
additional,
behavior
or
features
or,
or
you
know,
validation
within
the
type
system.
M
The
motivating
example
I
have
here
is
just
is
just:
can
we
make
sure,
can
we
allow
this
house
pet
edge
to
truly
implement
edge?
Currently
we
can't
we
can't
do
that.
We
can't
we
can't
have
to.
We
can't
include
the
words
implements
edge
over
here
when
it's
true
that
it
does,
and
that
offends
me
as
a
as
a.
M
So
that's
that's
actually
a
new
feature
now.
Is
it
the
most
necessary
feature
again
that
offended
me
as
someone
running
through
open
issues
on
the
working
group,
not
as
someone
in
daily
practice
here.
So
I
I
don't
want
to
exaggerate
the
importance,
but
certainly
it's
to
me.
It's
not
so
important
to
save
a
few
characters
of
of
that.
Wrapping
frame
that.
L
Makes
sense
so,
from
my
perspective
just
for
context,
I
am
the
ios
developer
at
apollo,
so
I'm
working
on
a
client
library,
that's
consuming
schemas
and
we're
doing
a
lot
of
code
generation
and
one
thing
that
specifically
compiled
applications
that
use
graphql
compiled
clients
have
that
we
don't
see
from
the
web.
Clients
is
that
we
have
to
deal
with
objects,
the
schema
changing
out
from
under
us.
L
We
compile
an
application,
we
generate
code
and
then
we
shift
it
and
then
the
schema
changes
on
the
back
end
and
we
don't
have
that
knowledge,
whereas,
like
a
web
client
is
constantly
just
getting
the
new
schema
changes
right
once
they're
deployed
and
the
biggest
issue
for
me
with
unions
is
that
new
types
are
added
to
unions
that
we
don't
know
about,
and
I
can't
guarantee
anything
about
those
the
value
of
saying,
oh
well,
I
know
that
this
union
implements
this
interface
means
that
I
can
generate
code
for
the
union.
L
That
I
know
is
going
to
be
valid
even
for
new
types
added
to
that
union,
and
I
I'm
not
against
using
union
or
intersection
for
that.
But
that's
that's
a
big
concern
on
the
usability
side.
J
M
Now
returns
a
fish
that
doesn't
implement
node
and
is
therefore
not
part
of
that
intersection.
You'll
get
a
server
time
error
right.
I
mean
that
so
I
mean
you'll
get
a
query
error
I
should
say-
or
I
guess
I'm
reminded
of,
if
you
use
the
fragment
on
fish,
you'll
get
a
validation
error,
but
if
you,
the
server
tries
to
return
a
phish
you'll
also
get
a
server
error,
so
you
will
get
errors
on
both
and
that
that
should
help
you,
because.
P
Compared
to
the
client,
I
think,
is
the
point
like
the
server
has
a
schema.
That
is
much
newer
than
the
client.
So
when
the
client
was
built,
fish
might
have
existed
but
didn't
implement
house
pet
node.
But
later
on,
somebody
on
the
server
is
like
wait.
A
minute
phish
does
implement
house
pet
node.
So.
P
P
P
When
you
see
a
house
pet
node,
you
know
exactly
which
fields
are
allowed
to
you're
allowed
to
query
on
them,
because
they're
part
of
that
interface
inheritance
and
it's
explicit,
whereas
with
the
intersection
much
like
unions
and
one
of
the
reasons
personally,
I
hate
unions
and
discourage
their
use.
Is
that
you
don't
know
how
the
fields
will
change
underneath
you
and
when
you
just
look
at
a
union
it
tells
you
nothing
about
what's
actually
available.
P
M
Well
then,
the
server
can
can
always
add
a
new
type
to
an
interface
as
well.
I
mean
the
only
a
union
is
basically
an
an
interface,
an
empty.
P
Interface,
so
so
it's
not
that
different
right.
The
nice
thing
about
using
an
interface
is
that
right,
the
whole.
If
the
ideal
here
is
that
you
get
fields,
you
get
to
query
for
specific
fields,
because
you
know
every
type
is
going
to
have
those
fields
by
using
an
interface
you're
very
explicit
about
what
those
fields
are.
P
At
this
point
in
time,
you're
saying
yes,
there
might
be
a
future
house
pet
that
will
come
along,
but
it's
guaranteed
to
have
these
fields,
because
it's
directly
on
that
interface,
whereas
you
can
get
into
weird
situations
where
people
make
backwards,
incompatible,
breaking
changes
with
unions
like
they
remove
some
type
from
a
union
or
they
remove
a
field
from
an
interface
and
you've
kind
of
the.
The
one
worry
I
have
with
the
intersection
is
that
we're
disaggregating
field
changes
on
interfaces
and
on
types
that
ripple
through
to
like
potentially
make
other.
P
So
I
can
make
an
existing
intersection
invalid,
like
in
an
existing
usage
of
an
intersection
invalid
by
removing
a
field
on
an
interface
where
that
field
is
never
explicitly
anywhere
in
any
code.
On
my
client,
it's
like
it's
never
used
directly
on
the
interface
it's
only
used
on
the
intersection,
but
by
removing
the
field
from
the
interface
now.
My
client
code
is
invalid
because
of
this
like
it
basically
creates
more
hops
of
types
that
I
have
to
work
through,
to
figure
out
why
my
code
is
no
longer
compiling
yeah,
it
makes
it
even.
E
It
makes
it
even
worse
because
you
you're
combining
unions
and
then
you
in
an
intersection,
maybe
and
then
you're
changing
a
union,
and
you
don't
even
know
that
this
ripple
through
the
intersection
now.
So
there
is
like
it's
much
more
difficult
to
see
how
things
are
affected
and
so.
M
Just
I
would
say
that
in
general,
what
we're
talking
about
is
well.
First
of
all
again,
I
would
agree
there
is
a
a
lot
of
complexity
that
comes
with
intersections
and
those
those
are
definitely
the
downsides,
but
I
think
most
of
the
complexity
is
contained
within
the
idea
of
a
union,
and
most
of
the
complexity
of
unions
is
unfortunately
contained
within
the
domain.
M
I
mean
the
reason
why
they're
not
interfaces
in
their
unions
is
they
don't
share
any
fields,
and
so
you
have
to
you
know,
even
if
you
had
an
empty
interface,
it
wouldn't
be.
You
know,
even
if
it
was
the
keyword,
interface
you'd,
be
stuck
in
the
same
problem,
because
all
the
fields
on
dog
and
cat
there's
nothing
that
are
combined
and
if
it
would
return
a
fish.
You
know
you
wouldn't
know
about
it.
So
there's
there's
not
much.
You
can
do
about
that
about
that
problem.
M
What
intersections
does
is
it
allows
us
to
say
that
those
unions
do
implement
node
without
without
saying
having
to
introduce
a
lot
of
dummy
types
dummy
interfaces
over
here
when
I
say
dummy,
I
don't
I
mean
silly,
but
I
mean
like
duplicate
I
mean
here,
I'm
highlighting
over
here
we're
gonna
have
to
implement
for
every
union.
We
have
we're
going
to
have
to
implement
an
interface
house,
but
node
implements
node
meaning.
This
is
the
only
field
that
it
has
in
common
and
to
me
you
know
all
of
these.
M
They
implement
node
but
they're
all
just
additional
nodes.
It
makes
more
sense
to
think
of
these
as
of
intersections
now.
Having
said
that
again,
this
is
just
a
number
of
characters
and
I
don't
like
it,
but
it
I
think
if,
after
this
discussion,
we
come
down
to
say
that
this
is
still
the
best.
This
is
the
best
solution.
You
know,
I
I
think
that's.
Okay,.
K
We're
we're
getting
close
to
our
time
limit
for
the
topic,
but
I
do
want
to
bring
it
back
first
yakov.
Thank
you
for
assembling
this
doc.
This
is
exactly
what
we
asked
for
the
last
meeting
of.
Can
we
back
up
and
understand
the
problem?
Can
we
look
for
precedent
and
understand
the
space
a
little
bit
better,
so
it
doesn't
feel
like
we're.
Inventing
in
a
vacuum.
K
You've
done
exactly
that,
and
this
feels
super
detailed
and
and
makes
it
much
more
easy
to
compare
and
contrast
possible
solutions.
So
this
has
been
incredibly
valuable.
I
gotta
say
I
agree
with
most
of
the
feedback
here
it
last
last
meeting
when
you
presented
the
union's
implementing
interfaces.
I
thought
that
sounds
so
bizarre.
K
It
was
hard
for
me
to
wrap
my
head
around
it
reframing
it
as
actually
what
this
is
is
a
union
followed
by
an
intersection,
really
clarifies
it,
but
then
hearing
the
pros
and
cons
actually
makes
me
really
like
your
original
proposal,
because
I
agree
with
the
the
original
concern
that
anthony
brought
up
about
one
of
the
the
thing
that
felt
most
strong
about
your
original
proposal
is
that
it's
not
just
a
a
filter
like
I
see
an
intersection
type
like
a
filter.
K
You
take
one
type
and
you
filter
it
by
by
another,
but
it's
truly
a
constraint
in
the
sense
that
if
you
do
something
in
the
schema
that
invalidates
that
constraint,
we
can
statically
make
noise
about
that.
Instead
because
we
know
your
intent
and
that
feels
like
the
most
powerful
part
of
that
proposal.
K
Another
thing,
maybe
just
as
a
re-characterization
of
the
the
other
domain
of
feedback,
that
I'm
hearing
I'll
call
it
like
implicit
versus
explicit
and
that's
an
explicit
trade-off
against
expressivity.
If
you
need
expressivity.
K
So
far,
we've
intentionally
held
a
principle
to
keep
our
type
system
as
explicit
as
possible,
knowing
that
that
will
hold
our
hands
in
terms
of
how
expressive
we'll
be
able
to
to
be
in
the
the
introspection
api
itself,
you
need
to
be
able
to
query
the
possible
types
for
any
any
abstract
type.
So
with
unions,
that's
pretty
obviously
straightforward.
You
they're
all
listed
for
interfaces,
it's
just
a
reverse
lookup.
K
You
just
look
at
all
the
the
things
that
implement
that
interface,
but
one
of
the
things
that
makes
that
easy
to
compute
and
also
therefore
easy
to
reason
about
is
those
possible
types
always
have
to
be
concrete.
K
Like
there's
no
follow-on
effect,
we
have
to
follow
a
chain,
and
this
kind
of
would
be
the
first
case
where
we
would
break
that
where
an
intersection
would
be
an
intersection
of
abstract
types,
where
you
then
have
to
kind
of
follow
a
chain
to
figure
out
the
end
result-
and
you
know
I
agree
with
the
con
that
you
document
here
about
there's
complexities
that
come
with
that
and
is
it?
Is
it
worth
the
value
that
we
get
in
the
expressivity
that
we
get?
K
I
gotta
say
I'm
skeptical,
but
it
does.
It
does
make
me
feel
better
about
your
original
proposal
as
a
as
a
really
kind
of
neat
solution
to
the
problem
that
maintains
our
ability
to
use
union
types.
M
Yeah
I
mean
now
we
have
well,
we
have
intersections
up
with
an
implementation
pr,
but
we
shouldn't
forget.
We
have
from
last
working
group,
we
have
unions
implementing
interfaces
pr.
I
think
that
I
discovered
a
few
more
tests
that
I
could
add
based
on
this
pr,
but
if
that's
the
way
we
go
forward
or
if
we
go
forward
in
no
way
with
the
last
option,
I
guess
that's.
M
You
know
I'm
hearing
pretty
clear
feedback
that
intersections,
despite
being
fun,
aren't
you
know,
come
with
that
additional
complexity,
so
you
know
if
we
can
decide
at
this
meeting
to
to
cross
that
out
and
go
back
to
last
meeting's
idea.
We
could
solve
that
problem
that
way.
So
I
guess
that's
you
know
if
there's
consensus
around
that,
then
maybe
we
can
think
about
you
know.
Do
we
have
to
wait
for
another
month
to
how
to
advance
the
prior
unions
implementing
interfaces?
How
do
we
want
to
move
forward.
L
Yeah
sorry
go
ahead.
I
was
just
going
to
say
that
not
as
an
official
representative
as
a
from
apollo
but
from
everything
I've
talked
about
internally.
We
talked
about
this
idea
of
unions
implementing
interfaces
almost
a
year
ago,
and
I
had
basically
unilateral
support
throughout
the
entire
company
that
this
was
a
great
idea
and
we
should
do
it
and
it
would
unlock
a
lot
of
things
for
us,
so
I'm
very
on
board
like
I,
I
want
to
be
a
big
proponent
that
we
should
implement
something
here.
K
I
I'm
coming
around
to
the
idea
you
know
I
I
want
to
hold
by
the
principle
of
the
best
changes,
no
change
but
acknowledge
that
this
is
a
bit
of
a
gap
in
the
expressivity
of
our
system
and
the
usefulness
of
unions,
though
by
the
way
the
last
suggestion
you
have
here
isn't
crazy.
K
It's
just
it
kind
of
looks
like
what
would
common
graph
kill
patterns
look
like
had
we
not
introduced
union
types
and
the
way
that
you
would
do
that
is
you
would
define
nominal
interfaces
either
with
no
fields
or
if
they
implemented
other
field
interfaces,
then
you
would
just
repeat
those.
M
K
But
if
you're
in
a
code
base
that
does
not
have
a
concept
of
a
union,
so
hack
code
bases,
I
think
actually
they
probably
do
now,
but
php
had
interfaces,
but
they
certainly
did
not
have
unions
and
facebook's
php
code
base
was
littered
with
these
fieldless
interfaces
because
they
were
trying
to
describe
unions
or
unions
of
things
and
the
the
last
thing
you
you
put
there
is
exactly
how
you
would
describe
a
union
that
has
a
constraint
and
when
you
had
only
that
one
tool
to
work
with
and
it
works
like
I,
I
saw
code
bases
where
it
works
exactly
like
that,
but
it's
non-obvious
as
to
what
that
is
you're
like
what
do
you
mean
this
you
this
interface?
K
That
adds
nothing
like
why
and
it's
a
roundabout
way
of
saying
a
union
with
a
constraint.
So
I
like
the
explicitness
of
saying
no,
this
is
a
union
with
a
constraint.
That's
what
it
is
that
that
feels
better.
The
downside,
by
the
way
of
having
fieldless
intersections
as
a
or
sorry
fieldless
interfaces
as
a
way
to
define
unions
is,
if
you
end
up
in
a
schema
that
has
many
unions,
where
you
have
a
handful
of
types
that
coexist
across
many
unions.
K
When
you
go
look
up
that
type
you
tend
to
see,
implements
and
then
like
a
comma
separated
list
of
like
dozens
of
things
like
every
union
that
they
exist
in
which
makes
them
really
difficult
to
wrap
your
head
around
and
figure
out
which
of
those
interfaces
are
producing
value
for
this
type
and
which
of
those
interfaces
are
actually
nominal
interfaces
that
describe
some
union
type.
It's
just
a
confusing
piece,
but
like
yeah,
I
think
some
aspect
of
it
is.
We
also
have
to
kind
of
sleep
in
the
bed
that
we've
made
for
ourselves.
K
We've
introduced
union
types,
people
use
them
quite
a
lot.
It
would
be
bizarre
if
we
said
yeah
we
we
don't
think
people
should
be
using
union
types.
You
should
just
go
ahead
and
use
intersec
interfaces
as
a
workaround.
That's
pretty
strange,
I
will
say
I
meant
what
I
said
about
this
being
a
very
useful
exercise,
because
my
biggest
question
was
this
feels
weird,
and
it
was
difficult
for
me
to
explain
to
myself,
despite
seeing
the
benefits
because
of
its
weirdness,
it
made
me
feel
like
we
were
reinventing
the
wheel.
K
We
are
just
reassembling
the
parts
in
a
form
that
is
not
typically
seen
that
provides
new
value,
that
if
you
were
in
any
other
strong
type
system
language,
what
you
would
do
is
you
would
first
define
your
union,
then
you
would
define
an
intersection
and
that
guarantees
that
all
the
pieces
that
you
would
put
in
the
union
include
that
that
you
know
filtering
function
for
your
your
intersection,
the
node
interface.
In
this
example
typescript.
K
That's
what
you
would
do,
c-sharp,
that's
what
you
would
do,
but
for
us,
what
we
really
want
is
a
schema,
build
time
constraint
that
we
can
validate
and-
and
we
don't
get
that
here-
so
I
think,
like
we
stumbled
on
something
a
way
to
talk
about
this.
That
was
valuable.
Last
time
to
say,
the
really
what's
happening
here
is
a
constraint
and
the
constraint
is
that
all
the
types
must
implement,
node
and,
and
that
is
similar
to
what
you
would
describe
as
as
an
intersection.
K
I
do
think
yeah
I
do
think
implements
is
probably
the
right
keyword
just
because
it
is
the
right
way
like
if
you
were
to
frame
that
out
as
a
whole
sentence.
You,
I
would
say
we
have
a
union
called
housepet
which
has
a
constraint
that
all
of
the
members
of
that
union
must
implement
node,
and
then
you
can
start
to
cut
words
out
until
you
get
to
basically
syntax,
and
so
the
word
implements
does
still
kind
of
make
sense
there.
K
But
I
do
think
people
who
encounter
when
we,
if,
if
we
get
this
to
the
final
phase
and
introduce
this,
I
imagine
quite
a
lot
of
people
have
the
same
kind
of
you
know
moment
that
I
had
and
if
we
can
accompany
this
with
some
clear
documentation
about
why
it's
the
form
that
it
is
and
how
to
think
about
it.
Then
this
exercise
has
been
super
useful
for
that.
M
Okay,
great,
what
is
I
think,
the
last
remaining
step,
then,
is
moving
back
to
last.
The
last
prs
for
the
spec
and
implementation
is:
do
we
want
to
allow
querying
fields
directly
on
a
union
that
implements
an
interface,
and
I
don't
really
have
a
you
know
a
bone
in
that.
K
That
seems
like
pure
value
to
be
juiced
out
of
this.
If
you,
if
you
explicitly
guarantee
the
constraint
that
all
the
members
of
this
union
will
implement
this
interface,
then
that
sure
seems
like
it
should
mean
they
should
be
able
to
query
the
fields
of
those
interface.
So
I
I
think
that's
the
the
work
required
for
the
sort
of
next
phase
of
of
this
is
understanding
the
ramifications
and
making
sure
that
we're
getting
the
appropriate
value
out
of
it
and
that's
going
to
have
a
bunch
of
kind
of
you
know.
K
Edge
case
impacts
on
changes
to
the
introspection
system
and
assumptions
made
around
that
and
yeah.
Michael's
got
a
good
point
in
the
comments
too
about
how
we
think
about
graphql
errors,
and
so
I
think,
there's
just
sort
of
like
an
ecosystem
effect,
both
across
the
spec
and
across
how
we
know
people
are
using
graphql
that
we
ought
to
make
sure
that
we
have
covered
our
bases
on.
M
Okay,
I
think
I
think
this
this
last
intersection
pr
has
exposed
some
additional
place
in
the
code
base,
where
I
have
some
tests
to
add
for
the
last
pr.
So
you
know
I'll
work
on
refining
that
for
the
next
you
know
for
the
next
meeting.
I
guess
is
that
the
next
basically
action
item
that
we
could
put
in
or.
K
L
K
I'm
gonna
switch
up
our
our
agenda
order
a
little
bit
if
that's
okay
with
you
alex
I'll.
Have
you
go
next,
just
because
you've
just
got
a
10
minute
slot
here
and
I
expect
we'll
get
into
the
weeds
with
the
last
two
topics.
N
Yeah
for
sure
I
just
want
to
let
you
all
know
how
things
are
going.
We
have
a
first
client
that
has
client-controlled
nullability
support
the
apollo
ios
client.
Their
alpha-4
is
relying
on
a
canary
release
of
graphql
js.
N
There's
no
servers
that
support
it.
Yet
I
don't
think
so.
It
doesn't
do
anything,
but
it
does
code
generation
so
so
that
that
that
works.
I
wanted
to
get
an
idea
of
like
if
y'all
had
thoughts
on
what
rollout
of
this
should
look
like,
since
it
is
an
experimental
feature
like
how
do
you
communicate
with
people
who
use
graphql?
How
should
we
get
feedback
from
people
who
are
using
it?
Have
we
done
something
like
this?
In
the
past.
E
Yeah,
but
so
the
latest
hot
chocolate
version
for
net
supports
it
already.
So,
oh,
I
can
spin
up
the
server
if
you
want
nice.
Okay,.
N
Sweet
sorry,
yeah,
no
okay,
we
got
it.
We
got
two
nice
yeah
that'd.
G
Be
tight,
alex
we're
we're
also
working
on
it
across
all
the
things
at
apollo
preliminary
stages,
but
we'll
have
a
lot
to
share
with
you
very
soon
cool.
N
Yeah,
so
with
regards
to
getting
feedback
from
people
who
are
using
it
or,
and
the
rollout
part
have
we
have
we
done
anything
like
this
in
the
past?
Is
there
like
a
process
for
this?
It's
like
tried
and
true.
K
We
have,
although
I
don't
know
that
our
past
ones
have
been
super
successful.
I
think
what
we've
tried
before
that's
gotten
a
little
bit
of
value
has
been
once
we
have
it
in
the
you
know
like
it's
experimental,
you
gotta
intentionally
flick
it
on
as
we
open
some
issue
or
I
guess
now
we
have
the
discussions
board.
Maybe
that's
a
better
place
to
do
that.
Basically,
just
the
flag
like
hey
this
is
that
final
phase,
we're
collecting
final
feedback.
Please
use
it,
run
it
in
your
systems
and
provide
feedback.
K
Honestly
most
of
the
people
who
are
going
to
provide
that
kind
of
feedback
are
in
this
room,
but
sometimes
you
you
get
lucky
and
and
more
folks
will
try
it
out
and
report
back
the
stuff
that
they
learned.
K
E
Cool,
I
also
sorry
what
what
about
relay
guys
do
they
have
more
feedback
on
or
do
they
even
have
implemented,
maybe
client,
side,
nullability
or.
E
P
Not
yeah
yeah
jordan's,
the
probably
the
best
person,
but
I
so
just
be
concrete,
really
has
not
done
any
work
with
server
capability
of
client
defined
null
ability,
but
they
have.
P
From
my
understanding,
I
could
be
putting
words
in
jordan's
mouth,
so
not
a
hundred
percent,
but
it
probably
doesn't
make
sense
to
implement
server-side
client-controlled
nullability
until
we
have
some
mechanism
for
fragment
level
keys
or
like
basically
being
able
to
say
this
fragment
like
is
null.
N
That's
my
understanding,
too,
is
that
they're
gonna
strip
out
any
client-side
designators
and
then
sort
of
do
the
processing,
with
whatever
they
get
back
on
the
client.
N
K
In
using
the
syntax,
especially
if
we
because
I
know
there
are
still
a
couple
of
open
discussions
around
the
exact
semantics
of
of
those
things,
and
if
they
can
line
up
with
what
we've
learned
from
people
using
relay,
then
that
has
the
added
benefit
that
the
syntax
for
people
who
use
relay
can
just
directly
use
null
propagation
punctuation
rather
than
more
verbose
directives.
N
Yelp
is
going
to
be
piloting
the
thing
we're
probably
a
couple
quarters
out,
but
I'm
gonna
gonna
be
piloting.
It
do.
We
know
any
other
companies
that
are
intended
to
try
it
out
pretty
early
on
what
what
is
yelp
server
stack
we
yeah
so
most
of
our
stuff
is
in
python.
I
think
we
use
pyramid
and
then
and
then
but
our
graphql
services
node.
H
Okay,
so
on
the
server
side
we
like
we,
you
know
we
have
an
implementation
of
this,
but
it's
you
know
it's
not
quite
compatible
with.
You
know
the
versions
going
into
the
spec,
but
we
could
look
at
you
know
like
you
know
how
it
should
take
to
get
that
compatible,
and
then
I
mean
I
think
our
clients
would
love
to
try
this.
H
We
are
using
apollos
like
paul's,
ios,
client
and
js,
and
so,
if
we
could
get
this
get
it
you
know
get
our
server
into
match,
then
then
we
could
get
some
feedback
from
from
our
ui
developers.
H
P
Like
on
our
in
the
big
question-
and
I
know
it's
been
glossed
over
because
we
can
solve
it
via
validation,
but
is
that
it
introduces
another
aspect
of
basically
fragments
from
various
products
being
having
more
overlapping
complexity,
which
means
I
can
mess
up
somebody
else's
product
by
intro
like
I
can
make
it
impossible
for
some
other
engineer
far
in
another
organization,
even
from
being
able
to
iterate
on
their
own
stuff.
P
By
introducing
this
like
by
introducing
some
client
controlled
nullability,
that's
used
in
a
very
central
query
and
that's
that's
not
that's,
probably
not
a
concern
that
should
block
us
from
moving
forward
in
advancing,
but
it
will
block
like
that
is
really,
I
think,
the
main
block
for
relay
like
pushing
it
and
encouraging
it
on
relay
level
servers.
N
Yeah
for
sure
I
don't,
I
don't
expect
everybody
to
use
this
out
of
the
gate.
It's
it's
very
early
on,
but
I
wanted
to
see
if
anyone
else
was
just
so.
We
can
coordinate
and
gather
feedback
and
whatnot
matt.
Would
that
be
solved
by
your
fragment
modularity.
P
L
You
yeah,
I
know
I
was
the
most
vocal
anti-fragment
modularity
person
on
that
thread
before,
but
I
have
thought
about
it
a
lot
and
I
do
think
that
there
are
use
cases
where
it
makes
sense.
So
I
think
that
we
should-
probably
I
don't
know
if
you
guys
have
been
moving
internally
forward
on
that
one,
but
we
should
probably
bring
that
one
back
to
the
forefront
at
some
point.
N
Otherwise,
we're
looking
to
merge
the
parsing
and
lexing
portion
of
the
implementation
relatively
soon
ivan
got
me
a
review
like
minutes
ago,
and
then
I
think
the
the
primary
blocker
for
execution
is.
We
have
to
land
on
how
errors
work.
So
I'm
going
to
come
to
the
next
working
group
meeting
with
some
discussion
items.
So
we
can
talk
about
that.
K
K
That's
just
asking
for
feedback
on
this,
with
a
bunch
of
pointers
out
to
the
places
to
pay
attention
to
whether
it's
the
alpha
release
or
and
then
like
a
list
of
topics
of
things
that
you
are
still
trying
to
make
final
decisions
on
that
you
explicitly
want
feedback
on
that
way.
There's
like
one
nexus
point
for
people
to
deliver
that
feedback
to.
N
Yeah,
I
wonder
I'm
trying
to
think
of
like
a
good
way
so
that,
like
if
someone
stumbles
upon
this
flag
in
a
blog
post,
I
want
them
to
know
about
the
discussion
thread.
So
I
wonder
if
there's
a
way
that
we
could
say,
like
oh
you're,
running
execution
with
this
thing
open,
you
know
we're
going
to
log
like
a
link
or
something
to
this
discussion
thread.
Come
tell
us
about
your
experience
or
I
don't
know
I'll
think
about
it.
I
Well,
this
suggestion,
because
I
think
this
is
confusing
to
call
it
this
way:
client
controlled
nullability
and
it's
even
seems
like
if
something
like.
I
It
actually
throws
error
or
something
it's
violated.
Then
it's
kind
of
server
error,
while
in
fact
it's
failed
assertion-
and
you
remember
this
at
the
end,
so
that
I
think
it's
it
would
be
less
confusing
and
more
clear.
What
actually
happens
here
is
that,
along
with
a
query
on
certain
fields,
the
client
sends
please
make
assertion
check
that
this
is
not
now
client
controls,
nothing.
L
L
I
Then
this
is
impossible
when
question
mark.
It
means
that
essentially,
as
far
as
understand
that
it's
only
used
it's
on
the
upper
fields
in
the
tree
to
allow
this
thing
to
be
now,
you
cannot
actually
make
knowable
what
is
not
knowable
on
server
right
yeah.
So
it's
an
addition
in
concert
with
this,
with
the
exclamation
mark
right.
K
To
to
generalize-
maybe
it's
just-
we
ought
to
take
a
step
back
and
make
sure
that
we
have
the
appropriate
names
and
ways
to
describe
these
features,
which
alex
to
your
point,
you're,
still
trying
to
figure
out.
The
exact
semantics
of
these,
which
may
have
like
the
name
that
makes
sense
for
one
semantic,
would
would
maybe
be
confusing
for
another.
K
So
I
think
there's
a
little
bit
of
a
a
tight
tie
between
those
two
but,
but
certainly
I
I
agree,
we
ought
to
make
sure
the
name
we
land
on
makes
sense
like
I've
been
thinking
about
the
question
mark
as
an
error
boundary
rather
than
as
something
like
it.
That
just
happens
to
change
null
effects,
but
that's
more
of
a
result
of
how
their
error
handling
behavior
works,
but
the
actual
usefulness
there
is
that
it's
an
air
catching
boundary.
I
I
like
the
idea
of
thinking
about
an
exclamation
point
as
an
assertion.
K
Other
languages
have
similar
sort
of
behavior
and
even
similar
syntax,
and
I
think
they
all
use
different
names.
Swift
uses
unwrap,
which
we
don't
use,
the
idea
of
types
being
wrapped
necessarily
or
we
do,
but
not
in
the
same
way
so
yeah,
maybe
making
sure
we
we
get
that
right.
N
Sure
right
yeah
we
can,
we
can
put
up
a
discussion
thread
yeah
we'll
do
it.
O
O
I
still
know
it's
how
to
name
ic
nodes,
even
though
we
much
only
like
parsing
and
not
simatic
execution
schematics,
it's
like
experimental
feature
on
the
flag,
but
if
later
we
decide
to
remove
it,
it's
breaking
change
for
graphqs
and
it's
also
breaking
changes
for
all
the
implementations
that
will
do
experimental
facts.
O
So
I'm
like
I'm
totally
for
discussion,
naming
upfront
before
we
commit
to
ipi,
since
it
like
saved
us,
a
bunch
of
dancing
with
breaking
changes
so
like
supporting
to
name
of
the
same
field
and
doing
some
other
weird
things.
O
So
I
wanted
to
ask
people
to
review
pr,
but
actually
like
for
naming
separate
thread
makes
sense.
I
think
what
we
really
need
is
like
generic
name
for,
like
entire
syntax
question,
mark
bank
and
square
brackets,
because
when
in
ic
they
like,
we
have
one
union
type
of
three
types
of
nodes.
O
So
it
should
be
generic
name
name
for
like
square
braces
and
name
for
bank
and
name
for
question
mark.
So
like
four
names.
Basically
wait
of
things
so
so
would
be
great
if
we
set
up
a
trade
to
discuss
with
four
and
decided
before
really
much
yeah
and.
K
Like
coming,
I
I
don't
want.
I
don't
want
perfect
to
to
be
the
enemy
of
good,
especially
while
we're
in
the
phase
of
prototyping
experiments
and
iterating
like
because
we
could
spend
an
entire
month
trying
to
get
the
name
right
only
to
like
tweak
the
semantic
based
on
feedback
and
all
of
a
sudden,
the
name's
wrong,
and
that
would
have
been
wasted
effort.
E
I
mean
that
there
are
names,
or
I
mean
especially
for
the
syntax
tree.
I'm
also
have
concerns
with
the
names,
but
there
are
names
out
there
for
similar
tokens
c,
sharp
java
or
whatever,
and
so
we
might
just
need
to
have
a
look
at
their
syntax
trees
so
which.
K
Is
discussion,
maybe
maybe
the
action
there
is
a
separate
discussion
thread
just
to
kind
of
go
through
some
naming
options
and
great
suggestion,
michael
to
look
at
some
precedent.
I
K
N
K
Yeah,
we
don't
want
to
like
be
writing,
big
blog
posts,
and-
and
I
mean
we
can
always
talk
about
work
in
progress.
That's
fine
but
like
once
things
are
cracified.
Of
course
you
want
the
right
names,
but
we'll
get
there
we'll
get
there.
Yep.
I
Let
me
bring
some
philosophical
thing:
there
is
a
saying
if
you
want
to
understand
the
thing
name
it
so
proper
naming
brings
a
lot.
I
mean
of
understanding,
so
it's
kind
of
important,
at
least
for
end
users
for
internal
naming
of
variables.
Yes,
but
we
think
we
have
to
think
about
end
users,
so
proper
name
should
bring
them
immediate
kind
of
50
of
understanding.
O
K
All
right
alex
thank
you
for
the
update,
exciting
to
see
the
progress
we'll
hand
it
over
to
defer
and
stream
next.
M
Yeah
cobb:
do
you
have
the
first
piece
of
this?
I
do
have
the
first
piece,
I
I
think
it
might.
I
don't
know
if
rob
wants
to
go
forward
with
his
first.
That
would
be
fine
with
me.
Sort
of
both
are
a
continuation
from
last
week.
M
M
Basically,
that's
when
a
resolver
is
returning
a
a
list
of
of
items,
the
and
as
well
as
when
our
when
the
overall
async
generator
returned
by
graphql
js
is
returning
payloads
with
possible
multiple
completed
results
at
both
of
those
levels.
We
have
to
decide
whether
we
want
to
be
able
to
return
lists
subsets
of
items.
So
I
could.
M
I
could
share
my
screen
again
of
what
the
discussion
was,
but
I'm
not
sure
how
much
people
remember
from
last
time
or
how
much
we
want
to
go
through
those.
If
anyone
has
some
immediate
feedback,
because
we
didn't
you
know
basically,
I
spoke
last
week,
we
didn't
get.
We
sort
of
ran
out
of
time
right
before
people
possibly
would
weigh
in.
But
I'm
going
to
share
my
screen
from
that
discussion
and
I
can
take
it
from
there
in
terms
of
how
much
more
people
want
me
to
speak.
M
K
M
It's
basically
here,
let's
take
a
look
at
the
suggested
type
signature
of
execute
over
here.
So
what
we
have
right
over
here
in
our
execute
function
is
we're
right
now
we're
turning
a
promise
or
value
of
an
execution
result
or
of
a
async
generator,
and
that's
the
same
as
what's
currently
in
the
implementation,
but
what
goes
inside
this
async
generator.
M
So
what
I
would
be
suggesting
is
that
we
that
we
would
return
an
array
of
execution
results
rather
than
a
single
execution
result,
but
that
same
question
is
on
two
levels:
what
should
the
async
generator
or
async
iterator
that
we
return
mean
the
graphql
and
function
returns
as
well
as
what
the
resolver?
M
You
know
we
now,
with
incremental
delivery,
we're
going
to
now
allow
resolvers
to
return,
async,
iterables
and
not
just
iterables,
and
for
the
same
reason
that
we
might
want
to
return
batches
of
results
if
they're
all
available.
At
the
same
time,
we
might
want
to
let
those
underlying
services
that
are
returning
async
iterables,
that
we
then
com
of
items
that
we
then
complete.
M
We
might
want
to
allow
them
to
return
batches
at
the
same
time.
So
there
would
be
a
difference
this
similar,
it's
really
two
separate
issues,
but
for
me
the
exact
same
motivating
principle.
There
was
the
signature
of
those
async
iterables
and
we're
a
little
more
we're
a
little
more
generic
there.
We
allow
those
to
be
async
iterables,
whether
we
return
an
async
general,
which
is
anything
iterable,
iterate
or
whatever.
But
the
question
is
what
should
be
inside
this:
should
it
be
an
item
or
an
array
of
items?
M
Basically,
and-
and
I
want
us-
I
almost
was
to
think
broadly
because
if
we
can
get
agreement
that
all
of
the
items
should
be
returned
available,
it
doesn't
have
to
be
an
array,
and
similarly
the
resolver
doesn't
have
to
return
an
array
of
items.
It
could
be
an
object
that
contains
an
array.
It's
just
I
mean
if
we
can
all
agree
that
that
has
to
return
all
the
avail
that
we
should
allow
returning
all
the
available
items.
M
At
the
same
time,
we
can
then
sort
of
you
know
drill
down
to
how
we
would
do
that.
Would
it
be
a
simple
array,
or
would
it
be
a
more
nested
object,
but
I
guess
the
first
question
is:
do
we
want
to
not
allow
that
or
do
we
want
to
allow
it,
and
the
question
is
right
now
we
well
yeah
I'll
stop
there.
If
anyone
has
initial.
K
It
does
seem
to
me
that
it
will
be
incredibly
useful
to
ensure
that,
as
batches
of
data
is
available,
that
we
can
deliver
batches
of
data
to
a
client,
especially
since
this
isn't
just
a
matter
of
a
fiddly
how
it's
described
in
the
payload
kind
of
thing
like
there.
K
The
one
just
like
minor
piece
of
feedback
is,
I
wonder,
if
the
suggested
type
signatures
for
execute
and
subscribe
could
be
the
same
like
the.
I
know
subscribed.
You've
you've
tried
to
make
sure
that
you
don't
break
the
existing
the
existing
definition
by
making
sure
that
we
can
do
an
async
generator
of
a
result,
or
it
could
be
an
array
of
results
in
the
case
that
there's
multiple
subscribed
payloads
simultaneously
is,
should
the
same
be
true
for
execute
like
it
should
the
the
sense
that
this
is
like.
K
I
imagine
that
the
vast
majority
of
the
time
these
will
be
arrays
of
size.
One
and
async
execution
result
can
never
be
an
array
type.
So
what
a
potential
I
don't
know
if
it's
a
simplification
or
not
or
just
unifying
between
the
two,
be
it's
either
an
execution
result
or
it's
an
array
of
execution
results.
M
I
mean
I
thought
of
sympathizing.
Basically,
the
other
way
is
that
we
always
have
a
have
an
array,
even
if
it's
an
array
of
size,
one
for
both
execute
and
subscribe.
But
I
do
agree,
it
would
be
nice
if
they
had
the
same
signature.
I
don't
think
it
matters
to
me
so
much,
although
you
know
which
one
it
picks.
M
O
O
It's
surprising
that
I
think
generator
can
return
like
a
value
and
you
return
a
sequence
of
value,
but
you
need
to
wrap
if
you
don't
care
for
simple
cases
and
like
what
people
implement
as
a
first
version
for
them,
it
would
be
more
logical
to
just
implement
a
syn
generator,
but
now
we
force
them
to
wrap
up
an
array,
what's
even
more
every
item,
so
whatever
more
surprising.
If,
if
you
need
to
return
array
as
in
yours
over,
if
you
want
to
return
array,
so
we
need
to
wait.
C
I
was
thinking
it
would
kind
of
be
nice
that
it's
forcing
the
client
developers
to
consider
returning
an
array
if
everything
is
always
wrapped
in
a
right,
because
then
they're
not
there's
they're,
not
getting
into
the
chance
of
the
foot
gun
of
of
thrashing
their
client
re-rendering
on
a
lot
of
payloads.
I
M
Just
scrolling
to
where
the
implementation
that
I
have
up
for
for
this
within,
so
I'm
trying
to
find
it
within
a
graphql
executor.
So
that's
what
all
the
screen
changes
are.
I
I
M
M
The
spec
alludes
part
of
it
to
you
know
how
we
would
handle
async
generators
returning
a
resolve,
a
field
generators-
if
I
remember
that's
how
they're
referred
to,
but
it
sort
of
implies
actually
that
you're
not
returning
a
raise
you're
returning
single
items,
and
so
I
think
we
would
want
to
clarify
that,
but
other
than
that,
it's
sort
of
an
illusion-
it's
not
specifically
in
there,
but
in
terms
of
the
response
of
the
actual
graphql,
you
know
payloads.
M
K
That's
part-
oh
I
was
also
asking
like
is:
is
this
more
about
the
specific
js
type
system
changes
that
you?
You
want
feedback
on
which
totally
okay
to
ask
for
opinion
here,
but
I
also
broadly
agree,
or
is
this
more
about
the
shape
of
the
payloads
that
will
come
from
this,
because
I
know
we
had
a
brief
conversation
before
about
whether
we
wanted
to
allow
a
raise
of
results
and
is
that
at
the
top
layer,
like
there's
direct
impact
on,
if
we
make
changes
to
the
shape
of
that
payload?
K
M
M
C
At
least
at
least
for
the
execution
results
for
maybe
we
should
talk
a
little
bit
about
the
return
from
the
resolver,
because
I
I
feel
like
that.
One
is
more
of
an
implementation
detail.
M
The
the
one
change
over
here
to
the
to
to
what
you
would
return,
I
mean
you're,
basically
you're,
yielding
an
array
instead
of
a
a
resolver
is
allowed
in
its
signature.
I
believe
to
return
anything,
and
so
the
signature
of
the
resolver
type
doesn't
change
in
the
implementation.
But
then
we
do
add
some
validation
that
you
know
in
the
execution
that,
if
you
don't
you
know,
return
an
iterable,
then
you're.
You
know
you're
in
trouble
with
the
big
execution
police,
so
yeah.
M
So
that's
over
here,
that's
over
there
and
yes,
so
I
mean,
I
guess
I
guess
we're
broadly
in
agreement
that
this
is
a
good
idea,
and
we
should
just
make
sure
that
when
we
talk
about
the
payload
format,
we
keep.
That
in
mind
is
that
is
that,
where
we're
at.
K
That's
my
read:
yeah
the
getting
making
sure
the
payload
shape
captures.
Both
the
flexibility
to
represent
simultaneous
events
in
a
batch
is
important.
I
I
do.
I
see
the
immediate
ramifications
on
that
on
ui
quality
and
performance.
K
Well,
also,
the
point
I
was
making
before
about
whether
there
should
be
a
value
or
like
a
result
or
an
array
results
versus
just
an
array
results
is.
We
should
also
make
sure
that
the
common
case
is
easy
to
understand.
K
So
if
the
common
case
is
if,
if
95
percent
of
payloads
are
going
to
be
or
99
payloads
they're
going
to
be
arranged
size
1,
then
you
can
imagine
99
of
graphql
users
will
be
questioning
why
the
heck
that
array
is
there
and
just
the
one
percent
who
has
the
use
case
at
the
batch
is
going
to
be
happy
that
it
exists.
So
there's
just
some
fiddling
there
to
make
sure
that
we
get
both
of
them
right,
but
I
think
broadly
making
sure
that
we
have.
This
capability
seems
quite
worthwhile.
K
Great
rob
you
want
to
take
it
from
here,
yeah
sure.
C
So
the
past
couple
of
meetings
we've
been
talking
about
the
payload
of
for
stream
results.
We
went
through
a
couple
iterations
in
the
last
meeting
we
decided
on
that.
C
There
was
a
little
bit
of
discussion
and
there
is
a
use
case
that
there's
a
scenario
that
came
up
where
it
is
ambiguous
without
the
without
having
the
index
in
the
payload
at
all,
and
that
is
the
case
where
you
have
two
deferred
fragments
somewhere
with
the
same
stream.
Nested
inside
of
that
fragment,
each
defer
is
going
to
start
a
separate
execution,
sort
of
and
you're
going
to
get
the
stream
payloads
that
originate
from
both
defer.
C
C
So
I
guess
I
want
to
hear
thoughts
on
the
other
two
options
where,
where
I'm
leaning
towards
right
now
is
the
new
property
that
we
could
call
at
indices
and
have
that
be
an
array
also
of
one
now,
and
that
gives
us
room
for
expansion
for
supporting
batches.
We
could
have
more
than
one
indexes
in
there.
That
corresponds
each
item
in
the
data
array,
or
we
could
also
support
sparse
responses
where
they're
not
coming
back
in
order.
K
I
do
worry
about
the
trade-off
between
flexibility
and
the
complicated
logic
necessary
to
merge
these
results
back
together.
There's
think
we're
where
we'd
settled
up
to
now
of
it
to
say.
First,
yes,
it
is
useful
to
represent
multiple
elements
of
a
list
coming
down
simultaneously
because
we
know
that
that's
a
pretty
common
feature
of
back
ends
to
stream
in
chunks,
and
so
we
can
also
stream
in
chunks
per
list,
which
I
think
is
a
different
thing
from
streaming
like
multiple
things
happening
within
the
tree,
but
these
are
all
just
kind
of
clean
concatenations.
K
C
Yeah
there
there
could
be
in
the
case
where
you
have
the
the
same
stream
on
if
you,
if
you
have
the
same
deferred,
fragment
the
same
stream
inside
different
deferred,
fragments
their
their
deferred,
isn't
doing
de-duping
of
fields,
which
is
something
that
we
had
talked
about
a
long
time
ago
and
decided
against
it
kind
of
gives
exponential
complexity
when
you
try
to
get
into
it.
C
So
you
would
be
getting
this
this
the
streams,
the
stream
payloads
for
this
field
for
each
defer
and
because
it's
the
same
path
and
they
could
be
yeah.
It's
found.
E
One
I
mean
that's
a
very
constructed
case.
This
I
mean
usually
to
make
it
useful.
You
would
have
arguments
that
then
there
would
need
to
be
a
distinction
right
and
then
there
couldn't
be
sure.
Yeah
like
this,
this
repeatable
stream.
C
E
E
C
Yeah
I'm
open
to
it.
It's
I
still
do
hesitate
that
just
not
having
that
index
in
there
anyway
is
somehow
gonna
bite
us
later.
K
But
this
this
example
is
very
interesting.
This
this
implies
that
there's
essentially
two
simultaneous
streams
of
the
same
list
that
appears
at
the
same
spot
in
the
final
merged
result
right.
E
Yeah
yeah
because
we
don't
have
the
parent
label
essentially
in
this
case,
it's
because
we
don't
get
the
parent,
it's
only
cost,
because
we
are
in
in
the
deferred
section
right
and
that's
why
we
take
it
apart.
If
we
didn't
have
these
two
defers
on
there,
we
would
merge
it
like
the
server
would
use
the
field
budging
rule,
and
then
this
problem
wouldn't
appear,
but
now
that
the
the
result
essentially
is
spliced
or
we
we
are
sliced
in
the
processing
there
and
I
think
it's
very
constructed
because
it's
the
same
it
should
resolve.
K
And
this
isn't
a
case
where,
barring
the
label
argument,
that's
here.
This
isn't
the
case
where
you
could
just
take
a
look
at
these
two
fragments
and
say
these
fragments
clearly
are
duplicatous
like.
If
this
wasn't
deferred,
we
would
not
have
fetched
the
same
field
twice.
We
would
have
done
field
collection
and
fetched
that
field
once
it
just
happened
to
be
visited
via
two
paths
in
the
fragment
right.
E
Yeah
yeah
I
mean
you,
can
you
can
construct
more
complex
cases
here,
right
that
that's
very
that's
very
simplified,
so
th
this
we
could
easily
analyze,
but
as
it
gets
more
complex,
you
might
run
into
the
same.
E
Where
you
couldn't
just
say:
okay,
we
drop.
We
merge
them.
A
So
we
actually
need
to
support
nested,
defer
and
stream.
Would
it
be
sufficient
to
only
allow
one
level
of
this
and
then
just
get
rid
of
the
problem
entirely?
I
am
worried
about
if
we
do
fragment
composition
and
you
have
like
deferral
stream
and
a
fragment,
you
then
can't
compose
it
inside
of
another
deferred,
fragment
or
something
like
that.
But
I.
K
Think
that's
too
costly
for
composition.
It's
inevitable
that
you'll
you'll
want
multiple
layers
like
it
may
be
the
case
that
most
uses
only
have
one
layer
deep,
but
this
defer
with
the
streamed
list
inside
the
deferred
piece
seems
actually
like
something
that's
going
to
fairly
typically
happen.
So
I
you
know
we.
K
E
K
If
I
can
reframe
the
problem
here,
it's
actually
really.
K
What
we
want
to
be
able
to
do
is
describe
any
asynchronous
payload,
that's
going
to
be
merged
as
an
identity
in
action
right,
because,
if
you,
if
two,
if
the
same
list
is
being
streamed
twice
but
all
of
the
merge
operations
are
ident,
then
you're
just
burning
cpu,
but
at
least
the
end
result
is
going
to
be
the
same,
because
the
second
merge
that
side
impedance
will
just
do
nothing,
and
maybe
that's
the
thing
that
we've
missed
here
is
we've
made
the
assumption
that
there
will
be
an
existing
set
of
lists
and
then
you'll
get
data,
and
you
must
concat
it,
but
concat
is
not
identity.
K
If
you
ask
to
concat
the
same
thing
twice,
you'll
end
up
with
two
of
those
things
in
there,
not
one
if
it's
like
set
at
index,
that's
idempotent,
but
it
limits
us
to
only
being
able
to
do.
One
thing,
then,
perhaps
the
the
being
able
to
buy
back
having
a
range
is
actually
like
set
at
index
range
it's
from
this
index
to
that
index.
K
These
are
the
values
which
I
think
is
similar
to
the
at
indices,
but
at
indices
implies
that,
rather
than
that
being
2
3
4,
it
could
be
seven
one
three
and
I
think
that's
where
things
start
getting
a
little
bit
more
hair
brained,
and
if
we
can
hold
the
constraint
that
these
are
always
some
contiguous
range
within
the
list.
That
makes
the
merge
operation
a
lot
easier.
P
P
K
K
And
either
way
seeing
this
is
shaking
my
confidence
that
we'll
be
able
to
make
the
guarantee
that
we'll
never
provide
you
a
set
of
updates
that
will
that
will
put
you
in
a
incorrect
state
so
this,
and
if
the
takeaway
from
that
is
every
one
of
these,
you
know
here's
the
new
data
at
this
path
like
if
each
of
those
operations
are
always
guaranteed
to
be
idempotent,
then,
hopefully,
in
addition
to
that,
we
can
also
say
the
server
should
not
give
you.
K
C
Yeah,
I
would,
I
would
definitely
like
to
know
what
the
what
logic
the
meta
server
is
doing
to
dedupe
those,
because
it's
definitely
not
something
that
the
open
that
the
graphql
js
implementation.
I
have
is
doing
interest.
E
Need
to
know
for
which
fragment
that
would
be
on
coming
the
data.
P
You
kind
of
do
but
for
relay
the
fragment
ends
up
so,
like
the
fragment
knows
what
you
have
fragment
level
subscriptions
to
a
central
store,
so
the
way
defer
and
stream
kind
of
work
for
real
is
we
know
an
update,
happened
to
this
node
in
our
normalized
store
and
that's
what
causes
the
re-render,
rather
than
like
a
specific
payload
came
from
the
server
that
happened
to
be
the
defer
payload,
at
least
as
I
understand
it,
I
could
be
wrong
and
I
can
ask
away
where
the
logic
is
for
this.
K
Here's
a
thought,
especially
if
cause
I
you
can
correct
me
if
I'm
misremembering,
but
my
memory
is
that
we
kind
of
settled
that
option
a
that's
where
you
started
and
that
that's
the
most
reasonable
since
it
has.
It
maintains
this
idea,
there's
kind
of
like
one
way
to
define
paths,
especially
since,
if
you
had
to
walk
through
a
list
to
get
there,
you'd
have
the
index
in
there
anyway.
K
K
What
we're
now
learning
is
like?
No,
it
may
be
that
99
of
the
time
that
would
be
an
equivalent
operation,
but
that
is
not
the
operation.
What
you
do
is
you
say
you
are
setting
the
your
setting
at
a
range
where
the
beginning
of
that
range
is
found
at
the
index
in
the
path,
and
the
length
of
that
range
is
the
length
of
the
data.
So
if
you
have
a
list
of
length
two
and
then
person
films,
two
is
the
thing,
then
that
sure
looks
like
it
can
cat.
K
K
K
Yep,
exactly
yeah
yeah
you're
rob
you're
a
step
ahead
of
me,
you've
already
written
that
down
in
future
expansion
yeah.
So
I
think
that's
just
the
way
that
we
describe
how
the
operation
works
and
then
that's
equivalent
to
what
we've
been
doing
up
until
now.
It's
just
kind
of
future,
safe
or
at
least
resilient
against
the
potential
to
have
that
that
edge
case
it
by
society,
independence.
C
Yeah,
the
the
only
thing
that
it
might
make
trick
air
in
the
future
is
if
we
do
want
to
support
the
out-of-order
payloads
for
sparseless.
C
K
Yeah
we
preserve
that
because,
if
there's
a
difference
between
saying
here's,
a
single
operation
where
I'm
setting
at
this
range
from
here
is
a
batch
of
asynchronous
payloads,
going
back
to
yakov's.
Point
of
you
know
making
sure
that
we
have
the
ability
to
represent
arrays
of
asynchronous
results.
You
can
imagine
having
you
know,
three
events
that
happen
quote
simultaneously.
K
That
then
say
set
at
index
three
set
index,
one
set
index
seven,
and
that
gives
you
the
ability
to
do
out
of
order
payloads
as
sort
of
multiple
events
that
happened
in
in
that
stream,
which
would
be
then
that
that's
still
preserved,
but
that
would
allow
us
to
keep
this
particular
piece
to
say.
K
We
expect
lists
to
come
back
as
continuous
blocks
of
data.
So
anytime
you
see
it
the
data
here,
that's
representing
a
continuous
block
of
a
list
which
could
be
one.
It
could
be
the
whole
list.
It
could
be
a
subset
of
the
list,
but
it's
always
going
to
be
a
contiguous
block.
J
I
have
also
a
question
regarding
the
attribute
has
next,
I
only
mixing
the
concepts
of
the
sequential
and
random
access
to
the
the
data
wouldn't
be
wouldn't
be
more
reliable
to
provide
just
the
size
of
the
array
instead
of
just
giving
the
providing
the
the
boolean
flock
saying
that
there
is
a
next
track
of
data.
C
Yeah,
so
the
the
has
next
refer
is
not
to
the
individual
stream,
but
to
every
payload
being
returned
by
all
the
deferrers
and
streams
in
the
operation
and
that
it
could
not
even
with
a
single
stream
that
could
not
be
known
ahead
of
time,
because
you
could
have
a
your
underlying
data
source
could
be
some
kind
of
async
generator
or
something
that
you,
you
don't
know,
synchronously.
What
the!
How
many
items
are
in
the
list
until
you've
read
them
completely.
J
J
That
there
will
be
always
such
an
order
of
the
chunks
that
the
the
the
only
last
very
last
chunk
would
have
the
the
these
this
flux
set
set
to
false
yeah.
If
it.
C
Yeah
and
in
the
case
where,
where
we
don't
know
at
the
time
of
the
last
one
ascent,
we
have
in
this
fact
that
you
could
send
a
payload
that
just
doesn't
have
data
label
or
path
and
just
says
has
next
true,
and
that
was
one.
K
That
does
I'll
wrap
this
up,
because
I
wanna
have
a
little
bit
of
time
for
benji,
but
it
does
open,
maybe
an
interesting
question,
and
maybe
we
just
decide
we
don't
wanna
tackle
this
is
do
we
want
the
ability
to
signal
that
the
stream
of
a
particular
list
has
completed
well.
The
rest
of
the
query
may
have
other
defers
or
other
lists
that
are
being
streamed,
such
that
you
say
this
particular
chunk
of
data,
for
this
path
is
the
last
one.
C
Yeah
that
that
is
something
that
I
have
a
an
issue
open
for.
We
were
kind
of
leaning
towards
not
solving
it
now,
but
something
that
could
be
added
on
later
in
a
new
property
or
something
like
that.
C
But
if,
if
you
think,
if
we
think
that's
something
that
needs
to
be
in
the
initial,
I
don't
have
an
opinion
on
it.
Just
yeah
occurred
to
me
with
greg's
comment.
Yeah.
C
For
that,
I
guess
just
before
we
move
on,
I
just
want
to
summarize
are:
is
the
general?
Are
we
generally
leaning
towards
sticking
with
with
option
a
but
updating
the
language
that
it's
in
to
basically
say
what
I
have
highlighted
here.
K
Awesome
thanks
for
building
confidence
around
this
yeah
thanks
a
lot
for
everyone's
feedback,
all
right,
benji.
Sorry
to
give
you
less
time
than
you
asked
for,
but
hopefully
we
can
get
through
some
of
what
you
want
to
talk
about
and
cover
the
rest.
Next
time.
A
That's
all
right,
I
wasn't
expecting
to
talk
for
particularly
long,
but
I
thought
that
the
discussion
might
go
along.
I
apologize
my
cat's
just
jumped
up
next
to
me
and
she's
going
to
be
very
noisy,
so
I
apologize
there's
a
lot
of
meowing,
so
the
one-off
proposal-
this
has
been
I've,
been
dragging
my
heels
on
this
for
a
little
while
and
the
main
reason
is,
it's
not
immediately
obvious
whether
this
should
be
part
of
the
output
schema
or
not.
A
There
are
arguments
for
both
directions,
but
anyway,
as
an
update,
as
I
gave
earlier,
the
spec
pr
is
finished
for
adding
this
as
input
and
the
graphql
jspr
is
also
present
for
adding
this
as
input,
so
we
could
theoretically
merge
it,
but
what
I
want
to
know
is:
have
we
satisfied.
A
Ourselves
either
well,
basically,
we
we've
agreed
that
we
should
add
this
as
an
input
first
and
then
maybe
as
an
output
later,
but
what
I
don't
want
to
do
is
come
to
add
it
as
an
output
later
realize
that
we
made
a
mistake
and
that
would
have
affected
input.
I'd
like
to
answer
some
of
the
complex
questions
around
output
before
we
merge
it
for
input.
Basically,
even
if
we
don't
know
all
of
the
answers,
so
it
basically
comes
down
to
this.
Do
we
want
one
of
in
output
types?
A
A
But
what
does
that
mean
then,
for
unions
are
unions
now
semi-deprecated,
and
it
also
is
interesting
when
we
combine
it
with
yakov's
proposal
to
make
unions
more
powerful
as
well.
Do
we
want
those
two
sort
of
competing
forms
of
polymorphism
there?
If
we
don't
want
to
add
it
as
an
output?
Type,
then
is
one
of
on
input
types,
definitely
the
right
solution
and
my
main
concern
there
is
having
two
types
of
polymorphism
on
output
and
then
a
type
of
polymorphism
on
input.
A
That's
completely
different
shape
and
supports
completely
different
things
like
supporting
these
scalars
enums
lists,
as
well
as
input
object
types
that
does
seem
strange.
So
I've
been
struggling
with
this
question
in
my
own
head
for
a
while,
and
I
haven't
got
any
answers
so
yeah.
Does
anyone
have
any
thoughts?
Please.
K
I
gotta
say
it's
pretty
entertaining
watching
essentially
closed.
Captions
of
the
notes
appear
directly
behind
you
as
you
speak.
I
love
this.
I
have
some
thoughts
here.
I
actually,
I
think,
you're
on
the
right
track.
My
suggestion
is
considering
how
much
time
and
energy
we
put
into
this
so
far.
We
ought
to
be
decoupling
away
the
parts
that
are
less
clear
to
make
the
parts
that
are
clear
closer
to
doable.
K
The
original.
The
original
problem
to
solve
here
was
input
unions,
and
I
think
we
ought
to
stay
focused
on
that
goal,
but
I
definitely
agree
with
your
your
concerns.
I
do
think
to
answer
your
question
on.
Would
one
of
output
types
still
be
useful,
despite
creating
multiple
ways
to
represent
unions?
K
My
sense
is
definitely
yes.
It
certainly
buys
us
the
describing
the
differences
between
the
two
and
when
you
would
use
one
versus
the
other,
but
it
doesn't
seem
like
one
clearly
slam
dunk
replaces
the
other
they're
just
it
gives
us
more
flexibility
and
a
better
tool
for
schema
definition.
That,
I
think,
is
good.
K
Then
we
ought
to
proceed
forward
with
the
input
unions,
and
I
I
don't
know
if
that
list
is
known
or
if
that
list
is
all
checked
off.
But
but
that
would
be
my
suggestion.
A
A
There
was
a
number
of
strong
voices
saying
we
should
never
add
this
to
output
types,
and
I'm
saying
if
people
feel
that
then
now
would
be
a
good
time
to
say
it,
because
that
may
affect
whether
or
not
you
know
the
input
types
is
the
right
thing,
and
it
might
be
that
we
have
to
research.
The
whole
thing
make
a
decision
later
and
then
go
ahead
and
merge
them
for
input
but
yeah.
If,
if
anyone
has
any
strong
contradictory
opinions,
now
would
be
a
good
time
to
voice
them.
L
I
mean
I
definitely
agree
with
what
was
said
benji
about
the
concern
that
this
kind
of
overlaps
with
unions
and
one
or
the
other
is
going
to
be
you're,
going
to
have
two
competing
things
that
people
are
using
to
do
the
same
thing.
What
is
the
right
best
practice
when
you
use
one
or
the
other
different
teams
are
going
to
have
different
ideas
on
that,
and
then
things
like
when
we
want
to
make
unions
more
powerful.
L
Do
we
do
that
to
both
these
one
of
you
know,
output
types
as
well
like
do
we
do
different
things
for
each
of
them?
Why
would
you
pick
one
or
the
other
you
get
trade-offs
that
becomes
really
really
dangerous.
L
I
don't
have
a
whole
lot
of
context
on
the
history
of
this
issue,
but
I
know
that
we've
talked
about
doing
some
sort
of
unions
for
input
types.
Just
really
quick
summary.
Can
somebody
tell
me
why
that
this
was
chosen
as
a
better
alternative
to
like
extending
unions
in
a
way
that
made
them
solve
this
problem,
or
is
that
way
too
much
of
a
conversation?
I
have
right
now.
K
For
a
remaining
two
minutes,
I
think
it
is,
but
there
is
documentation
on
this
that
that's
that's
certainly
worth
the
read
I'll.
Look
it
up,
benji
I'll
say
we
ought
to.
We
ought
to
separate
design
from
decision.
So
it's
one
thing
to
say:
hey.
If
we
were
going
to
do
one
of
output
types,
we
feel
fairly
confident
that
this
is
the
appropriate
way
to
design
them.
K
I
think
we
proved
to
ourselves
via
a
lot
of
hard
work,
that
that
was
probably
the
not
the
right
thing
to
do,
that
there
was
too
much
pain,
but
via
all
that,
conversation
still
landed,
that
one
of
was
clearly
the
cleanest
way
to
do
input,
unions,
and
so
I
I
still
feel
bullish
on
one
of
output
types,
it's
providing
value,
but
I
I
I
mean
that,
to
the
degree
that
we
ought
to
continue
exploring
the
design
space,
especially
if
that
helps
us
validate
the
input
type
design
space.
K
So
hopefully
there's
not
like.
I
don't
want
it
to
end
up
in
this
position
where
we
have
to
have
the
full
discussion
about
whether
output
one
of
types
are
or
worth
doing
or
not,
in
order
to
make
any
progress
on
input
union
types
which
is
sort
of
the
entire
reason
why
we
went
down
this
path
in
the
first
place
yeah.
I.
A
Agree
so
if
we're
still
agreed
that,
even
if
we
don't
have
output,
one
of
it's
still
good
to
have
the
input
one
of
even
though
it
doesn't
match
the
output
polymorphism,
then
that's
great,
in
which
case
I
suggest
that
we
move
it
to
rfc
2,
since
it
already
has
a
graphql,
js
implementation,
it
has
a
spec
implementation.
A
K
Sure,
let's,
let's
I'll
actually
I'll,
do
that
now
I
mean
worst
case.
We
decided
that
that
was
wrong
and
we'd
move
it
back.
But
knowing
what
I
know,
I
think
that's
probably
a
safe
change
and
then
from
here
out
we
ought
to
then
validate
that
that
draft
is
is
in
the
form
that
we
want
it
to
be
by
exploring
the
output
space
as
a
way
to
help
build
that
confirmation
and
the
rest.
But
absolutely
I
think
it's
been
and
sitting
in
a
fairly
solid
state
and
warrants
rfc2
done
and
done
fantastic.
K
All
right
with
that
we're
wrapping
up
almost
exactly
on
time.
So
thank
you
all
for
the
healthy
discussion.
We
covered
a
ton
of
ground
we're
working
on
a
lot
of
really
interesting
things.
So
much
appreciate
all
the
hard
work
you've
all
done,
and
the
great
discussion
here
bring
the
same
energy
next
month
and
thank
you
all
so
much
talk
to
you
again
soon
thanks.
Everyone.