►
From YouTube: GraphQL Working Group - April 7, 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).
A
F
Give
it
a
minute
or
two
for
folks
to
show
up
you
have
any
open
agenda.
Requests
looks
like
we
might
have
a
few
last.
A
F
That
was
the
additional
maintainers
one.
F
I
got
our
note
stock
attached
already.
I
see
people
opening
it
and
going
ham,
fantastic,
hello.
F
Hey
folks,
we're
just
giving
it
a
minute
for
everyone
to
show
and
I'm
going
through
our
agenda
prs,
making
sure
we
got
everything
merged.
So
we
have
a
complete
agenda.
F
All
right
feel
free
to
keep
sending
them
as
you've
got
them,
but
I
think
I
got
all
them
all
merged.
F
And
looks
like
participant
group
is
stabilizing
too,
which
is
great
all
right.
Let's
kick
things
off.
F
Welcome
everybody,
happy
april
back
for
another
graphql
working
group
meeting,
of
course,
by
all
joining
here,
we
agree
to
the
spec
membership
agreement,
participation,
guidelines,
contribution,
guide,
code
of
conduct,
links
to
all
of
those
fantastically
written
documents
in
the
agenda
file
as
per
usual
and
then,
as
we
usually
do,
let's
just
do
a
quick
round
of
names
to
faces.
F
K
D
F
Welcome,
I
don't
think
I
see
rob
yet.
K
C
G
Hi,
I'm
robert
also
on
the
relay
team
at
meta.
F
F
All
right,
well,
thanks
everyone
for
being
here,
and
I
see
our
note
stock
is
already
getting
flushed
out
and
a
couple
of
people
have
that
open,
as
always
huge
thanks
to
benji.
For
being
our
always,
the
first
volunteer
to
take
notes,
especially
as
benji
chimes
in
with
discussion
folks,
wouldn't
mind.
You
know,
picking
up
the
reins
and
helping
make
sure
that
we
take
high
quality
notes.
Those
have
proven
to
be
extremely
useful.
F
I
want
to
spend
a
little
bit
talking
about
graphql
conf,
coming
up
pretty
soon
we're
going
to
take
a
look
at
the
graphical
2
design
proposal,
which
I
got
a
little
early
peak
at
very
cool,
a
proposal,
around
unions
and
implementations
of
interfaces,
and
then
we
can
spend
a
significant
amount
of
time
talking
about
deferring
stream
based
on
this
note
sounds
like
we're
we're
reaching
the
finish
line,
which
is
super
exciting
anything,
that's
not
on
this
agenda
that
folks
want
to
talk
about
today.
F
F
Let's
take
a
quick
look
at
action
items.
I
don't
know
that
we
had
that
many
action
items
last
meeting,
so
there
might
not
be
much
here
but
always
good
to
take
a
quick
scan
through
these.
F
Did
we
actually
end
up
having
any
action
items?
Last
time
I
can't
remember,
I
don't
think
I
see
any
filed
doesn't
necessarily.
B
F
Okay,
well,
I
don't
see
anything
tagged
to
be
closed.
Nor
do
I
see
anything
that
has
been
updated.
So
that's,
okay.
You
can
follow
up
with
those
after
the
meeting.
F
All
right,
first
one's
from
me,
if
you
were
not
yet
aware
we're
going
to
be
hosting
a
graphql
conf,
that's
going
to
be
actually
organized
and
hosted
by
the
graphql
foundation,
because
this
is
the
first
time
that
we're
doing
something
like
this.
We
are
piggybacking
on
openjs,
so
the
openjs
foundation
is
running
openjs
conf
and
have
graciously
provided
us
a.
I
think
it's
a
90
person
attendance
room
so
not.
K
F
Space,
obviously,
we
expect
the
vast
majority
of
people
who
are
going
to
tune
in
to
do
so
virtually,
but
especially
for
this
set
of
crew
folks
who
are
proactively
working
on
graphql.
It's
kind
of
the
theme
that
I
want
to
have
for
this
conference
is:
what's
the
machinery
that
makes
the
graphql
engine
tick
and
I
think,
there's
some
interesting
things
to
look
at
that
from
the
foundation
point
of
view
and
a
ton
of
interesting
things
to
look
at
that
from
the
point
of
the
working
group.
F
So
I
wanted
to
make
sure
that
everyone
was
aware
this
was
happening
and
that,
over
the
next
couple
of
weeks
we're
going
to
take
talk,
suggestions-
and
I
think
brian
and
I
have
reached
out
to
a
handful
of
you
guys
with
ideas.
But
I
just
wanted
to
make
sure
that
you
guys
all
knew
that
this
was
a
thing
and
wanted
to
encourage
you
to
submit
talks.
F
The
the
preference
would
be
to
hopefully
be
able
to
meet
in
person.
I
know
that's,
not
gonna
be
viable
for
everyone,
so
we're
definitely
gonna
also
entertain.
Talks
that
are
gonna
be
also
delivered
remotely,
but
I
think
it'll
be
it'll,
be
nice
to
have
sort
of
a
an
intimate
group
available
in
person
around
the
conf.
But
anyway
I
wanted
to
flag
that
up
and
then,
if
anyone
had
any
questions
or
thoughts,
I
could
take
a
minute
to
answer
this.
F
Yes,
so
because
it
is
a
joint
conference,
you
register
for
the
one
of
the
other
conferences
and
then
there's
a
graphql
dedicated
space.
That's
part
of
that
conference,
the
I
got
two
links
in
there
there's
the
actual
graphql
conf
is
linked.
That
opens
a
page
which
should
have
a
little
blurb
about
how
to
register
and
which
would
take
you
through
to
the
I
think
it's
called
open,
js
world
this
one
that
actually
has
like
a
registration
form.
F
So
we
essentially
have
a
room
at
that
conference
and
I
think
some
meta
crew
is
going
to
be
at
that
conference
anyway.
Rachel's
going
to
be
there
so
piggyback
on
that.
But
if
you
have
a
talk
idea,
that's
the
second
link.
F
There's
a
cfd
there
don't
need
to
create
something
huge,
just
a
couple
sentences
about
your
abstract
and
we
asked
a
question
about
whether
or
not
you're
able
to
travel
that
doesn't
necessarily
have
a
bearing
on
on
whether
we
want
to
pull
you
into
the
schedule,
but
good
to
know
who's
going
to
be
able
to
travel
and
who
won't.
N
When
we
register
for
js
con
for
cd
com,
is
there
a
way
to
like
designate
that
we're
we're
planning
to
attend
graphql
conf?
So
we
so
we'll
have
an
idea
of
like
how
many
folks
are
going
to
be.
You
know
trying
to
be
in
the
90
person
room.
F
Any
way
to
indicate
that
I
will
ask
brian,
because
brian
is
also
helping
openjs
put
this
together.
H
Well,
a
little
bit
of
concern,
especially
from
server-side
folks
who
build
servers.
The
conference
is
primarily
about
gs
right
so
to
present
something.
K
A
I
don't
know
if
you
were
at
other
graphical
conferences,
it's
very
graphic
specific,
so
the
implementation
I
mean
at
other
graphic,
like
graphql
conferences
like
in
berlin.
There
are
talks
about
graphical
java
or
also
other
specific
implementations,
but
most
of
them
is
more
on
a
conceptual
level.
H
F
Js
world
there's
another
one:
that's
happening
simultaneously
called
cdcon,
which
is
the
continuous
ci
cd
conference,
which
will
be
a
lot
more
back-end
folks.
F
To
have
this
be
a
front
end
only
graphically.
F
Yeah,
but
to
be
clear,
open
invite
for
anyone
who
wants
to
talk
about
server
side.
I
think
the
graphql
audience
the
folks
who
would
want
to
pay
attention
will
very
much
care
about
that
kind
of
thing.
H
Okay,
maybe
just
let's,
let's
create
discussion
or
some
item
with
the
extra
information
as
it
will
come
up
and
continue
discussion.
There
sounds
great.
C
F
I
think
that
would
be
awesome.
I
will
see
who
all
is
able
to
to
make
it.
If
it's
a
too
small
of
a
subset
will
make
it
an
informal
thing,
so
it'll
be
a
social
get
together
of
the
working
group.
Folks,
if
we
have
a
reasonable
order
of
magnitude,
then
we
can
do
something.
That's
like
a
live
meeting
in
person,
but
either
way
yeah
it'll
be
it'll,
be
good
for
the
folks
who
are
able
to
to
come
to
have
some
face
time
together.
F
F
That
one
got
pulled
if
you
reload,
you
should
see.
K
K
Okay,
good
yeah,
so
I
will
watch
the
time.
Lee
encouraged
me
to
bring
this
to
the
general
working
group,
because
the
new
graphical
design
is
for
sure
a
major
change
and
it's
nice
to
have
many
graphql
experts
actually
have
a
look
at
it
before
we
are
committing
to
it
and
implement
it.
So
I
suggest
that
I
just
give
you
a
brief
overview
five
to
ten
minutes,
and
then
you
I'm
looking
forward
to
your
feedback.
K
K
First
of
all,
on
the
conceptual
level,
we
thought
that
it
would
be
nice
to
just
like.
First
of
all
talk
about
how
can
things
be
extendable?
K
We
have
a
lot
of
issues
in
the
graphical
ripple
where
people
ask
for
certain
extensions.
They
want
to
replace
certain
parts,
do
their
own
docs
view
whatever.
So
the
view,
the
idea
is
for
sure
that
certain
panels
will
be
replaceable
and
you're
able
to
provide
your
own
plugins.
For
example,
I
can
provide
my
own
editor
or
I
can
have
a
plugin
on
the
left
side.
So
this
is
the
rough
schematic
view
of
this,
and
the
idea
is
really
that
when
you
open
graphical,
you
will
only
see
what
you
need
to
see.
K
So
this
would
rather
be
a
view
that
you
see
most
of
the
time
with
the
left
side
being
kind
of
turned
in.
You
don't
need
to
have
that
all
the
time
if
you
just
want
to
write
a
query
but
step
by
step
depending
on
your
needs.
You
can
then
enable
that,
just
by
clicking
here
on
the
docs
icon,
you
can
enable
them
and
then
view
them
a
quite
bold
approach
that
we
have
here.
K
We
we
had
the
simple
observation
that
in
the
operation
builder
that
one
graph
built
a
while
ago,
you
have
a
tree
structure
right,
it's
the
kind
of
your
your
graph,
your
graphical
graph
and
then
also
in
the
docs
you
kind
of
have
a
tree
structure
and
instead
of
visualizing
them
as
separate
things,
we
thought
it
would
be
interesting
to
explore
merging
them,
and
so
that
is
our
proposal
actually
that
the
docs
and
the
operation
builder
are
one
thing
they're
serving
one
purpose.
K
So
that
means
one
thing
as
I
can
open
specific
queries
here,
I
can
also
see
specific
types.
I
will
show
that
in
a
bit
how
how
you
can
navigate
through
that,
but
I
can
also
add
things
to
to
my
query.
K
So
an
example
is
here
now
I
can
like
open
things
up
and
kind
of
traverse
the
the
the
graph
here
and
then
add
what
I
need
when
we're
dealing
with
arguments.
The
idea
is
that
all
require
required
arguments.
We
would
show
them
anyway,
because
they
are
required.
You
need
to
add
them
anyway,
and
then
you
can
show
more
arguments,
the
ones
that
are
optional.
K
If
I
in
starship
now
say,
I
want
to
see
a
person,
for
example,
I
click
on
it
again
and
I
get
into
this
nested
menu
here
I
can
go
back
or
close
the
whole
thing
and
that's
also
the
idea
of
the
search.
So
if
I
want
to
search
for
a
specific
type,
the
idea
of
the
search
is
that
you
can
both
search
for
types,
specific
fields,
but
also
in
the
description
texts
of
of
fields.
K
K
This
is
a
draft
for
a
history
feature,
not
necessarily
something
we
need
to
implement
first,
but
just
to
illustrate
that
this
is
extendable
and
you
could
have
instead
of
the
docs.
You
could
have
the
history
here
and
just
select
different
queries
that
you
want
to
rerun
a
simple
setting
screen.
I
mean
this
is
just
showing
illustrating
that
you
can
have
settings
here.
The
idea
is
to
have
them
actually
in
the
bottom
left.
K
We
have
them
now
and
theme
could
be
one
of
them,
but
we
could
for
sure
add
more
settings
here
in
the
editor.
This
is
the
design
of
the
tooltips.
We
still
need
to
figure
out
with
one
echo.
If
all
of
this
is
even
possible,
it
should
be
possible
because
if
you
actually
look
into
how
the
tooltips
look
like
in
moneco,
they
are
basically
the
same
and
just
for
some
context,
ideas
to
move
this
to
moneco,
because
it's
more
advanced
and
implementation
and
the
actual
like
react.
K
K
K
Dark
mode,
of
course,
has
to
be
part
of
it
highly
requested
feature
exactly
could
just
be
toggled
based
on
the
system,
a
few
more
things
that
I
want
to
show
before
opening
it
up.
We
want
to
enable
it
to
drag
you
on
the
site.
K
It's
still
something
we
will
need
to
try
out
if
we
will
show
the
descriptions
kind
of
cut
off
like
this,
or
we
do
like
a
line
break
for
the
long
descriptions.
Still
something
to
figure
out
got
a
bunch
of
different
reactions
on
that,
and
then
I
wanted
to
show
one
more
thing.
I'm
just
wondering
here.
It
is
actually
so
if
you
look
into
how
vs
code
works-
and
you
also
have
these
icons
on
the
left-
and
you
will
see
that
if
you
click
on
them,
it's
not
changing
the
whole
screen.
K
It's
usually
just
changing,
what's
happening
in
the
sidebar,
and
the
goal
is
really
here
to
keep
that
behavior
consistent.
So
if
you
click
on
an
icon
here
on
the
left
that
it's
either
always
doing
something
in
the
sidebar
or
always
doing
something
with
the
whole
screen
and
to
separate
these
out,
the
idea
is
to
have
a
drop
down
here
where
you
can
say
graphql
editor,
however,
not
sure
where
we
have
it,
but
you
could
also
have
something
like
an
ast
explorer,
so
the
whole
screen
would
probably
be
different.
K
As
soon
as
I
use
a
variable,
this
curve
is
not
valid.
To
be
fair,
it
would
show
up
and
you
can
edit
them.
We.
H
K
Some
more
fancy
ideas
for
variable
inputs
with
like
different
inputs,
but
I
think
some
folks
will
want
to
just
copy
paste
json
here,
so
we
just
kept
it
simple
there.
This
is
actually
a
more
updated
version
of
settings
yep.
I
think
that
that's
it
from
my
site,
just
one
last
note.
Regarding
plugins,
we
can
also
imagine
on
the
result
pane
having,
for
example,
a
network
response,
plugin
or
a
built-in
feature
that
shows
you
the
details
there
yep.
That's
it.
H
M
H
Next
is
the
documentation
on
fields
with
arguments,
so
you
initially
show
just
the
beginning
right
here
and
then
somewhere
you
show
the
slide
when
you
expand
it,
because,
but
quite
quite
limited
space.
H
A
Yeah,
please
I
mean
you
have
the
overlay,
you
have
the
overlay
menu
that
he
showed
like.
If
you
click
on
the
type,
then
you
get
the
full
screen
type
exploration,
which
kind
of
is
nice.
You
have
a
quick
overview
of
the
types,
then
you
can
drill
into
a
type
and
there
there
you
could
make
more
space.
I
mean
it
doesn't
have
to
be
this
densely.
H
I
understand
and
by
the
way,
regarding
extended
version,
just
like
youtube
does.
It
shows
the
beginning
of
the
title,
but
when
you
hover
over,
it
shows
the
hint
with
a
full
text.
That's
quick
without
clicking
anything,
but
you
could
quickly
see
the
full
text.
K
Yeah,
I
think
that
would
also
make
sense,
yeah,
yeah
and-
and
in
this
drill
down
view,
I
think
we
can
also
experiment
with
actually
showing
the
full
description,
in
one
view,
yeah
yeah,
also
as
we're
talking
about
it.
One
detail
here:
yeah
for
the
small
ones
also
here
for
the
enums
that
could
just
be
in
line
here,
as
this
is
kind
of
a
type.
It's
like
an
isolated,
or
in
this
view
at
least
it's
not
clear
from
where
am
I
coming
to
this
type?
K
B
It
looks
some
really
great
tim.
This
looks
amazing,
I
love
the
the
documentation,
embedding
that
looks
brilliant
and
just
generally
the
cleanliness
really
nice,
and
also
the
focus
on
the
the
editor
input,
where
it's
definitely
got
more
visual
priority
roman
mentioned
the
the
variables.
I
also
have
some
concerns
there.
B
In
particular,
I
think
we,
as
an
ecosystem,
are
moving
towards
trying
to
use
static
queries
where
possible,
so
it
feels
like
we
should
be
encouraging
people
to
use
variables,
and
I
think
a
lot
of
people
don't
even
realize
variables
are
much
of
a
thing
when
they
start
with
graphical
and
graphql.
B
So
if
we
can
make
adding
variables
really
easy,
particularly
in
the
explorer
view,
you
showed
the
the
argument
there,
but
I
don't
see
what
happens
when
you
actually
interact
with
that
that
required
argument.
There
would
be
amazing,
I
think,
is
if
you
interact
with
it,
maybe
even
it
inserts
a
variable
placeholder
and
you
can
just
enter
the
value
for
it
rather
than
entering
the
value
in
line,
perhaps
might
be
an
option.
F
Yeah,
if
you
could
hover
over
a
value
in
your
query
and
part
of
the
the
hover
over
card,
is
like
a
little
action.
It's
like
make
this
a
variable,
and
it
just
like
replaces
it
with
a
variable
name
and
then
inserts
a
variable
at
the
top
and
then
makes
that
the
and
then
takes
the
value
and
sticks
it
down
into
the
variables
tab.
You
have
like
a
one
button.
Push
it's
a
quick
fix
in
this
code
should.
K
Yeah,
so
regarding
the
variables,
if
you
look
into
the
one
graph
explorer,
they
even
allow
you
to
edit
the
values
of
the
arguments
in
the
in
the
left
side,
and
we
said
that
the
the
sidebar
gets
a
bit
complex
then
so
we,
the
opinion
here,
is
that
we
would
always
go
for
variables
if
you
select
something
here
and
you
can
just
edit
them
here
and
that's
it
and
we
wouldn't
allow
editing
values
on
the
left
side.
We
could
add
that
later,
but
it
would
make
this
view
quite
complex,
so
yeah.
K
This
ties
perfectly
into
that
idea
to
go
for
variables
by
default.
So
if
I
like
collect
my
query
or
click
it
together
on
the
left
side,
then
we
would,
by
default
that
variable.
F
I
am
curious
to
see
what
that
nested
view
of
the
of
the
documentation
it's
like
kind
of
documentation,
but
also
kind
of
a
almost
like
an
ast
explorer,
but
like
at
a
high
level.
What
that
looks
like
for
sophisticated
queries
this.
This
is
obviously
a
straightforward
example
with
a
simplified
schema.
But
if
you
have
a
big,
complicated
schema
and
a
pretty
modestly
sized
query
like
when
you
have
more
than
four
or
five
levels
of
indentation
and,
like
you
know,
the
leafs
of
your
query,
does
that
get
into
horizontal
scrolling?
F
That
might
feel
weird,
or
does
it
just
kind
of
like
push
a
ton
of
white
space
onto
the
side?
So
I
I
don't
have
a
great
suggestion
there,
but
that
might
be
one
where
we
have
to
be
a
little
more
careful
with.
A
K
That
is
a
good
question.
First
of
all,
I
don't
even
know
we
to
be
fair.
We
haven't
thought
about
it.
I
don't
know
how
fragments
are
solved
in
the
one
graph
explorer.
We
would
need
to
explore
that
because
I
would
assume
they
had
that
solved,
but
it's
a
good
point.
We
should
like,
even
if
it's
not
perfectly
represented
on
the
left,
and
you
have
to
write
the
fragments
yourself.
At
least
the
state
shouldn't
be
completely
inconsistent
right.
L
You
almost
could
have
given
your
explorer
is
like
a
one-to-one
match
with
the
tree.
You
almost
could
have
each
top
level
thing
be
a
and
like
be
hinted
with
an
executable
definition.
So,
instead
of
just
being
query,
it
would
be
like
query
from
get
films.
Then,
if
you
have
a
fragment,
you
would
have
again
at
the
top
level
user
from
fragment
to
user.
L
The
I
one
thing
that
is
hard
to
get
at
the
design
stage
and
I'm
sure,
I'm
absolutely
sure,
knowing
the
people
working
on
this,
that
this
has
been
thought
through
somewhat
or
at
least
in
people's
mind,
is
like
right,
complex,
schemas,
complex
queries,
making
sure
that,
like
you're,
not
blocking
tasks
on
a
peripheral,
so
docs
in
this
case,
being
a
peripheral
plug-in
being
available.
L
K
K
L
You
you
also
could,
by
default,
hide
like
use
a
dot
dot
or
something
just
to
hide
everything,
because,
like
the
stuff
between
title
and
release
date,
there
might
be
500
fields
between
them.
That,
mostly
you
don't
necessarily
care
about
seeing.
But
you
care
about
the
things
that
are
directly
queried
most
like
those
are
the
most
important.
K
K
Like
that
yeah,
that
sounds
awesome
because
then
you're,
basically
writing
your
query
and
then
on
the
on
the
on
the
sidebar.
The
docs
are
showing
up
for
what
you're
writing
kind
of
like
on
demand.
Lazy
right,
I
don't
know
where
our
toggle
is.
We
had
it
next
to
the
search,
but
that
was
the
idea
yeah.
That
could
be
one
option
to
deal
with
these
huge
schemas.
But
again
you
will
also
need
to
be
able
to
look
into
those
types
right.
You
cannot
just
talk
everything
away.
L
I
mean
I,
I
think
another
thing-
that's
really
cool
about
this
or
like
this
design.
That
is
great,
in
my
mind,
is
like
if
somebody
doesn't
like
the
docs
explorer,
as
is,
they
should
be
able
to
create
a
new
one
drop
it
in
and
like
prove
out.
Yes,
this
is
actually
better
by
writing
code
to
make
something
that's
actually
better,
without
necessarily
having
to
worry
about
the
entire
ecosystem,
like
that's,
that's
not
possible
with
graphical
today.
So
that's
that
is
very
exciting
that
we
could
actually,
you
know,
get
competition
for
tools
that
solve
similar
jobs.
K
Yeah
just
to
understand
that
meta,
do
you
even
use
the
like
off-the-shelf
graphical
or
how
much
is
what.
K
L
Think
we
end
up
yes
and
yes,
and
I
think
we
use
it
and
it's
forked
and
we
like
sometimes
pull
it
in.
D
I
can
talk
to
that.
We
we
do
use
it,
we
do
have
a
fork
of
it
and
I
think
we're
also
exploring
like
a
special
version.
That
is
more
specific
to
our
use
case.
But
I'll
connect
up
the
folks
working
on
that
with
this
effort
to
make
sure
that
they're,
seeing
what
you
are
working
on
and
can
can
learn
from
it
great.
K
Yeah,
so
the
idea
is
that
if
I
want
to
replace
this
whole
screen
here,
for
example,
ast
explorer
or
some
folks
have
asked
for
a
full
screen,
docs
view,
then
I
would
do
that.
Basically,
here.
F
That
was
the
idea.
I
thought
that
maybe,
rather
than
having
that
hovering
over
the
the
query
text
editor,
maybe
that's
a
useful
way
to
swap
out
the
left
pane
where
the
default
is
the
query
response,
but
you
could
swap
out
or
sorry
the
right
pane.
You
could
swap
out
the
query
response
with
an
ast
explorer
or
a
documentation,
side-by-side
documentation
view,
because
at
any
point
you
still
want
the
bit
of
query
text
that
you're
operating
over.
But
sometimes
you
want
to
see
the
response
that
you
get.
F
F
If,
if
the
only
major
reason
you
have
it
is
the
side,
so
then
you
can
kind
of
reclaim
the
vertical
space,
but
just
only
claim
it
in
the
you
know
upper
right
most
corner
where
you
have
the
graphical
logo.
Now.
K
Interesting,
that's
a
that's
an
interesting
one.
To
be
honest,
if
the
main
motivation
was
really
that
we
would
have
a
full
screen
use
case,
if
we
don't
really
have
that
use
case,
and
if
we
say
that
for
the
sd
explorer,
the
query
editor
is
anyway
the
same
and
you
wouldn't
would
you
would
only
replace
the
response
parts
then
it's
fine.
I
just
want
to
make
sure
that
we're
flexible
enough
if
people
want
to
have
like
a
full
screen,
docs
view.
For
example,
I
mean
we
can
also
say
that's
not
a
design
goal.
B
Thinking
about
this
a
little
more,
I
think
it's
it
would
be
nice
if,
like
the
various
different
panels,
could
be
made
full
screen
like
I
can
imagine
wanting
to
make
the
docks
full
screen.
I
can
imagine
wanting
to
make
the
response
body
full
screen,
or
even
you
know,
potentially
the
variables
pain.
So
maybe
the
full
screenness
is
a
separate
concern
that
could
apply
to
any
of
the
panels.
B
I
certainly
on
the
right
hand,
side
like
in
postgraphal,
for
example,
we
give
you
the
ability
to
like
see
what
the
sql
query
that
the
that
was
generated
is
or
whatever
they
are
query
plans.
Things
like
that
we'd
like
to
be
able
to
see
those
and
toggling
between
them.
On
the
right
hand,
side
would
be
quite
nice,
so
I
quite
like
lee's
suggestion
there.
H
A
quick
question,
so
we
know
we,
we
have
collapsible
regions
in
response.
Do
we
have
collapsible
regions
like
selection,
subsets
in
the
query
or
fragments?
Because
if
you
are
talking
about
big
documents
that
that
would
be
probably
one
of
the
things
to
help
and
for
example,
if
we
have
500
fields
as
in
in
one
subset
as
much
said,
then
maybe
something
like
the
easy
way
to
make
it.
Collapsible
is
inline,
fragment,
spread
right
so
and
then
yeah.
K
That
is
part
of
moneco.
I
think
that
is
the
big
advantage.
We
actually
don't
have
it
in
here,
but
you
would
have
these
little
carrot
symbols
and
then
you
can
just
collapse
those
parts.
Yes,
that
would
absolutely
be
part
of
it.
H
And
another
thing,
maybe
just
an
action
when
on
the
left
on
this
tree,
if
there
is
some
action
available
for
types
create
fragment
on
type.
H
And
then,
for
example,
clicking
on,
I
don't
know
on
the
field
which
returns
type
also,
something
like
this
create
selection
subset.
So
we
don't
have
type
select
all
that
kind
of
accelerators.
K
H
K
K
H
H
K
Plug-In
no,
but
I
mean
some
people
asked
almost
going
the
way
towards
like
a
how
is
it
called
postman?
You
know
like
that.
You
can
like
have
other
stuff
in
there,
but
for
now
I
don't
think
that's
the
goal
of
graphical.
I
mean
you
reusable
fragments.
Why
not?
Okay
for
for
later,
why
not
yeah.
B
In
terms
of
us
trying
to
throw
some
spanners
in
the
works,
one
thing
to
keep
in
mind
is
that
you
can
repeat
the
same
field
multiple
times
with
aliases,
so
make
sure
that
that's
something
that
you
test
against
in
the
in
the
sidebar.
K
Yeah,
we
will
need
some
kitchen
sink
examples
here
to
to
try
it
out.
Yeah.
F
I'll
repeat,
some
feedback
that
I
gave
tim
when
when
we
did
a
preview
of
this
earlier,
which
is
this
looks
like
a
huge
change
from
the
graphical
of
today,
which
is
very
exciting
and
probably
the
right
way
for
us
all
to
think
about
this
is
this
is
like
a
north
star
vision.
This
is
where
this
will
end
up,
but
rather
than
like,
leaping
directly
to
the
state,
we
should
kind
of
move
graphical
from
where
it
is
today
in
the
direction
of
this.
F
So
you
can
imagine
a
phase
that
just
you
know,
gets
them
the
monaco
pieces
all
the
way
to
where
we
need
them
to
be
then
getting
the
visual
style
in
place,
then
rearranging
some
things
a
bit
into
this
form
and
then
starting
to
add
the
right
plugin
structures,
because
I
imagine
some
of
these
just
individual
pieces
could
be
a
humongous
amount
of
work
like
just
the
stocks
sidebar
piece
we've
already
brought
it
at
the
complexities
and
what
will
make
that
a
challenge?
K
We
have
the
graphical
working
group
next
week
and
I
want
to
then
coordinate
the
work,
so
we
are
able
to
put
someone
on
it
like
two
weeks
full
time
and
there
have
been
many
people
interested
in
helping
out,
and
so
I
yeah
next
week
we
can
just
coordinate
the
work.
I
know
that
ricky
worked
more
on
the
fundamental
stuff
on
react
side
in
the
last
days
as
well,
so
yeah.
All
of
that
is
also
progressing.
K
So
the
graphical
working
group
didn't
really
exist
for
a
while-
and
I
just
started
these
documents
here,
but
you
should
be
able
to
just
go
in
here
and
perfect,
pretty
much
the
same
structure.
F
Yeah
a
little
bit
of
the
sidebar
at
some
point,
we
should
just
kind
of
rethink
how
we
we
think
about
these,
like,
rather
than
being
a
constellation
of
working
groups.
These
are
really
just
kind
of
subcommittees
of
this
working
group.
I
think
it's
the
right
way
to
think
about
it
and,
if
that's
the
case,
then
we
should
have
better
sort
of
link
outs
from
our
our
main
working
group.
F
Saying:
hey,
here's
all
our
subcommittees:
here's
where
to
learn
about
them
and
sign
up
for
their
subcommittee
meetings,
but
thank
you
tim
for
getting
some
organization
in
place
on
those.
That's
super
helpful.
F
Yeah,
no,
no
problem,
I
mean
that's
very
exciting
work
and
I
think
you're
hearing
a
lot
of
enthusiasm
from
this
group
too.
We're
nitpicking
the
design,
but
it's
it's
looking
really
fantastic.
Is
there
a
do?
You
have
a
a
discussion
open
or
like
if
folks
think
about
feedback
later?
Is
there
a
place
where
they
should
put
that.
K
Yeah,
so
there
is
a
github
discussion
yeah.
If
you
just
go
into
the
discussions
tab
of
graphical
graphical
to
design,
I
posted
it
there,
including
the
figma
files
and
even
a
grain
video
where
julian
the
designer
and
I
went
through
the
design
and
explained
all
the
interactions,
how
they
should
look
like
and
yeah
feel
free
to
jump
in
there.
K
And
you
know,
I
believe
that
there
will
still
be
many
edge
cases
that
we
will
need
to
figure
out
and
that's
why
we
will
need
to
tightly
work
with
julian,
who
had
all
these
ideas
and
he's
by
the
way.
The
person
who
designed
graphql
background
so
he's
also
very
excited
to
do
the
new
thing
now.
J
O
Okay,
fantastic,
I'm
gonna
try
to
share
my
screen
if
that's
okay,
just
to
take
through
the
example.
O
M
O
Right,
so
this
is
from
the
pull
request
on
the
on
the
spec,
and
basically,
this
topic
is
allowing
unions
to
declare
that
they
implement
interfaces,
so
unions.
O
For
example,
unions
in
here
possibly
implementing
an
interface,
so
unions
can
only
consist
of
object
types
in
the
current
spec
and
they
don't
necessarily
have
to
share
any
fields
in
common,
but
they
could
share
fields
in
common
and
when
they
do
it,
theoretically,
it's
possible
for
them
to
to
say
that
they
do
and
declare
that
they
implement.
As
in
this
example,
these
interfaces,
and
so
one
of
the
things
I
mean
one
of
the
things
that
this
will
were
pretty
much.
O
The
only
thing
this
would
help
unlock,
I
think,
or
the
main
motivating
case
I
saw
when
I
was
just
browsing
through
some
of
the
graphical
spec
issues
is
the
case
right
below
this.
Let's
say
we
have
a
type
that
wants
to
implement
an
interface
like
a
house
pet
edge,
for
example,
that
wants
to
implement
an
edge
if
the
node
type
is
a
union
type
as
it
is.
You
know
if
we
look
up.
O
These
are
the
relay
types
from
what
I've
been
told
that
I
don't
actually
use
relay,
but
this
was
the
main
motivating
example
that
I
saw
that
mike
posted
when
he
was
extending
interfaces
to
implement
interfaces.
So
here
the
node
type
within
the
edge
interface
is
itself
an
interface.
O
So
in
order
to
scrolling
back
down
in
order
for
a
house
pet
edge
to
implement
edge,
its
node
field
has
to
implement
that
node
interface
and
if
the
node
field
wants
to
be
a
union
or
we
want
it
to
be
a
union
the
only
way
or
or
one
way
at
least
to
allow,
that
is,
for
the
union
to
declare
that
it
implements
that
interface
as
it
does.
In
this
example
now
here,
we
also
have
a
we're
using
a
hierarchy
so
we're
showing
that
it
implements
two
interfaces.
O
Just
like
interfaces
can
implement
interfaces,
a
house
or
object
types
I
should
say-
can
implement
multiple
interfaces
so
to
create
a
union,
and
that's
just
the
example
that
we're
showing
here.
So
that's
the
basic
motivating
case
and
that's
the
basic
spec
change.
That's
the
basic
proposal
in
a
nutshell,
and
I
have
a
pr
on
the
reference
implementation
per
view
and
that's
about
it
from
my
end
for
my
initial
thoughts
and
open
it
up
to
discussion.
A
Yeah,
I'm
very
intrigued
by
this
to
say
it
gives
a
bit
more
flexibility
to
unions.
Also,
you
could
you
could
solve
that
with
interface
implementations,
but
this
is
without
having
the
need
to
have
these
combined
interface
implementations.
I
think,
and
it
gives
more
flexible
flexibility
in
combining
types
still
being
able
to
access
these
first
fields.
A
I
mean
for
the
for
the
use
case
that
you
have
there.
It's
actually
not
in
the
real
aspect
that
you
have
to
have
these
interfaces.
You
could
you
actually
wouldn't
have
them
in
the
current
server
guide.
O
Right,
that's
what
I
that's
what
I
saw,
but
I
saw
that
motivating
mike,
and
maybe
others
is
that
you
could.
You
could
implement
them
as
interfaces
and
then
essentially
it
sets
the
stage
for
like
fun,
even
like
additional
functionality
like
like
even
like
generic
type
says
like
preprocessors,
to
like
sort
of
generate
automatically
all
these
housepad
edges
and
this
edge
and
that
edge
that
all
implement
the
common
interface
and
the
client
would
be
you
know.
So,
there's
a
bunch
of
you
know
possible
future
directions.
O
Maybe
this
could
take
in
in
terms
of
using
an
interface
here.
I
thought
about
that.
Like
do
we
really
need
house
pet
to
be
a
union.
O
We
could
instead
say
that
it
is
a
that
is
just
it's
an
interface
that
implements
you
know
an
interface,
but
what
we
get
when
we
we
say
it's
when
we
say
it's
a
a
union
is
that
now
it's
limited
specifically
to
these
particular
types
and
that
you
know
may
or
may
not
be
what
the
designer
of
the
schema
wants
to
say
that
you
know
here
in
order
to
we
in
order
to
add
something
it
has
to
be
in
order
to
add
something
to
this
possible
edge
or
this
possible
field.
O
It
has
to
be
in
these
pre-specified
types.
So
to
be
honest,
I
came
across
this
as
just
you
know,
when
I
was
looking
at
some
of
the
potential
you
know,
requests
on
the
graphql
spec
website.
It's
not
not
something
that
I
would
I'm
using
at
all,
but
I
thought
it
was
like
a
nice
small.
You
know
sort
of
initial
spec
change
to
get
going.
O
You
know
my
feet
wet
a
little
bit
in
that
direction,
so
it's
not
necessarily
a
must,
but
I
think
it
adds
some
functionality
and
I
guess
the
real
question
is
whether
there's
be
a
downside
to
that.
Again
or
the
one
I
have
the
question,
I
have
yeah.
L
So
there
is
a
it's
I'd
say:
there's
a
surface
area
here
where,
for
instance,
this
we
could
allow
empty
interfaces
which
probably
covers
the
same
use
cases,
but
it's
also
kind
of
weird
to
allow
abstract
types
to
implement
abstract
types,
but
not
like
the.
I
guess.
A
flip
side
of
this
proposal
is
that
now
unions
are
allowed
to
implement
interfaces,
but
interfaces
are
not
allowed
to
be
part
of
unions.
O
L
H
L
L
F
L
H
F
Is
a
terminology
thing
that
makes
it
a
little
confusing
right,
because
really
what
we're
talking
about
here
is
a
constraint
on
the
union.
As
you
say,
this
union
may
only
contain
numbers
which
implement
endnote.
Rather
than
saying
this
union
directly
implements
pet
in
node,
because
unions
don't
have
fields,
they
can't
implement
an
interface,
but
their
members
can.
A
Exactly
it's
like
a
generic
constraint
actually
because
implements
is,
I
think,
the
wrong
word.
It's
more
like
the
union
has
now
a
generic
constraints
that
its
members
in
the
set
have
to
implement
pet
and
node,
and
from
this
we
can
derive
then
in
the
in
the
query
that
it's
safely
to
use
these
fields.
F
Yeah,
I
think
that's
right.
The
the
use
case
is
interesting
and
definitely
somewhat
motivating.
I
think
yeah.
I
agree
with
your
your
framing
that
this
is
more
of
a
a
nice
to
have,
rather
than
a
need
to
have
like
you
could
probably
design
yourself
out
of
this
pickle
if
you
needed
to,
but
it
would
be
annoying
and
like
we've
certainly
encountered
similar
cases
before
we
say
we
value
simplicity
over
the
annoyingness,
and
I
could
see
us
having
that
outcome
here,
because
it
is
a
little
a
little
confusing.
F
I
guess
my
biggest
question
that
might
unlock
the
ability
to
move
forward
is
what's
the
precedent
like
do
we
can
we
find
other
languages
with
similar
shape
type
systems
that
have
a
similar
kind
of
constraint,
and
if
we
can't
then
for
a
similarly
shaped
like
diamond
dependency
problem,
how
do
those
languages
solve
it?.
H
I
think,
comparing
to
languages
which
are
mostly
programming
languages,
it's
not
exactly
the
way
to
go
here,
because
programming
languages
have
their
own
needs.
H
H
As
for
the
valid
or
legal
list
of
fields,
it's
just
the
field
must
be
at
least
on
one
of
the
object
or
one
of
the
types
and
probably
in
some
cases.
I
guess-
and
I
just
don't
see
anything
wrong
with
it.
We
want
to
enforce
that
these
fields
in
this
interface
are
required
to
whoever
object
is
there,
so
I
think
it's.
I
guess
it
might
be
beneficial
in
many
cases.
So
union
establishes
that
there
is
some
certain
fields
that
require
on
all
of
them.
H
F
In
the
past
we
found
quite
a
lot
of
design
guidance
by
looking
at
other
type
systems,
and
I
know
swift,
kotlin
typescript
haskell,
like
they
all,
have
similar
kind
of
constructs
around
union
types
or
either
type
classes
or
interfaces
so
that
there's
a
similar
kind
of
abstract
type.
So
I'm
curious
like
if,
if
others
have
the
same
kind
of
diamond
dependency,
this,
like
house
pet
edge
house
pet,
framing
that
in
graphql's
type
system
we
make
that
not
valid.
F
How
do
other
languages
handle
that
diamond
dependency
that
we
could
learn
from
just
so
you
know
like?
Are
we
doing
it
the
same
way
that
others
are
doing
it?
Are
we
doing
it
in
a
unique
way?
If
we're
doing
it
in
a
unique
way,
that
might
be
fine
if
we
can
kind
of
make
a
case
for
why.
O
Sorry,
let
me
get
that
so
I
think
one
thing
that
another
type
language
might
do
is
and,
as
you
said,
it's
kind
of
a
constraint
I
mean
we
can
really
leave
out
implements
at
node
and
the
we
could
introspect
and
and
know
that
housepad
interfaces,
those
interfaces,
those
interfaces,
so
each
of
the
member
types
of
housepad
implements
those
interfaces
because
it
says
just
a
few
lines
above,
but
the
reason
why
I
put
it
this
way
as
a
constraint,
I'm
trying
to
find
a
link
to
it,
but
it
was
basically
a
suggested.
O
I
think
in
the
previous
here
it
is
518..
It
was
was
suggested
that
that
should
be.
That
should
be
the
case
at
the
bottom
of
this.
I
think
this
is
the
prior
art
on
this
I
should
have
mentioned
to
begin
with.
I
think,
basically,
the
reason
why
I
was
suggested.
I
actually,
I
don't
think
a
matter
is
actually
defined
in
an
issue,
but
you
can
check
in
this.
You
know
issue.
O
518
is
that
it
was
suggested
that
if,
if
we
don't
specifically
declare
that
they
implement
those
interfaces,
then
we
could
be
you
know
somebody
could
rely
on
it.
O
A
new
housepad
for
some
reason
doesn't
implement
patent
node
and
that
could
break
queries
and
so
the
benefit
of
adding
this
as
a
constraint
and
would
would
be
in
that
in
that
would
be
in
that
sense
that
it
tells
the
schema
writers
that
that
this
is
expected,
you
know,
will
be
used
as
it
may.
O
You
know
maybe
relied
on
to
consistently
implement
those
interfaces,
and
if
you
want,
for
instance,
say
a
union
of
cat
dog
and
bird,
let's
say
bird
doesn't
implement
pet
for
whatever
reason,
then
you
have
to
create.
You
know
your
own
union,
because
this
union
is
going
to
be
used
in
queries
where
that's
relied
on.
A
Because
if
you
wanted
this
constraint,
you
could
also
have
like
a
housepad
interface
that
actually
implements
patent
patent
node
and
then,
if
you
now,
if
cat
and
dock
implement
that
now,
every
new
type
that
comes
along
and
then
implements
also
housepad
would
have
to
abide
by
that
rules.
A
O
It
definitely
proceeded
next
work
on
that
and
here
what
I
think-
and
I
thought
about
whether
you
might
still
need
that-
and
I
think
you
or
someone
else
mentions
like
empty
interfaces
also,
but
here
what
you
get
to
say
is
that
you
get
to
constrain
housepad
to
specific
types,
so
that
someone
using
a
house
pet
edge
knows
that
they're
only
getting
either
cats
or
dogs
you
mean,
and
so
that
can't
you
know
it's
constrained
not
by
the
interfaces
that
they
they
satisfy,
but
by
known
types
I
think
that
might
still
be
a
benefit
of
unions,
although
you
could
have
a
differently
designed
schema
where
you're
not
using
a
union,
and
you
might
be
able
to
get
something
similar.
O
I
think
I
think
this
would
be
sort
of
expand
the
ability
of
unions
to
be
used
as
these
edges,
for
you
know,
for
people
who
are
using
unions
because
they
want
to
constrain
to
a
limited
set
of
types
because
and
because
we
don't
do
that
introspection.
You
know
this.
This
explicit
constraint
would
still
be
useful.
F
It
does
seem
like
one
of
those
things:
it's
like
a
corner,
like
the
vast
majority
of
people,
never
encounter
this
case,
but
those
who
do
may
be
frustrated
and
for
that
reason
it
could
be
worth
doing.
L
I
think
the
question
with
the
yes
we
could
do
this
implicitly
is
the
key
thing
there
is
that
it
makes
schema
changes
much
more
fragile,
whereas
this
lets
us
have
much
stricter
validation
of
what
changes
are
happening
with
the
schema
like
it
would
be
weird
for
a
change
to
like
a
yeah,
a
change
to
pet
like
or
adding
alligator
to
house
pet,
to
break
house
pet
edge,
because
house
pet
no
longer
implements
node.
A
A
Yeah
what
I
also
or
the
value
I
see,
especially
for
this-
that
if
you
would
implement
an
interface
that
implements
interfaces
here,
you
have
this
combination
at
all
times
at
the
times,
whereas
this
is
a
kind
of
this
union
could
be
just
exposed
through
one
field.
So
this
constraint
is
just
valid
on
this
one
field.
It
doesn't
affect
a
lot
of
other
types,
so
so
I
feel
this
would
give
a
lot
of
flexibility.
A
F
Yeah,
that's
kind
of
why
I
asked
about
it
because
I've
not
heard
of
this
kind
of
constraint
on
a
union
before
it
doesn't
necessarily
mean
it's
not
out
there.
But
I'd
be
super
curious
if
you
can
figure
out.
F
Surely
this
this
type
system
problem
exists
right
where
you
have
these
various
constraints
and
they
they
must
solve
them
in
some
way,
and
I
agree
with
all
the
general
sentiment
here
that
it
that
actually
like
explicitly
defining
the
constraint,
is
more
useful
than
implicitly
trying
to
discover
it,
and
that's
also
going
to
be
more
more
stable,
as
schema
changes
happen
over
time.
F
So
yeah,
I'm
super
curious
to
see.
If
there's
anything,
we
can
learn
from
the
the
rest
of
the
type
system.
I'm.
A
A
But
I
also,
I
think
so
it
reminded
me
of
something-
and
I
I
had
this
generic
constraints.
Usually
you
would
have
constraints
on
the
fields
where
you
say:
okay,
this
returns.
How
is
pets
where
or
you
would
have
a
t
constrain
there?
Where
you
said
my
generic
constraint
implements
these
kinds
of
things.
That
is
what
you
find
in
most
languages,
but
here
it's
a
bit
moved
on
to
the
union.
A
C
Have
a
question
about
execution
behavior,
I
review
current
spec
proposal
on
graphqs
and
I
don't
see
execution
changes,
changes
in
executor
so
as
understand
in
coin
queries.
If
you
want
to
use,
for
example
id
you
still
need
to
do
in
one
fragment
or
fragment
versus.
If
you
do,
housepad
is
interface
implementing
interface,
you
automatically.
C
C
I
I
don't
have
strong
opinion
on
this
proposal,
but
if
something
like
that
gets
matched,
I
think
execution
behavior
should
also
be
changed
so
asking
for
a
fields
directly
without
the
knowing
fragments.
If,
if
it's
explicit
restriction
on
the
type,
why
do
I
need
an
one
fragment
as
a
client.
O
I
think
I
think
I
follow,
and
I
think
I
agree
with
you,
meaning
house
pat
is
constrained
to
implement
pet
and
node,
and
so
you
should.
We
should
have
a
test
case
and
and
nx
and
probably
you
know,
you
should
be
able
to
use
house
pet.
As
you
know,
to
select
fields
just
like
you
can
use
pet
a
node.
O
I
think
I
left
that
out
once
I
sort
of
realized
without
quite
realizing
it
that
we're
talking
about
just
a
constraint
over
here
and
so
and
so,
and
so
what
we
want
to
unlock
is
really
just
the
use
of
that
house
bet
in
that
query,
but
yeah
I
think
I
can.
I
think
I
could
add
that
what
that
would
basically
mean
is
that
house
pet,
as
a
union
declaring
head
and
node
implementing
pet
in
node,
becomes
an
empty
interface.
O
That
is
also
at
the
same
time
that
it's
also
a
union.
If
I'm
not
mistaken,.
C
Probably
not
empty,
but
interface
with
like
fields
from
from,
but
not
correct,
no
additional,
no
additional
fields,
because
in
current
version
you
cannot
ask
any
fields
on
union
at
all,
without
in-line,
fragments
or
without
fragments,
without
type
casting
in
a
sense.
O
Yeah,
actually
I
mean
it
might
be
worth
it
to
get,
because
that
then
that
does
confuse,
maybe
the
differences
between
unions
and
interfaces
even
more
so
I'm
not
sure.
While
that
may
be
beneficial,
I
mean
that
that
problem,
or
that
like
annoyance,
is
a
problem
with
unions
in
general.
So
I'm
not
sure
we
would
want
to
make
that
change,
but
I
think
we
would
I'd
like
to
hear
you
know
happy
to
hear.
I
F
Yeah,
we
should
also
do
a
scan
like
this
is
going
to
have
some
cascading
effects
across
introspection,
and
that
means
it
will
probably
have
those
same
cascading
effects
across
graphql
graphql.js.
O
Yeah,
I
think
the
introspection
changes
are
already
in
the
pr
unless
some
additional
ones
I
missed.
But
I
didn't
that
that
change
that
ivan
makes
to,
or
is
pointing
out,
that
you
should
be
able
to,
in
theory,
select
fields
on
house
pet
and
not
just
on
cat
patent
node
that
I
didn't
make
and
I'm
not
sure
whether
we
would
want
it.
But
I
would
tend
to
think
we
would
like
ivan.
But.
F
O
Okay,
if
there's
consensus
for
sure
I
mean
what
I
was
hoping
is-
is
to
unlock
this
field
behavior,
but
then,
if
we
can
make
our
queries
better
using
that
new
type-
oh,
you
know
yeah
yeah.
I
like
it.
O
How
about
I
work
on
that
at
the
time,
and
I
guess
we'll
ponder
it
over
the
next
unless
there
are
additional
comments,
I
guess
I
see
a
couple
of
hands
stephen,
do
you
have
a
comment.
N
Yeah,
I
would
thought
you
know
precedents
and
languages.
I
guess
I
mean
like
algebraic
like
a
a
full
algebraic
type
system,
would
support
this
in
the
sense
that
this
is
combining
the
union
and
intersection
type.
In
the
same,
you
know
the
same
type
and
so
typescript
I
mean,
I
think
you
know
would
allow
this.
Then
in
that
sense,
and
then
it's
one
of
the
most
fully
featured
algebraic
type
systems
and
and
so
that
you
know
it's
an
example.
N
We
can
look
at
you
know
I
don't
know
how
often
that's
the
you
know-
that's
used
in
practice
there,
but
you
know
because
there's
plenty
yeah,
it's
turning
complete
type
system,
basically
so
and
then
yeah
another
another
thought
is
to
you
know.
The
the
usefulness
of
this
is
that
in
some
ways
in
graphql
we
implicitly
already
have
this
concept
in
that
like
when
you
want
to
spread
on
node,
say
in
in
a
union.
N
N
That's
that's
happening
there
that
you
know
this
could
help
make
more
explicit,
which
you
know,
which
would
be
nice.
F
Okay,
so
I
think
the
next
actions
are
under
better
understand
the
impact
on
seeing
if
it
changes
the
way
in
which
local
fragment
constraints
work
such
that
you
could
directly
query
fields
without
having
to
spread
on
the
individual
types
doing
a
little
bit
of
research
to
see
how
other
languages
or
other
type
systems
specifically
handle
those
kind
of
problems
that
look
for
any
kind
of
precedent
that
we
might
be
able
to
learn
from,
and
then
just
one
last
kind
of
thought
is
based
on
kind
of
the
initial
confusion
around
the
idea
of
a
union
implementing
something
which
I
think
is
it.
F
It
was
easier
for
me
to
understand
this
once
I
realized
that
this
was
a
constraint
rather
than
a
union
implementing
something
since
unions
don't
have
fields
in
the
same
way
that
interfaces
and
objects
do
maybe
there's
just
a
different
keyword
that
describes
this.
I
don't
know
if
it's
like
contains,
or
I
don't
know.
I
don't
have
a
great
suggestion
for
you,
but
that
might
be
another
thing.
That's
worth
exploring,
while
you're
at
the
space.
I
O
H
O
O
F
I'm
gonna
put
it
at
rc1.
For
now
we
can
always
push
it
back,
but
given
that
people
seem
generally
enthused
about
the
problem
being
solved
here,
I
think
it's
okay
to
let
it
float
at
that
that
point.
Unless
anybody
disagrees.
I
I
That's
already
been
sent,
so
we
had
decided
that
it
should
bubble
up
to
the
boundary
of
the
payload
for
and
there's
cases
of
both
where
it's
the
field
is
an
error
or
the
field
was
null
and
it
needed
to
bubble
up
higher
and
could
that
be
distinguished
for
deferred
payloads,
since
they
defer
is
only
on
fragments
deferred
payloads
are
the
data,
is
always
an
object,
so
the
distinction
there
is
relatively
straightforward.
I
I
I
I
guess
the
first
thing
this
was
also
we
talked
about
is
an
advantage
for
handling
batching
in
the
future.
I
So
the
first
thing
I
want
to
say
is
that
I
I
wouldn't
I
don't
want
to
include
batching
in
this
proposal,
so
that
could
be
something
that
could
be
added
later
on,
and
so
I
would
like
to
move
forward
with
data
being
in
an
array
with
the
list
element
inside
of
it,
and
the
spec
is
going
to
say
that
it's
only
ever
going
to
be
one
one
piece
of
data
inside
of
it.
I
So
we'd
like
to
get
consensus
on
that.
Additionally,
we
had
talked
about
moving
the
number
of
the
element
out
of
this
path
and
into
its
own
property,
and
this
I'm
kind
of
a
little
bit
less
clear
on
the
benefits
of
it.
I
could
see
we
had
talked
about
sending
things
out
of
order.
As
a
reminder,
we
had
already
agreed
that
spec
now
that
stream
payables
have
to
come
in
order.
I
F
If
I
remember
the
thought
on
having
at
index
be
pulled
out,
is
that
it
differentiated
from
the
full
value
and
the
index
within
it,
because
the
you
can't
index
into
the
individual
array
elements
with
the
graphical
query,
and
it
gave
you
a
fairly
easy
way
to
tell
the
difference
between
a
stream
into
a
payload.
That's
describing
a
stream
into
a
list
versus
one
that
is
a
deferred
chunk
or
something.
You
have
this.
This
field
that
you
can
look
at
and
pretty
clearly
understand
that.
But
it
does
seem
like
it's.
I
Yeah,
I
think
we
already
would
have
that
with
the
with
array
wrapping
around
data,
that's
pretty
uniquely
saying
that
it's
a
stream
payload
and
additionally,
that's.
That
is
the
reason
why
we
have
the
the
label
field.
So
if
you
do
need
to
identify
exactly
where
it
came
from,
that's
another
option.
B
Rob
with
a
with
a
streamed
situation:
do
you
get
an
empty
if
you
have
like
the
first
zero?
For
example,
do
you
still
get
an
empty
array
in
that
original
payload?
You
do
yeah.
That
too
then,
potentially.
H
I
have
a
question
so
I'm
imagining,
for
example,
the
stream
of
stock
quotes
right
and
essentially
the
server
can
it
can
reuse
the
same
stream
for
many
many
clients.
H
H
What
I'm
saying
is
that
the
the
downside
of
keeping
this
in
the
index
for
the
server
and
I'm
not
sure
it's
useful
for
the
client?
Another
thing
you
mentioned
from
the
beginning:
you
want
to
have
in
this
at
least
release
you
want
to
avoid
the
batch
batching
right,
but
I
see
it
better.
O
H
But
I
think
batching
is
inevitably
coming
for,
if
simply
for
efficiency,
it
should
be,
and
if
it's
inevitable,
then
I
think
it's
worth
addressing
potential
implementation
troubles
or
whatever
now,
rather
than
later,
discovering
them
so
and
things
like
this
like
indexing,
because
it
it
effectively
prevents
reusing
these
streams
on
the
server.
A
I
I
really
don't
see
it
this
way,
because
I
mean
you
have
the
you
have
a
local
state
in
your
execution
engine
anyway,.
O
C
H
O
Yeah,
I
I
have
an
implementation
up
at
graphql
executor.
You
know
just
just
a
fork
of
my
fork
for
graphical
and
it
it.
O
It
currently
has
different
behavior
when
batching
is
requested
and
right
now
it
only
or
sorry
parallel
streaming
is
requested
and
right
now,
it'll
only
send
this
ad
index
field
when
possibly
parallel
or
out
of
order
streaming
is
enabled,
and
it
just
leaves
it
as
is
currently-
and
you
know,
building
on
that,
meaning
the
the
the
client
is
going
to
is
going
to
have
to
specify
whether
they
want
batching
or
or
out
of
order
or
slash
parallel
streaming
and
if,
if
they're,
using
the
default,
what
would
be
the
default
now?
O
What
would
be
released
with
this
individual
version?
It
would
only
be
sequential,
and
so
we
could
say
that
we're
going
to
stick
with
you
know
what
you
know
the
index
in
as
the
last
field
in
the
path.
Just
in
that
case-
and
you
know,
if
we
enable
batching
later,
we
can
always
add
the
additional
field.
But
moreover,
I
I
do
think
roman's
suggestion
is
very,
very
interesting
that
you
know
seeing
as
it's
guaranteed
to
be
sequential.
I'm
not
sure
why
we
necessarily
need
to
include
the
index.
O
F
Is
there
any
case
that
some
kind
of
data
integrity
issue
some
something
could
cause
one
of
these
payloads
to
get
dropped
or
accidentally
show
up
out
of
order
when
it
shouldn't
be
such
that
this
ends
up
being
like
a
parody
check.
H
It
depends
on
what
what
is
the
order?
I'm
more
imagining
you
are
requesting
the
client
request
to
kind
of
start,
seeing
some
stream,
which
is
internal,
the
stream
doesn't
start
when
it
is
requested
by
the
client
like
stock
quotes,
they
go
on
and
the
client
says
oops.
I
want
to
see
it
give
me
the
stream.
So
in
this
sense
the
index
is
almost
meaningless.
H
O
Be
like
a
subscription
type
example.
I
mean
in
this
case
you're
asking
to
stream
the
the
top
first
10
000,
most
popular
songs
of
the
90s.
I
mean
that's
a
lot
of
data,
so
you
maybe
want
to
stream
it,
and
so
then
there
is
a
particular
order
to
each.
You
know
song
in
terms
of
the
hierarchy,
and
I
guess
I
do
see
lee's
point
about
data
integrity,
although
I
guess
that
could
be
handled
different
ways.
F
That
implies
that
the
typical
implementation
may
look
at
this
sniff
to
see
if
there's
a
number
at
the
end
of
the
path
pop
that
number
off
the
path
and
then
use
the
path
to
find
the
piece
of
data
that
they're
about
to
concat
the
data
into.
F
And
if
that's
the
case,
then
let's
save
them
the
trouble
and
not
include
the
number
in
the
path,
and
I
I'm
remembering
now
that
that
was
part
of
the
rationale
for
for
pulling
it
out
was
we
were
thinking
about
what
the
actual
stream
receivers
implementation
might
look
like
and
trying
to
figure
out
how
we
would
do
this
in
a
straightforward
way
for
them.
I
do
still
find
that
the
parity
check
thing
compelling.
F
You
know
if
you
end
up
in
something
where
you're,
like
things
show
up
on
the
client
out
of
order
and
you're,
not
sure.
What's
going
on,
the
first
thing
you
would
look
at
is
well,
did
we
did
our
payloads
make
sense,
were
they
applying
themselves
at
the
appropriate
index,
and
especially
if
we
think
at
some
point
in
the
future
we
might
want
to
allow
out
of
order.
Payloads
then
having
this
from
the
beginning
would
be
useful.
A
This
is
always
just
the
last
indexer
we
would
put
pop
essentially
because
if
we
have
a
more
complex
path,
where
you
have
a
list,
you're
you're
in
a
list
and
stream
an
inner
list,
then
you
would
need
indexes
right.
I
Exactly
yeah
yeah,
just
this
number
there
there
will
be
numbers
in
the
past
even
for
non-stream
payloads,
for
streams,
insider
streams,
etc.
I
A
If
it's,
if
we
all,
if
we
all
agree
that
it's
always
an
append,
at
least
at
this
stage,
then
we
can
remove
the
number
at
the
end.
So.
F
I'm
always
in
favor
of
including
more
data
rather
than
less,
because
our
our
assumption
now
that
that's
a
a
non-useful
piece
of
information
may
come
back
to
bite
us
as
this
feature
evolves
yeah,
and
you
know
if
these
things
feel
equivalent
to
us,
and
actually,
I
think,
michael,
you
make
a
good
point
about
how
if
there
was
a
nested
stream,
the
parent
ones
index
would
very
clearly
appear
in
the
path,
because
that's
the
only
way
in
which
you'd
be
able
to
get
to
the
value
that
you're
writing
into
then
maybe
it
is
weird
for
along
the
path
is
the
number
is
in
there,
but
at
the
end
of
the
path
it's
not
and
so
yeah,
maybe
it
maybe
it
does
make
sense.
F
H
Can
I
suggest
something
so
we
as
far
understand
we
send
array
in
slices
right
here
certain
array
from
the
server
to
so
this
array
of
items
is
sometimes
it
is
a
set
and
neither
client
nor
server
care
about
the
order
most
of
the
time
they
do
so,
let's
say
we
send
other
items,
you
know
and
items
come
other
details,
let's
say
or
members
of
the
group.
They
come
in
a
certain
order.
So
when
the
application
cares
about
the
order,
usually
the
index
is
part
of
the
object
and
we
don't
have
to
worry
about
this.
H
So
when
object,
like
person
arrives,
it
has
the
index
inside.
So
I
think
usually,
these
these
server
and
client
or
application
designers.
They
don't
leave
it
to
the
protocol,
they
don't
rely
on
the
protocol,
but
because
they
they
do
need
this
kind
of
thing
everywhere.
So
this
index
is
already
there
explicit.
H
O
H
O
F
To
timing
issues
I
have
two
separate
but
related
concerns.
One
is
given
the
constraints
that
we've
already
set
up,
there's
a
bug
or
some
other
kind
of
reliability
issue
and
not
having
this
information
means
an
inability
to
differentiate
between
that
error,
condition
and
a
safe
condition.
Whereas
having
the
the
piece
of
information
there
does
give
you
that
ability,
even
if
you
most
people,
won't
use
it.
Some
savvy
engineer
is
gonna,
go
build
that
and
then
the
other
one
is.
F
Today's
constraint
says
that
these
must
appear
in
the
order
and
therefore
a
insert
into
at
index,
and
it
can
cat
are
equivalent
operations.
But
this
that's
not
saying
that
for
forever
into
the
future.
That
will
always
be
the
case
like
we
could
come
back
to
this
at
some
point
and
say:
hey.
We
have
a
use
case
that
wants
to
deliver
streamed,
payloads
out
of
order
which
is
an
opt-in
operation
and
now,
oh,
we
have
to
change
the
payload
details
in
order
to
have
enough
information
to
do
that.
F
C
We
should
not
try
to
to
squeeze
with
advanced
use
cases
like
patching,
for
example,
into
a
payload
format
that
was
initially
designed
for
simple
response,
a
graphql
response
in
the
chat.
I
send,
like
example,
of
why
we
cannot
create
another
top
level
field
and
have
it
as
array
to
to
how
like
to
do
batch
and
like
one
one
one
wire
up
in
this
case.
We
we
don't
even
need
to
do
slices.
We
can
just
batch
as
part
of
a
format
and
another
thing
it's
I
think.
C
Another
thing
people
like
asked
previously
is
how
to
understand
that
particular
stream
is
finished
versus,
like
the
whole
asynchronous
part
of
the
choir
is
finished.
So
right
now
we
have
has
next,
but
has
next
is
global,
so
I
don't.
I
cannot
distinguish
between
the
all
stream
and
d4
for
a
query
finish
versus
streaming,
films
stream
with
particular
one.
This
example
finished.
C
C
F
F
Go
ahead,
we've
talked
about
this
before
in
terms
of
looking
at
whether
the
has
next
field
exists.
If
that,
if
the
has
next
field
exists,
oh,
I
guess
that's
not
true,
because
the
initial
pillar
has
that
too.
Okay,
I
see
what
you're
saying
go
ahead,
rob.
C
Yeah
and
incremental
property
is
like
well,
I'm
not
good
at
naming
things
like,
for
example,
I
always
ask
benjit
to
come
up
with
better
name,
so
incremental,
just
civilization
and
another
thing
one.
One
thing
I
don't
like
about
current
proposal
and
it's
included
in
a
lot
of
discussion
is
that
server
can
ignore
a
stream
and
defer.
I
I
don't
like
that
part
so
much
because
it's
kind
of
weird
you
send
like
some
directive
and
server
ignore
it
and
discussion
was.
C
If
we
do
topo
field,
we
can
say,
like
the
server
is
required
to
to
split
query,
but
he
can
return
it
to
the
same
response.
So
you
return
the
data
without
streaming
different
fields,
but
if
you
can
return
them
at
the
same
time,
you
add
this
incremental
or
some
other
name
in
the
same
response,
I'm
by
just
regression.
C
You
know
like
batching
on
not
batching
inside
inside,
like
particular
by
what,
how
suggested,
in
this
proposal,
by
batching
on
number
of
payloads
under.
I
Incremental
field
yeah.
Actually
I
think
we
were
going
to
talk
about
that
next,
where
we,
we
talked
a
little
bit
last
week
last
month
about
how
the
the
facebook
graphql
server.
They
have
a
way
of
batching
by
returning
multiple
payloads
in
an
array,
so
least
suggestion
of
wrapping
all
incremental
payloads
in
an
array.
Even
if
we're
not
doing
batching
that
that
would-
and
I
actually
I
think
what
we're
going
to
talk
about
next
was
like.
Is
that
something
that
we
should
do
now?
I
Just
so
when
we
do
support
batching
it's
there
and
it's
not
changing,
but
I
guess
that
that
would
also
be
a
a
way
to
distinguish
initial
payloads
and
subsequent
payloads.
If
everything
that
is
subsequent
has
to
be
wrapped
in
an
array.
L
So,
just
just
to
be
clear
for
what
we
do
at
meta,
we
we
don't
wrap
in
the
array
we
just
return
to
j
like
if
we're
batching
and
two
items
return.
We
return.
Two
json
objects
back
to
back
in
the
same
like
http
response,
so
it
it's.
F
Change,
there's
a
subtle
difference
in
client-side
behavior,
though
right,
because
a
client
could
parse
this
first
json
object
trigger
a
ui,
render
immediately
start
parsing.
The
second
one
trigger
a
ui
render,
and
if
it's
wants
to
try
to
batch
those
renders
then
it
has
to
have
like
I
know
on
web
react.
Has
some
frame
based
timeout,
but,
like
not
all
environments,
have
that,
so
you
can
end
up
creating
cpu
thrash.
L
Yeah
to
be
clear,
I'm
not
arguing
that
that's
necessarily
the
correct
I'm
just
saying
this
is
this
is
how
we
do
it.
It
is
possible
to
do
it
this
way.
That
is
like
the
simplest
way
and
even
in
graphical,
like
our
responses,
end
up
like
syntax
highlighting
fails
because
you
have
no.
You
have
like
multiple
json
objects
at
the
top
level,
which
isn't
valid.
A
Now,
from
efficiency,
standpoint
you're
sending
more
data
down,
essentially
because
you
always
have
these
ceremony
types
and
like
data,
multiple
data
fields
and
stuff.
O
Can
I
can
I
be
so
bold
as
to
say
that
we're
that
we're
sort
of
hitting
on
the
next
a
point
of
discussion?
I
would
definitely
want
to
incorporate
everyone's
comments.
That
are
definitely
on
point
for
that.
But
do
you
think
we're
done
with
our
discussion
about
path,
possibly,
and
I
think
the
consensus
seemed
to
be
around
you
know,
leaving
off
the
attendance
field
and
putting
it
in
path
and
then
we'll
get
to.
I
wanna
just
show
everybody
some
alternatives
as.
I
Okay,
so
so
I
I'm
gonna,
move
forward
with
wrapping
data
in
an
array
and
leaving
the
index
on
path
and
then
I'll
hand
it
off
to
yakov.
B
Well,
not
just
personal
preference.
I
don't
feel
that
the
index
really
lives
at
the
end
of
the
path,
in
particular.
If
you've
got
the
embedded
responses,
then
they're
not
going
to
share
that
same
number,
necessarily
because
there
could
be
more
than
one
of
them.
B
Obviously
right
now
we're
talking
about
having
one
thing
in
that
array,
but
if
there's
two
or
three
and
the
first
one
is
eight
there's
gonna,
be
things
children
that
have
the
nine
and
the
ten
referenced
which
you
know
later
in
later
payloads,
which
feels
a
bit
wrong,
but
also
like.
B
I
don't
think
that
the
numbers
required
at
all.
I
hear
what
lee
says
about
it,
but
I
still
don't
particularly
feel
that
that's
required,
like
you
know
the
protocols
we
use
like
tcp
and
whatnot
handle
stuff.
You
should
be
able
to
check
the
payloads
as
you
receive
them.
If
you've
got
some
kind
of
transport
layer
going
on
there,
it
feels
like
it
feels
like
adding
a
property
just
to
check,
for
that
kind
of
thing
is.
F
Let's
the
previous.
F
F
O
Oh,
I
didn't
mean
to
to
cut
discussion
short.
I
just
thought
that
we
had
reached
consistent
consensus.
I
mean
I
feel
like
we.
I
don't
know.
J
O
Carry
on
sorry,
okay,
I'm
gonna
try
to
share
my
screen
again.
O
Okay,
so
this
was
this
was
a
discussion
about
paving
the
way
to
optimize
batch
streaming
in
the
future
right
now.
O
The
implementation
that
we're
using
to
when
we
use
when
we
when
a
stream
is
requested,
it
might
be
requested
when
the
back
end
is
supplying
a
very
long
list,
statically
or
it
could
be
requested
or
in
probably
even
in
a
better
case
and
when
the
back
end
is
using
some
sort
of
streaming
protocol,
such
as
an
async
iterator
to
supply
values
and
the
values
can
be
streamed
to
the
server
and
then
can
be
streamed
to
the
client
after
they're
completed.
O
So
the
suggestion
here
is
to
is
to
in
the
graphql
js
implementation
is
is,
is
to
use
an
async
iterator
from
the
underlying
service,
not
of
values
but
of
iterables.
It's
kind
of
an
implementation,
specific
decision,
but
the
basic
idea.
There's
a
link
over
here,
I'm
sure,
there's
a
lot
of
discussion.
O
The
basic
idea
is
that
when
we
use
async
iterators
in
javascript,
we
have
to
go
back
to
the
event
loop
on
every
item,
but
if
we
instead
use
async
iterables
of
you
know
slices
of
of
the
eventual
list,
then
we
can
preserve
some
of
the
batch
execution
and
the
similar
idea
is
that
and
for
a
similar
reason,
eventually
we're
going
to
in
return
an
async
generator
that
generates
payloads
that
can
be
sent
by
the
graphql
server
to
the
client
and
if
multiple
payloads
happen
to
be
available.
O
At
the
same
time,
we
should
probably
make
those
available
to
the
you
know
the
server
at
the
same
time
so
that
they
can
be
sent
at
the
same
time
and
so
the
main
motivation
you
know
in
terms
of
timing
basis.
In
terms
of
timing,
this
would
be
a
breaking
change,
both
in
the
graphql
in
js
implementation
and
for
clients,
meaning
for
the
two
points
respectively
that
I
mentioned,
meaning
right
now.
Resolvers
return
lists,
they
return.
O
O
Also,
what
I'm
suggesting
is
that,
specifically,
they
should
be
allowed
to
return
iterables
or
async
iterables
of
iterables
meaning
of
selections,
and
so,
if
we
we
try
to
introduce
this
change
later,
anybody
who's
written
a
resolver
that
returns
an
async
iterator
iterable
of
items
is
going
to
be
kind
of
annoyed,
and
the
second
issue
is
a
little
bit
less
less
of
a
problem,
because
just
only
servers
would
have
to
update
their
code
to
you
know.
O
If
we
would
prefer
you
know,
change
the
async
generator
that
graphql
that
execute
returns
to
you
know
similarly
return
async
iterable
pale
of
of
arrays
of
payloads,
then
that
would
be
a
breaking
change,
but
only
for
servers.
So
what
about
spec
change?
I
put
this
down
as
a
question
because,
basically
getting
into
the
async
variables
didn't
seem
like
it
was
specified
so
much
to
begin
with.
In
terms
of
the
first
question,
I
think
definitely
in
terms
of
the
second
question.
O
We
would
need
a
spec
change
and
I've
put
some
languages
into
the
division
to
respect
changes,
or
you
know
for
both
of
these.
Basically
to
make
it
a
little
bit
clearer.
Maybe
I
should
have
started
with
this.
What
I'm
suggesting
is
that
the
return
type
this
is
for
the
second
issue.
The
return
type
of
execute
would
be
an
async
generator
of
not
of
an
async
execution
result
but
of
an
array
of
async
execution
results
and
it's
similarly,
the
the
the
format
that
that
a
resolver
will
return.
O
You
would
be
an
async
iterator
of
an
array
of
values.
I'm
gonna
skip
over
this
section
in
terms
of
subscribe.
Basically,
there
are
different
options,
but
I
chose
in
the
implementation
I
used
to
you
know
to
unify
it
with
execute,
and
you
know
we
can
talk
about
that
later.
O
That's
kind
of
a
detail
here
I
have
here's
just
just
to
give
you
a
sense
of
how
this
would
look
and
I
think
it
basically,
it
dovetails
nicely
with
what
what
ivan
was
mentioning
before
and
that's
why
I
sort
of
jumped
into
it,
although
it
just
uses
arrays
instead
of
you
know,
keyed
objects
to
describe
the
the
fields
here
we
have
like
a
pretty
normal
result.
O
It
would
be
wrapped
in
in
our
array,
because
all
the
results
are
are
available
at
the
same
time,
and
here
sorry
this
is
with
with
defer
you
know
without
defer
you
would
just
you
know
you
would
just
get
a
single
payload,
but
with
defer
if
everything
is
available.
At
the
same
time,
you
would
get
the
two
all
three
different
results
at
the
same
time,
wrapped
in
one
array.
What
about?
O
If
you
have
a
slow
field
in
the
initial
payload,
and
then
basically
here
you
have
the
difference
right
here,
you're
in
your
first,
the
generator
would
give
the
first
item
right
away
and
then,
with
this
slow
field
would
come.
O
You
know
stream
and
thought
of
initial
track,
one
it's
all.
If
we're
streaming
from
a
list,
it
can
all
be
sent
at
the
same
time.
You
can
ignore
the
stuff
over
here
about
chunks
greater
than
one.
This
is
because
it's
from
my
fork
set
currently
on.
Oh,
I
was
batched
into
streaming,
but
this
is
the.
This
is
the
main
additional
case
that
we
have
over
here,
which
is
the
stream
where
you
let's
say
you
have
a
slow
initial
item
again.
O
O
To
agree
with
my
goals
point
about
how
this
type
of
matching
creates
extra.
You
know
data
that's
sent
to
the
client,
whether
in
stream,
if
we
match
within
the
data
object
within
the
data
array
in
larger
chunks
as
I've
implemented
in
some
of
these
other
examples,
we
end
up
being
able
to
consolidate
some
of
the
data.
That's
true
and
I
think
basically,
we
should
support
both
types
of
patching.
O
I
agree
with
rob
that
I
think
we
need
to
support
it
as
the
first
thing
that
gets
out
of
the
of
the
gate,
but
I
do
think
also
to
agree
with
roman.
I
think
that
it
eventually
will
be
coming,
and
so
I
just
think
we
should
be
prepared
for
that
eventuality
in
the
larger
scheme
of
things
whether
we
put
the
ad
index.
O
You
know
here
in
this
example,
whether
we
put
that
in
the
path
or
separate
through
the
path,
that's
kind
of
a
detail
that
I
hope
we
can
get
consensus
on
very
quickly
because,
as
I
snuck
into
the
agenda,
I
think
these
are
like
basically
the
last
two
working
items
that
we
have
left
to
getting
this
to
the
next
stage.
O
I
think
this
is
a
good
idea.
I
don't
think
necessarily.
It
needs
to
be
in
arrays
versus
structured
objects,
so
I
basically
agree
with
with
ivan
as
well
just
to
point
a
ahead
to
you
know
how
a
chunked
response
might
look.
A
funk
response
would
look
like
this.
If
you
have,
this
has
been
streaming
so
we
can
see
here
in
this
first
example.
O
Everything
that's
ready
is
sent
in
the
first
payload
these,
the
the
initial
list,
as
well
as
the
as
well
as
items
number
two
and
three,
and
they
are
at
indices
one
and
two,
and
here
we
can't
just
stick
it
at
the
end
of
the
path.
So
we
have
to
use
something.
O
I
would
suggest
that,
if
we're
going
to
use
an
index
field,
we
should
probably
and
we're
keeping
the
current
form
happening,
we're
not
radically
altering
like
ivan
said,
we
should
probably
make
it
parallel
to
data
how
it
has
to
be
an
array
we
should
probably
make.
O
It
also
have
to
be
an
array
of
a
single
item
with
the
index
just
just
to
prepare
the
way
for
you
know
what
we
have
implemented
here
and
then
the
slow
item
would
be
index
zero,
which
would
become
later
and
that's
basically
the
these
are
the
examples
of
the
I'm
sorry
I
didn't
put
in
here
the
example
of
the
resolvers,
but
the
resolver
resolvers.
Basically,
you
know
you'd
have
to
design
you.
O
It
would
be
suggested
to
design
your
resolvers
to
to
only
for
simplicity,
to
only
give
payloads
that
are
raised,
even
if
the
array
is
of
length
one
and
that's
about
it.
F
I
know
we're
right
at
time,
so
I
think
most
of
our
feedback
might
have
to
come
on
your
discussion
thread,
but
just
a
quick
reaction
here
is,
I
think
this
makes
a
ton
of
sense,
the
type
that
you
described,
having
an
async
iterator
of
an
iterable
of
some
value,
that's
a
direct
match
with
the
the
pattern
that
I've
seen
elsewhere.
F
F
O
Thanks
anyone
else
with
maybe
ivan,
if
you,
if
you
you're
looking
at
this
and
comparing
with
what
you
have
suggested,
any
thoughts.
C
Yeah,
so
I
I
wouldn't
say
it's
a
it's
an
issue
if
we
duplicate,
especially
since
we're
duplicating
not
like
inside
every
object
in
nested
response,
but
we're
duplicating
fields
only
on
stream,
while
on
the
or
before
level,
it's
like
manually
created
points
by
client.
So
I
expect
like
people
use
only
a
couple
of
d4
or
like
wait.
C
O
I
think
that's,
that's
totally.
Fine!
That's
totally
acceptable.
I
think
for
this
you
know
this
there's
a
lot
of
content
in
here.
This
is
this.
Is
the
issue
that's
on
my
fork,
but
if
we
just
go
back
one
or
two
a
lot
of
examples
here,
what
I'm
suggesting
over
here
right
now
is
only
to
do
the
batching
that
I
think,
is
more
in
line
with
what
you're
saying
and
we
can
think
about
adding
batching
within
the
payloads.
O
If
it's
you
know,
in
terms
of
what
michael's
saying
about
saving
fields,
if
someone
doesn't
use
compression,
et
cetera,
et
cetera,
but
the
key
thing
here
is
is
whether
you
agree
with
the
with
the
other
type
of
matching,
that's
more
in
line
with
what
you're
suggesting,
but
just
using
arrays
being
patching
entire
payloads.
O
That's
the
key
yeah.