►
From YouTube: GraphQL Working Group - October 7, 2021
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
B
C
A
I'm
starting
to
starting
to
wish
that
github
ordered
the
agendas
in
reverse
chronological
order.
Oh
yeah,
the
list
is
getting
a
bit
longer.
Every
time.
E
Yeah,
I
agree,
I
thought
about
adding
like
a
directory
layer
in
there
for
a
year,
but
I
don't
want
to
like
break
all
our
old
links.
A
E
Speaking
of
which
I
have
to
go,
pull
up
the
agenda
file
and
the
notes
please
and
the
notes
I
always
forget
to
do
this
before
the
meeting
starts.
A
It's
got
the
handy,
google
docs
to
mark
down
converter.
What
would
be
really
nice
is
if
it
then
had
the
reverse.
That
would
make
it
a
lot
easier
to
to
populate
it.
Yep.
G
A
The
the
github
column
in
the
agenda
seems
to
have
worked
well.
Everyone's
just
automatically
filled
out
so
good
fix,
beautiful.
E
E
We
got
15
names
on
our
lists
and
13
people
on
the
call
which
is
pretty
dang
close
to
a
quorum.
So
I
think
we'll
probably
just
get
started
and
let
anybody
who's
not
here
yet
show
up
when
they're
going
to
show
up,
although
I
don't
know
how
close
of
an
overlapping
venn
diagram
that
is
so
if
your
name's
not
on
the
agenda,
send
in
a
pull
request
I'll
get
emerged
in
quickly,
but
as
we
always
do
all
right
actually,
first
a
quick
note.
E
E
We
will
go
down
the
list
as
it's
written
down
in
the
agenda
file
and
if
you
don't
have
your
name
there,
yet
that's
okay,
just
introduce
yourself
at
the
end!
So
hey
everybody!
My
name
is
lee.
H
Oh,
I
guess
I'm
next
hey,
I'm!
I'm
alex
I'm
from
yelp
in
san
francisco.
E
G
E
I
never
want
to
go
with
the
zoom
list
because
that
one
yup
random
math.random
order
michael's,
not
here
yet
so.
Benji
you're
up,
hey.
A
Everyone
I'm
I'm
benji
maintainer
at
the
grapho
open
source
suite
from
the
uk.
J
Hey
just
came
in,
I
didn't
realize
it
was
right
just
in
time
I
work
on
a
graphql
proxy
ibm
and
it's
just
in
a
few
of
these
topics.
K
Cool
I'm
jordan
from
facebook
on
the
relay
team.
M
C
Awesome,
I'm
hugh
in
ottawa
work
for
apollo
on
several
different
open
source
projects
like
apollo,
client
and
apollo
server.
I
Hey
everyone,
I'm
sasha.
I
do
graphql
at
twitter.
E
We
got
everybody
awesome
very
happy
to
have
you
all
here,
thanks
so
much
for
doing
introductions.
Let's
make
sure
we
have
enough
people
in
our
notes.
File
I
see.
Benji
has
already
made
significant
progress
and
I
see
a
handful
of
people
have
that
open.
Do
we
have
enough
folks
who
can
jump
in
and
take
notes,
especially
as
benji
jumps
into
conversation.
M
E
E
Most
excellent
and
sorry
again
for
getting
that
up
at
the
last
possible
minute,
but
you
are
impressively
copying
over
context
there.
Let's
take
a
quick
look
at
our
agenda.
We
have
a
lot
of
stuff
to
talk
about
today,
so
we'll
do
our
best
to
stay
on
time.
E
I
see
they
all
a
lot
of
these
say
five
minutes,
I'm
gonna
go
ahead
and
guess
that
that's
optimistic,
but
I
think,
even
if
we
a
lot
10
to
15
for
all
these,
we
should
be
able
to
get
through
them
all.
First
we're
going
to
take
a
look
at
the
action
items.
We're
going
to
talk
about
nobility,
rfc
argument,
name
uniqueness,
one
of
map
types
allowing
descriptions
on
executable
definitions
and
why
errors
that's
a
good
list
of
things?
Are
we
missing
anything
and
does
this?
This
order
seem
reasonable.
E
I
see
nothing
flagged
as
ready
for
review,
which
means
that
we're
probably
not
going
to
spend
too
much
time
here.
But
let's
take
a
quick
look
at
what
is
open.
We
only
have
five
past
action
items
open.
This
makes
me
very
happy
we
used
to
have
like
20
plus,
so
we've
done
very
good
on
digging
through
our
past
actions.
E
E
Some
of
these
actually
seem
somewhat
relevant
to
some
of
our
topics,
so
maybe
we'll
be
able
to
to
come
back
to
these
in
the
next
session,
but
all
right.
Well,
since
we
don't
have
any
marked
as
as
ready
for
review
and
last
meetings
aren't
in
here,
we'll
skip
past
this,
and
did
I
just
close
my
agenda
file?
I
did
oops
okay,
so
next
up
is
snullability
alex
I'll
hand
it
to
you.
H
All
right
yeah,
so
I
just
wanted
to
update
everyone
on
the
state
of
this,
had
to
take
a
little
break,
got
had
to
do
my
day
job,
but
I'm
working
on
this
full
time
right
now,
hopefully
through
to
the
end,
we
are
doing
the,
including
the
the
question
mark
syntax
that
was
described
by
lee
and
I
think
a
couple
other
people.
So
I
need
to
update
the
strawman
with
that.
H
We
have
a
implementation
up
for
in
graphql.js
that
is
open
for
public
review,
we're
looking
for
feedback
on
our
test
cases
and
the
implementation
in
general.
I've
created
this
doc
with
sort
of
like
a
like
a
more
readable
list
of
test
cases.
In
case
people
like
to
look
at
that,
instead
of
code,
that
might
be
a
little
bit
easier
to
read
through.
H
Can
you
add
a
link
to
that
to
the
agenda?
Oh
yeah
for
sure
I'll
I'll?
Add
it
later.
It's
also
linked
in
the
in
the
pr,
but
I'll.
I
will
add
that
yeah
test
cases
we're
gonna
begin
rewriting
the
proposal
next
week,
based
on
the
current
state
of
the
implementation
and
then
we'll
sort
of
you
know
as
we
get
feedback
on
the
implementation,
we'll
continue
updating
proposal
and
then
we're
going
to
open
up
a
pr
to
graphql
spec
by
the
end
of
next
week.
H
We
also
had
meetings
with
apollo
and
the
relay
teams
to
get
their
feedback
on
the
proposal
and
let
them
speak
for
themselves
in
the
details,
but
I
think
we're
all
in
agreement
about
like
the
core
of
the
behavior
of
the
features
that
we're
introducing
and
we're
also
down
to
meet
with
maintainers
of
other
client
libraries.
If
they'd
like
to
discuss
the
proposal,
shoot
me
a
message
here.
H
H
Yeah,
that
seems
reasonable
apollo.
Let
us
know
that
they're
deprecating
their
command
line
their
cli
tool,
but
we
they
suggested
that
we
try
to
integrate
it
with
the
guild
cli
tool.
So
we
might
try
to
do
that.
H
E
M
E
H
M
H
And
then
the
the
action
item
that
we
have
right
now.
Do
you
want
me
to
keep
that
up
to
date?
Is
that
helpful,
this
guy
yeah.
H
E
What
are
the,
what
are
the
open
like
what
what
part
of
the
implementation
are
you
still
exploring?
I
remember
in
the
last
conversation
we
had
around
this
the
thing
that
we
flagged
but
didn't
really
dig
into
too
much
was
doing.
Query
validation
like
if
you
have,
if
you
do
field
merging
and
you
come
across
two
fields,
one
of
which
uses
an
exclamation
point
or
question
mark
and
the
other
one
doesn't.
Is
that
allowed
or
not
allowed?
And
what
are
the
consequences
of
a
decision
like
that?
Have
you
explained
that.
H
Yet
yeah
they're
they're
effectively
treated
like
they're
just
different
types
right
now,
so
the
field
merging
rules
apply
as
if
as
if
there
are
different
types.
If
you
have
like
a
required
string
and
a
non-required
string
so
that
that
would
not
be
allowed,
you
can
work
around
that
by
aliasing
the
fields,
although
it's
kind
of
nonsensical,
with
the
bubbling
up
effect,
because
if
one
of
them
is
null,
then
it
just
blows
out
the
whole
thing.
H
Yeah,
I
think,
is
jordan
here
really
yeah.
It
really
talked
about
stripping
out
the
exclamation
points
and
then
and
then
doing
their
own
thing,
which
kind
of
helps
them.
K
K
I
think
our
plan
is,
since
we
sort
of
present
a
facade
of
fragments
being
isolated,
that
we
will
strip
them
out
and
handle
them
basically
implement
the
semantic
at
runtime,
but
with
the
behavior
that
they're
isolated
to
fragments
and
that
you
know
some
somewhere
down
the
road.
A
response
format
that
supports
isolated
names
fragments
would
be
like
sort
of
right
solution
to
get
us
back.
You
know
to
get
that
sort
of
as
part
of
the
spec,
but
I
think
we're
comfortable
with
that
divergence.
H
We
have
another
dock
that
I
can
publish
with
sort
of
like
a
list
of
known
problems
with
with
the
current
rfc
other
things
on.
There
are
a
list
there's
currently
no
good
way
to
indicate
that
a
list
item
is
non-nullable
or
like
required
relay
and
netflix
the
people
that
we're
basing
this
off
of
they
both
have.
I'm
not
blanking
on
the
word.
You
know
it
says
at
required
or
whatever
they.
H
They
both
said
that
this
isn't
a
problem
that
they've
run
into,
but
I
you
know,
I
think
it's
worth
thinking
about
an
upgrade
path.
If
that
does
become
a
problem,
something
that
we
can
implement
in
the
future,
even
if
we
don't
do
it
as
part
of
this
proposal,.
E
That
would
be
super
useful
to
have
that
doc
or,
if
you
want
to
one
of.
E
Did
recently
is
pull
a
bunch
of
the
spec
working
doc
markdown
files
into
this
working
group.
Repo.
That
way,
we
can
just
like
give
people
more
liberal
access
with
to
commit
rights
or
merge
rights.
That
might
be
a
good
place
for
this,
especially
if
you
find
that
there's
a
kind
of
a
long
tail
of
issues
you
want
to
work
through
and
want
to
keep
that
up
to
date.
So
people
who
are
going
to
watch
along
with
this
and
keep
track
of
it
and
offer
feedback.
E
H
Yeah
we're
looking
for
feedback
on
the
implementation,
so
in
the
graphql.js
thing,
and
then
I
think
we're
we're
good
otherwise,
on
on
you
know
like
what
the
path
forward
is
yeah
was
there
anything
anything
else
we
need
to
do
or
besides
opening
up
another
pr
to
graphql.spec
or
dash
spec
with
the
postal
itself.
E
Yeah
the
proposal
itself,
the
the
changes
to
the
spec,
I
think,
will
be
helpful.
Actually,
I
think,
that's
probably
a
good
in
addition
to
iterating
on
this
pull
request
and
getting
it
to
a
point
where
you
are
happy
with
it.
I
found
it
pretty
useful
to
do
spec
text
writing
and
code
rewriting
in
parallel,
because
you'll
find
forcing
you
to
think
about
it
in
terms
of
the
spec
will
highlight
gaps
in
your
implementation
and
the
writing.
E
So
that
might
be
a
good
thing
to
dig
into,
but
certainly
it
seems
like
you've
already
gotten
a
little
bit
of
feedback
on
the
on
the
pull
request
from
sahaj,
but
yeah.
That's
a
great
call
to
action
for
anybody
interested
in
this
to
go.
Take
a
look
for
sure:
okay,
yep!
That's
all
I
had.
E
Very
exciting,
thanks
for
your
continued
work
on
this.
This
is
one
of
the
proposals
I'm
most
excited
about.
I
know
it's
gonna
be
tough
to
get
it
right,
but
great
progress,
yeah.
Thank
you,
okay.
That
was
actually
pretty
dang
close
to
five
minutes.
A
little
bit
over
so
looks
good
for
keeping
us
on
time.
Next
up
is
argument,
name
uniqueness
and,
I
think,
do
or
yvonne
do
either
you
want
to
take
this.
B
We
discuss
it
before
a
call
in
github
issue
and
you
asked
me
to
champion
it
to
help
like
present
it
so
wait
to
solve.
Like
initial
confusion,
there
is
like
three
pr's
with
this
proposal
on
the
repo
one
initial
pr
did
have
like
coi
and
we
have
some
problem
with
continuous
integration.
So
you
regret
it
another
one.
B
B
I
create
graphql
jspr,
probably
it's
like
audited,
I'm
not
totally
matchable
or
not,
because
right
now
we're
preparing
new
release
of
craftkiljs,
so
a
lot
of
changes,
but
why
everything
reserve
test
cases
plus
yeah
by
the
way,
what
respect
proposal
about
if
you
wasn't
yeah
brief
time
by
the
way
big
thanks
to
banjo
for
presenting,
I
was
like
I
mean
first
time-
and
I
miss
like
working
group
call
so
bad
just
step
in
and
presented
inside
of
me
so
proposals
about
agent
validation
to
type
system
to
forbid,
duplicating
arguments.
B
It's
like
super
simple,
it's
more
like
a
mission,
but
since
it's
the
new
validation
rule
technically
technically,
you
cannot
specify
duplicate
an
argument
on
wireless,
it's
forbidden,
but
you
can
specify
duplicate
an
argument
definition,
so
I
don't
expect
we
will
actually
break
anybody.
B
E
So
let
me
make
sure
I
just
understand
one
piece
of
this:
the
this
is
about
unique
argument
definitions
and
we
already
have
one
for
unique
arguments.
So
you
is
that
right,
yeah,
okay,.
E
I'm
with
you
on
this
feeling
non-controversial,
anyone
have
any
trepidations
here
or
anything
they'd
like
to
see.
F
I
realized
I
reviewed
the
graphql
jspr
back
in
june.
This
is
completely
non-controversial
in
my
opinion,.
E
Yep,
I'm
gonna
say
ship
it.
I
think
this
is
at
at
least
stage
two.
I'm
gonna
call
this
yeah.
Let's
just
make
this
stage
two
I'll
move
it
in
the
github.
I
just
changed
the
label
right
now.
E
We
will
probably
move
it
from
two
to
three
in
the
next
meeting
or
we
could
even
do
it
asynchronously
between
now
and
then,
but
certainly
you
should
get
this
merged
into
graphql
js
and
shift
out
there
that'll
give
us
a
little
bit
of
time
to
just
triple
check
that
this
doesn't
cause
any
issue
and
get
the
right
test
coverage
that
you
want
to
see.
E
But
yeah
thanks
for
the
careful
read
both
of
you,
I
wanna
do
great
work.
E
Okay,
that
was
actually
exactly
five
minutes,
so
incredible
we're
so
on
time.
Today,
moving
on
one
of
who
boy
benji
handing
this
to
you.
A
Hey
everyone
and
if
someone
else
can
take
over
taking
the
notes
that
would
be
appreciated.
So
I
have
not
done
much
work
on
one
off
for
a
little
while,
primarily
that's
been
because
I
well
hey.
I've
had
the
lack
of
time,
but
partly
I'm
not
100
certain
that
it's
definitely
the
right
solution,
especially
factoring
in
the
the
limitations
that
I
think
we're
going
to
apply
to
the
initial
version
of
it,
which
is,
namely
that
it's
going
to
be
input
objects
only.
A
I
think,
to
start
with
so
there's
a
few
things
I
wanted
to
to
discuss,
or
at
least
to
to
raise
the
first
and
most
simple
of
them.
Is
I've
been
rethinking
the
syntax
a
little
bit?
A
I've
always
said
it
doesn't
really
matter
like
the
the
one-off
feature,
will
work
the
same
independent
of
what
the
syntax
is
in
sdl,
but
the
syntax
is
something
that
people
get
hung
up
on
and
also
if
we
were
to
apply
it
to
field
arguments
which
we
haven't
necessarily
agreed
to
do
at
this
stage,
but
we
might
want
to
doing
it
with
a
directive
is
really
awkward
because
the
directive
location
is
not
really
in
a
semantically
sensible
place
for
the
meaning
of
it.
A
So
what
I'm
proposing
we
do
at
the
moment
with
this
propose
with
this
rfc
is
that
we
use
a
one-off
keyword
that
would
come
either
before
the
curly
braces
that
define
the
fields
for
an
input,
type
or
an
output
type
or
before
the
parenthesis
that
define
the
argument
for
a
field.
A
So
then
it
makes
it
much
more
obvious
that
it's
one
of
this
list
of
things
that
is
defined
in
in
those
in
that
parenthesis
or
curly
braces.
So
that
is
my
syntactic
proposal
and
you
can
read
it
in.
I
think
the
very
last
comment
in
the
in
that
particular
issue
pull
request.
I
think
that's
quite
a
simple
one:
let's
pause
there
for
a
moment.
Does
anyone
have
any
feedback
on
on
that
proposal?.
A
I
should
probably
summarize
what
the
one-off
is
is
about.
Is
everyone
familiar.
L
L
Can
you
hear
me
actually,
yes,
careful?
Okay,
sorry
so,
with
the
guild
we
implemented,
actually
one
of
with
the
directives
for
input
objects
and
also
for
input
arguments,
and
I
totally
agree
with
you
that
on
input
arguments,
it's
like
super
awkward
and
it
doesn't
make
sense
from
just
looking
at
it.
So
I
I
guess
the
syntax
you
proposed
in
the
issue
definitely
makes
more
sense.
E
I'm
less
sure,
mainly
because
where
we
started
with
this
didn't
really
include
arguments,
we
started
with
input
objects
and
wanting
specifically
in
input
like
the
whole
conversation
that
led
us
here
was
input,
unions
and
so
arguments
is
a
little
bit
orthogonal
and
really
like
a
nicety
like
we
noticed
that
there's
similarities
between
input
objects
and
arguments,
so
we
said
hey.
E
If
we
have
a
solution
for
one,
we
should
see
if
it
matches
for
the
other,
and
this
feels
like
we're,
making
the
solution
for
inputs
a
little
bit
more
complicated,
because
now
there's
a
syntax
change
just
to
make
the
arguments
case
read
easier
when
that
was
not
our
original
goal,
and
I
I
have
a
an
alternate
proposal
which
actually
brings
you
back
to
your
original
proposal.
Benji
and
it's
not
necessarily
ideal.
It's
a
trade-off.
So
I'm
curious
what
people
think,
but
it's
one
that
has
some
precedent.
E
So
if
we
use
a
directive
and
so
directive
on
an
input
object
the
at
one
of
or
whatever
we
want
to
finally
name
that
if
you
have
a
set
of
arguments
that
you
want
to
restrict
to
only
one
particular
argument
of
a
set.
E
You
use
an
input,
object
and
so
the
the
precedent
I'm
thinking
of
is
for
mutations.
It's
really
common
to
have
like
a
bag
of
arguments,
for
a
mutation,
be
an
input
object
and
to
have
the
mutation
field.
Accept
that
input
object.
As
one
argument
you
know
we
can
question
about
whether
that's
a
reasonable
pattern.
It
has
some
historical
consequences,
but,
like
certainly,
we
see
that
pattern
show
up
quite
a
lot
and
it
might
make
it
a
little
bit
more
obvious
that
you
have
something
there.
E
J
L
I'll
go
on,
you
go
faster,
so
I
personally,
I
can
also
say
that,
like
using
just
an
input,
object
feels
more
natural,
especially
since
right
now
the
syntax
doesn't
like
the
custom
implementation
based
on
directive
doesn't
like
yeah.
You
must
place
the
directive
at
the
end.
So
most
of
the
time
we
build
some
complex
filter
and
yeah.
We
also
use
just
like
on
off
on
an
input
object
instead
of
like
the
field
arguments,
and
it
feels
better
to
use
it
like
that
and,
as
you
said,
maybe
we
don't
need
to
support
both
yet.
B
I
also
was
a
proponent
of
keeping
symmetry
because,
as
in
the
wet
proposed
change,
input
fields
are
pretty
symmetrical
with
arguments.
You
can
have
default
values.
You
can
have
like
everything
else
you
can
do
on
input
fields.
You
can
do
on
arguments,
but
thinking
more
about
this,
I
think
it's
actually
anti-pattern.
B
So
if
you
ever
decide,
you
want
some
additional
stuff
additional
like
optional
additional
configuration
you,
I
simply
cannot
edit
and
you
stuck
with
in
this
situation,
and
you
basically
need
to
duplicate
entire
field
and
do
like
name
switching
stuff.
So
I'm
I'm
actually
everything
in
my
way.
Theoretically,
it's
cool
to
continue
to
have
a
symmetry,
but
practically
speaking,
it's
very
then
like
for
schema
design
purposes.
It's
very
dangerous
to
have
like
situations
when
you
cannot
add
any
new
arguments
to
the
field.
F
Yeah
this
actually,
I
recently
have
been
dealing
with
command
line
arguments
and
one
really
clever
thing.
One
of
the
libraries
I'm
using
does
is
allow
argument
groups,
so
you
say:
okay,
this
argument
is
a
a
group
there's
a
group
of
arguments
that
we
accept
exactly
one
of
those
must
be
part
of
it,
and
so
long
as
you
have
one
of
those
arguments
set
it's
valid,
but
if
you
have
none,
it's
not,
and
if
you
have
two
it's
not,
and
so
it,
but
the
advantage
to
that.
F
If
you
label,
like
one
of
group
like
at
directive,
one
of
group
name
the
group,
you
can
then
add
additional
values
in
the
input
object
later
that
don't
fit
into
the
one
of,
but
must
be
passed
in
or
optionally
can
be
passed
in
and
like
making
it
impossible
to
have.
That
setup
feels
a
little
bit
like
we're.
Reducing
the
power.
B
We
have
groups
just
with
wrapping
so
like
you
can
use
and
put
types
as
arguments.
It's
just
way
it's
possible
it's
wrapping
and
entire
one
of
proposals
about
wrapping.
So
we
agree
that
having
having
like
simpler
version
and
more
like
typeset
version,
you
justify
additional
layer
of
wrapping.
So
if
we
decided
for
input
fields,
maybe
it's
better
to
also
have
this
for
arguments.
You
can
always
have
input
types
grouping.
N
What
do
you
think
is
cool?
You
know,
provide
more
options,
ways
to
do
things,
there's
more
ways,
for
you
know,
schema
designers
to
kind
of
shoot
themselves
in
the
footer
backed
into
a
corner,
and
so
you
know
in
this
case
you
know,
maybe
keeping
it
simple
or
simpler
is
encouraging
people
to
fall
into
the
pit
of
success
in
their
in
their
schema.
N
E
A
Oh
good
points,
I
think
my
main
motivation
with
this
is,
I
think
we
might
revisit
this
later
and
change
our
minds
and
want
to
extend
one
or
two
arguments
we
might
not,
but
we
might-
and
so
I
wanted
to
try
and
sort
of
preserve
that
option
value
there,
because
doing
that
with
a
directive,
as
we've
already
seen
in
actual
implementations
from
the
guild,
for
example,
is
not
comfortable.
It
is,
it
is
awkward
and
the
directive
approach,
also
kind
of,
as
I
think
you
pointed
out
a
while
ago
lee.
A
It
feels
like
a
different
type.
That's
why
we
actually
went
through
and
created
the
tag
type
at
one
point:
really
it's
a
variant
of
a
type,
but
again
it
does
feel
like
it
should
be
elevated
to
a
concrete
stature.
So
I
think
we're
for
the
sake
of
adding
a
keyword
to
the
language
rather
than
using
a
directive,
and
it
would
be
quite
a
simple,
straightforward
change
to
the
syntax.
I
think.
Would
it
would
it
not
and
you're
more
familiar
with
the
writing
the
passes
and
stuff
than
me
lee?
Do
you
feel
it
would
be.
A
E
At
least
this
here
we're
talking
about
changing
the
syntax
for
the
schema
language
which
the
cascading
effect
of
breaking
things
is,
is
much
lower
there
than
if
you're
gonna
change
the
syntax
or
the
query
language,
but
even
still
like
this
kind
of
the
you
know,
if
we're
adding
in
a
a
new
syntax
change,
then
I
think
your
criteria
that
you
just
described
is
the
right.
One
like
it
is
a
meaningfully
new
thing,
but
the
specific
proposal
that
you
put
in
here
still
doesn't
quite
feel
like
a
new
thing
like
it
still
input.
E
I
don't
know
that
they
would
appreciate
the
nuance
of
what's
happening
there
and
might
either
misread
it
as
a
directive
and
accidentally
add
an
at
sign
which
would
parse
correctly,
but
then
not
do
the
thing
that
they
thought
it
would
do,
or
maybe
they
would
drop
an
at
sign
from
the
directive
that
comes
after
that
and
then
get
a
parse
error
and
be
confused.
E
Why
so
like
because
of
its
location
and
and
behavior
and
similarity,
I
I
worry
that
it
ends
up
being
a
little
bit
too
nuanced
for
someone
who
hasn't
spent
the
last
like
24
months
thinking
about
input
unions
and
that's
why
my
bias
is
to
push
it
towards
existing
syntax
space
or
make
it
significantly
different,
which
is,
I
think,
what
our
goal
was
with
the
tag
type.
Was
it's
not
a
object
type?
It's
not
an
input
type
like
it's
a
distinctly
different
thing
and
yeah.
A
Okay,
cool
yeah
seems
reasonable.
I
think
the
only
other
slight
bit
of
pushback
that
I
have
was
against
your
original,
your
very
first
bit
of
feedback,
which
is
where
you
said
this.
This
all
came
out
of
solving
the
input
union's
problem
and
when,
when
I
was
thinking
about
this,
it
wasn't
only
to
solve
that
problem.
A
It
was
also
to
solve
things
like
you
often
have
getters
in
in
graphql,
like
get
a
user
by
their
email
or
get
a
user
by
you
know
some
id
or
some
other
thing,
and
those
are
convenient
at
the
moment
like
in
schemas
that
I
write,
I
give
them
dedicated
fields
because
it's
the
only
way
to
do
it
in
a
type
safe
way.
We
can
do
it.
A
As
you
say,
if
we
have
one
off
for
input
objects,
we
can
have
it
like
get
user
by
and
then
an
input
object
that
is
possible,
but
in
those
kind
of
fields
you
don't
tend
to
add
additional
arguments.
Maybe
you
maybe
you
might,
but
I
don't
tend
to
see
them.
It's
like
just
get
a
user
by
their
email.
That's
it!
There
is
no
other
complexity
to
it,
but
there
we
go,
you
know
they
could
be.
A
Maybe
it
factors
in
whether
they're,
archived
or
not,
or
something
in
future,
who
knows,
but
yes,
so
kind
of.
What
I
want
to
say
here
is
the
the
one-off
can
be
a
solution
to
the
input
union's
problem,
but
it
wasn't
designed
with
only
that
intent
in
mind.
It
was
just
bundled
in
with
it,
because
that
was
what
we
were
solving
at
the
time,
so
my
intent
for
it
was
a
little
bit
broader,
which
brings
me
nicely
onto
the
second
part
of
this
conversation.
A
So
one
of
my
main
hesitations
for
one
of
is
it
feels
wrong
to
have
a
polymorphism
on
the
input
that
is
so
distinct
from
polymorphism
on
the
output
and
also,
if
we
were
to
add
one
of
as
I'm
currently
proposing
it
even
with
just
for
input
types,
you
get
much
more
powerful
form
of
polymorphism
that
allows
not
just
one
of
multiple
object
types,
but
it
also
allows
scalars.
It
also
allows
lists.
A
It
can
allow
the
same
type
to
be
used
multiple
times
with
different
labels,
and
it
feels
wrong
to
have
more
powerful
polymorphism
on
input
than
we
have
on
output,
not
necessarily
wrong
it.
Just
you
know
it.
It
feels
hard
to
explain
and
I've
thought
a
lot
about
the
polymorphism
that
we
have
in
the
output
of
graphql
as
well,
and
we
often
get
people
talking
about
using
more
flexible
data
sources
like
mongodb,
for
example,
and
wanting
to
express
that
more
flexible
data
types.
A
Now,
I
would
say,
graphql's
purpose
is
to
abstract
those
kind
of
things
right.
It's
not
meant
to
be
like
a
linear
mapping
of
those
things,
so
we
want
to
define
a
really
nice
neat
schema
that
exposes
that
in
a
in
a
consistent
way.
A
However,
we
do
still
have
situations
where
these
things
exist
and
especially
in
the
case
of
what
we're
seeing
more
of
people
combining
lots
of
graphql
schemas
together
into
one
larger
schema,
federation
and
stitching
and
all
the
other
type
things
we're
seeing
more
and
more
people
needing
to
convert
these
data
stores
before
then
aggregating
them.
A
I
was
at
the
graphql
conf
the
other
day
and
min
chen
from
linkedin
was
talking
about
what
they've
been
doing
at
linkedin
they've
got
a
framework
that
they
use
called
rest.li
and
that's
how
they
have
their
rest
api
defined,
and
they
now
want
a
graphql
layer
over
it
and
they've
been
converting
things
from
their
service
entity.
A
Definitions
over
to
graphql
and
they've
been
doing
that
automatically,
and
it
turns
out
they
have
a
type
that
is
almost
exactly
what
I'm
proposing
would
be
the
output
type
they
have
that
already
in
their
rest
apis
and
they
need
to
convert
it
min
shared
with
me,
one
of
their
union
types
that
they
they
call
it.
A
union
type,
one
of
the
union
types
that
they
have
currently,
which
is
for
images.
A
So
when
you
specify
that
this
has
an
image
that
image
could
be
either
a
profile
picture
for
a
user,
in
which
case
it's
just
profile
picture
for
benji
done
or
it
could
be
school
logo
for
name
of
school
or
it
could
be
company
name
logo
for
name
of
company
or
it
could
be
an
image.
And
then,
if
it's
an
image,
then
it
becomes
a
whole
image
object
and
it
gets
a
whole
load
of
properties
like
its
url,
its
original
url.
A
So
they
are
actually
converting
that
at
the
moment
to
graphql
object
types,
and
they
just
know
that
every
single
field
on
those
are
nullable
and
one
of
them
will
be
set,
which
is
exactly
what
the
one-off
proposal
is.
So
I've
been
waiting
for
a
while
to
see
someone
using
this
kind
of
thing
in
the
wild
and
no
one's
reported
it
back
to
me,
but
I
did
happen
to
notice
it
in
a
conference
talk,
so
you
know
there
are
people
doing
it.
A
It
is,
it
is
good
to
have
a
solution
to
the
input
polymorphism
problem,
but
if
we're
not
going
to
add
it
to
output,
then
it
might
not
be
the
right
solution.
One
of
the
things
that
I
really
felt
that
the
one-off
proposal
has
is
that
symmetry
that
it
offers
and
the
simplicity
that
it's
built
on
all
the
existing
types
with
just
very
simple
validation
rules
added
and
I
feel
like.
A
E
I
I
think
I
agree
that
we
want.
I
I
don't
know
if
I
agree
to
the
extreme
that
if
we
can't
figure
out
how
to
do
this
for
the
output
type
system
that
we
shouldn't
do
it
for
input
type
system.
I
think
we're
still
going
to
deliver
a
bunch
of
value
by
getting
this
right
for
input,
but
I'm
with
you
that
having
some
symmetry
between
the
two
would
be
desirable
and
if
we
can
figure
that
out,
then
that's
a
great
thing.
I
think.
E
But
I'm
I'm
100
with
you
on
the
broader
vision
of
having
parity
for
input
and
output,
and
I
think
it's
a
better
way
to
represent
unions.
I
I
think
like.
If
we
had
this,
we
should
encourage
it
over
typical
unions
for
most
new
schema.
A
Okay-
that's
that's
good
to
hear
so
I
think
steps
forward
might
be
to
change
the
the
current
rfc
to
factor
out
the
arguments,
keeping
in
mind
that
we
may
add
them
in
future.
A
To
potentially
I
can't
remember
whether
it's
currently
got
output
factored
in
or
not,
but
anyway
to
add
output,
even
if
we
then
scope
it
back
out
so
that
we
can
then
scope
it
back
in
as
a
as
a
follow-up
one.
But
I
think
if
anyone
feels
that
one
of
the
other
input
union
solutions,
if
we
weren't
to
extend
one
of
to
output,
then
it
loses
that
advantage.
Does
that
then
mean
that
any
of
the
other
input
input
union
solutions
is
now
better.
A
B
I
I
also,
I
think,
I'm
have
the
same
position
as
this,
so
if
it's
work
for
input
it's
good
by
itself,
one
thing
I'm
worried
is
what
happened
like
for
input.
It's
okay,
you
provide
one
of
the
things
and
you
send
it
over
the
network,
but
for
output
inside
the
query.
You
list,
like
all
the
all
the
possibilities
you
care
for,
so
you
expect
to
get
something.
B
Which
is
like
different,
like
I
don't
want
to
prolong
discussion.
My
point
is
that
I
will
write
up
a
comment
in
in
your
proposal
and
we
can
discuss
it
asynchronously
offline,
but
for
me
input
case.
It's
like
way
way
simpler
when
output
case
is
so
just
wanted
to
propose
that
the
advances
like
anyway,
even
if
we're
stuck.
E
Yeah,
I'm
I'm
remembering
advantage
to
respond
to
your
point.
I
think
that's
also
a
problem
with
our
existing
unions,
where,
if
you
add
a
new
case
to
a
union,
you
can
end
up
with
something
where
like
at
most,
you
get
the
type
name,
and
then
you
get
nothing
else
which
I
don't
know,
maybe
that's
marginally
better,
because
at
least
you
know
what
it
was
called
in.
The
thing
you
didn't
get,
but
that's
certainly
a
case
that
we
already
kind
of
have
so
there's
some
parity
there.
E
I
I
think,
like
the
the
reason
why
output
one
of
us
were
complicated
in
the
past
is
the
actual
execution
and
response
form.
Behavior
is
meaningfully
different
and
when
addressing
this
kind
of
type,
it
doesn't
respond.
The
same
way
that
object
type
does,
whereas
inputs,
you
could
have
an
old
client
that
doesn't
know
anything
about
one
of
and
as
long
as
you
sort
of
go
by
the
letter
of
the
rule,
everything
will
just
keep
working.
E
So
I
think,
there's
going
to
be
some
complications
with
getting
output
type
right,
but
I
I'm
I'm
at
least
a
little
bit
less
worried
about
the
case
of
like
exhaustive
enum
checking,
because
we
already
have
to
have
code
generators
handle
that
case
for
the
whether
you're,
gonna
call
it
not
empty
or
unknown,
or
something
like
that
lauren
I
saw
you
had
your
hand
up.
L
A
Yeah,
I
think,
as
as
lee
hinted
before,
it
would
probably
be
if
we
added
this
to
output
types
we'd,
probably
in
general,
recommend
it
over
unions.
I
thought
about
them
quite
a
lot
and
I
see
basically
three
features
that
unions
have
that
the
tagged
type
do
not.
One
of
them
is
the
type
name
when
you
haven't
asked
it
about
its
specific
type,
which
we've
just
discussed,
is
what
evan
just
raised.
So
with
the
with
the
one-off
type
as
it
currently
stands,
you
get
no
information
with
a
union.
A
If
you
don't,
if
you
weren't,
expecting
it
you
get,
you
know
you
can
get
at
least
its
type
name,
but
that's
it.
Another
thing
is,
of
course,
unions
are
flatter.
They
don't
introduce
that
extra
layer
that
extra
object
layer.
So
there's
that-
and
the
third
thing
is
that
in
a
union
you
can
do
a
fragment,
spread
over
an
interface
type,
that
at
least
one
of
the
types
in
that
union
implements.
A
I'm
not
sure
how
useful
that
is,
and
I
think
if
you
need
that
you
should
probably
be
using
an
interface,
but
it
is
a
thing
that
you
can
do
with
the
union
that
you
would
not
be
able
to
do
with
attack
type.
So
those
are
basically
the
three
restrictions
I
was
actually
talking
with
greg
from
shopify
and
they
have
a
need
for
one
of
in
input.
They
don't
really
they.
Actually,
they
did
think
of
an
example
where
they
wanted
it
in
output,
but
have
since
replaced
that
with
an
interface-based
approach.
A
But
what
they
were
suggesting
is
that
we
could
potentially
add
like
a
field
name.
Just
like
we've
got
a
dunder
type
name.
We
could
add
dunder
field
name
to
indicate
which
of
the
fields
is
present.
A
I
think
potentially
calling
it
field
name
would
work
actually
because
aliases
are
aliases.
So
that's
fine.
That
would
then
give
us
that
extra
bit
of
information.
It
might
also
be
an
optimization
as
well
for
the
code
generators
because
then
you
can
use
like
in
typescript.
You
could
use
a.
A
A
But
again,
if
we
push
adding
one
off
to
output
to
a
separate
stage,
we
can
potentially
add
that
then
or
we
could
even
do
that
as
a
third
change
later,
if
we
felt
that
we
really
needed
it
anywho,
I
have
hogged
enough
of
the
time,
so
I
think
we
should
probably
move
on.
Thank
you
very
much
for
your
input.
Everyone.
E
D
D
All
right,
so
the
proposal
has
evolved
a
bit
from
the
initial
donation
was
allowing
a
map
type
which
would
use
a
similar
syntax
as
less
and
but
use
a
curly
brace
to
denote
this
as
a
map
after
iterating,
and
I
think
ivan
has
provided
great
feedback,
I'm
so
much
on
the
proposal,
which
is
a
list
transformation
and
what
we
mean
by
that
is
suppose,
there's
a
type
of
called
users
which
returns
a
list
of
users.
You
can
index
on
the
id
and
then
would
turn
a
list
into
a
map
and
return
that.
D
So
it
follows
in
a
similar
thing
to
how
graphical
does
alias
is
where
you
can
rename
a
field
and
then
get
something
else,
but
this
would
be
a
transformation
on
lists.
Ireland
feel
free
to
add
more
if
you
want.
I
know
you've
been
thinking
a
lot
about
this
as
well,
and
then
because
it's
a
list,
you
can
have
a
list
of
lists.
So
there's
a
couple
of
things
that
I
want
to
align
on,
and
I
will
just
go
down
to
that.
D
E
Can
you
give
a
little
bit
more
context?
I
don't
know
if
everybody
has
followed
along
quite
as
much
as
you
and
yvonne
have.
D
All
right
cool,
I
will
open
graphql,
sorry,
vs
code,
suppose
you
have
a
type
called
user
right
and
a
user
has
id
of
id.
Has
a
name
of
a
string
has
some
profile,
and
that
is
a
string
in
graphql.
This
would
be
returned
as
user's
user.
D
D
D
But
if
you
do
a
map
type,
then
you
can
take
the
list
and
transform
it
into
a
map
or
a
dictionary
keyed
by
name,
and
you
would
get
that
result
out
and
in
in
a
vein,
this
allows
you
to
query
lists
but
get
results
back
as
a
map,
so
in
most
implementations,
say
in
client
side
doing
a
map.
Lookup
is
one
while
filing
an
element
inside
the
list
is
an
on
operation.
So
this
saves
you
in
that
and
makes
the
client
side
more
efficient
when
using
those
graphql
responses.
B
Yes,
so
like
disclaimer,
I'm
observed,
or
one
of
carter
or
graffiti
and
like
when
people
discuss
it
inside
the
poll,
and
I
think
I
discuss
in
general,
they
like
remember,
experiment
we
did
like
years
ago
and
it
was
idea
to
push
boundaries.
But
during
that
we
learn
like
people
like
it's,
it
have
almost
a
thousand
stars.
I
didn't
contribute
like
it's
useful
for
people.
People
used
for
something,
but
at
the
same
time,
law
dash
is
too
big
like
some
key
transformation.
B
It's
like,
I
think,
it's
pareto,
so
you
can
satisfy
eighty
percent
of
use
cases
with
one
twenty
percent
of
transformation,
and
I
think
it
it's
top
one.
I
I
never
propose
it
because
I'm.
J
B
Person
who
have
actual
use
cases
need
to
champion
this
proposal
and
see
what
fits
and
what
not
I'm
like
against
doing
server
side
map,
for
like
two
reasons,
and
I
think
in
a
regional
issue-
lee
outwein
one
of
them-
it's
like
what
should
be
in
an
index
if
you
have
a
couple
of
keys
and
a
type
weight,
a
couple
of
fields
can
be
indexes,
and
it's
not
a
question
of
transport
to
error.
It's
not
a
question
schema
definition
too,
to
define
why
defining
the
key
is
opinionated.
B
Previously
required
fields
to
be
sent
in
same
orders
required
inside
the
query
and
people.
I
believe
people
from
community
have
like
big
issues
with
that,
because
they,
like
maps
unordered,
so
what
force
force
like,
I
think
you
did
the
change
to
to
say
it's
recommended,
but
it's
not
required
after
one
discussion.
So
basically
we
cannot
do
any
ordering
on
maps.
B
B
We
discuss
couple
variants,
and
so
variance,
I
think
we
settle
down
on
is
the
simplest
one
of
just
transforming
biggest
issue,
what
they
have
list
of
lists,
so
we
just
transform
it
to
a
mob
and
second
question:
what
to
do
with
kick
washes.
What,
if
you
have
like
a
duplicating
keys,
an
idea
is
to
reuse
idea,
argument
so
like
to
restrict
it
to
id,
and
id
is
unique
enough
to
to
use
as
a
key,
and
this
is
basically
three
increase
at
the
semantic.
D
Does
graphql
actually
enforce
so
in
a
list?
If
you
have
a
field
with
an
id,
will
it
enforce
that
each
of
the
id
fields
within
the
list
right?
So
in
that
case,
if
it's
not
enforced,
then
in
semantics,
id
exclamation
is
the
same
as
string
exclamation
right.
It's
just
for
the
user
to
know
like
this
is
a
non-human,
readable.
B
Yeah
yeah,
I
agree,
maybe
maybe
we
need
to
come
with
some
some
other
mechanism
to
a
fields
you
can
use
transformational
but
yeah.
It's
it's
details
of
proposal.
Let's
discuss
the
general
idea,
motivation
use
cases
and
how
useful
it
is
and
we
can
figure
out
a
restriction
on
the
keys
later
since
it's
right
now
we
discuss
some
stage
0
proposal
with
the
idea
of
moving
to
stage
one.
D
It
makes
it
very
easy
to
consume
the
graphql
responses
and
have
very
fast
lookups
into
those
lists
which
happens
like
when
you
have
a
list,
and
you
want
to
do
hey.
Let's
do
some
action
on
a
list
you
like
doing
the
lookups
and
and
changing
this
prediction
is
a
very,
very
common
pattern,
so
I
do
feel
like
it
has
legs,
but
before
diving
too
deep,
I
do
want
to
know
whether
the
graphql
folks,
you
think
they
should
even
focus
further
or
we
should
just
cut
it
off
at
this.
F
All
right,
I
have
relatively
strong
opinions
here,
but
I
put
a
comment
with
my
fairly
strong
opinion.
So
if
anybody
else
wants
to
dig
in.
D
Okay,
I
guess
this:
is
you
yeah
yeah?
That's
me,
okay
sounds
good.
I
will
take
a
look
at
it
a
sink,
but
for
this
proposal
over
here
ivan
from
like
duplicate
case,
I
know
you
mentioned
something
about
data
loss.
So
do
you
feel
strongly
against
that
duplicate
keys?
Should
error
out
or
one
overrides,
the
others
which
is
a
behavior
in
python
and
javascript
and
other
tools.
B
Yeah,
I
think
it's
it's
like
in
proposal.
That's
why
we
have
a
stages
stage.
One
is
to
recognize
it's
as
as
a
problem
so
and
stage
like
two
is
to
figure
out
technical,
all
the
like
edge
cases.
I
I
think
it's
edge
case.
I
want
to
provide
couple
use
cases
from
original
issue.
I
think
like
crispr
started
from
issue
number
101
and
a
lot
of
people
actually
like
it
mean
or
avoided
not
like
avoided
and
idea
was
what.
If
there
is
like
couple
of
use
cases
there
and
one
is
one
strong
use.
B
Some
type
of
sms
systems
and
other
systems
allow
you
how
users
specify
like
client,
specific
values
and
they
like
dynamic
and
the
recommended
ways
to
specify
them
was
to
use
key
values
like
for
a
lot
of
stuff
recommended
solution.
Solutions
that
we
always
recommend
is
key
value.
B
B
So
it's
like
standard
pattern,
a
problem
here,
graphql
is
the
moment
optimized
to
so
use
case
when
you
show
all
the
data,
meaning
quick,
if
you
want
to
show
all
key
value
pairs
to
represent
them
to
render
them
in
some
way
it's
enough,
and
I'm
gonna
kill
you
working
for
that.
But
what,
if
you
want
to
check?
If
something
is
present
or
not?
B
In
that
case,
you
either
need
to
do
transformation
in
the
client
or
you
need
to
use
like
a
find
on
array
to
check
if,
like
suffix
is
there
so
working
with
key
key
value.
Pairs
is
hard
and
it's
from
reading
these
comments.
I
think
it's
the
most
common
use
case
here,
another
common
use
case
I
showed
in
my
in
my
graphql
example.
B
B
It's
not
only
about
for
me,
it's
not
about
if,
where
it
make
efficiency,
how
efficient
is
to
search
an
array
or
map?
It's
more
about
developer
experience,
I
I
would
say
like
people,
if
you
have
a
big
amount
of
data
you
will
use
pagination
anyway,
but
and
for
small
amount
of
data
like
oh
on
or
one
it's
less
important,
but
developer
experience
the
fact
that
you
need
to
do
like
find
or
something
or
create
map
yourself.
It's
hard,
so
graphql
always
say
you
can
get
that
that
you
want
it's
a
question.
D
D
Yeah
yeah,
I
very
much
like
the
the
stroman
zero
is.
Is
this
a
problem?
Do
we
recognize
the
problem
and
should
we
be
solving
it?
I
think
you
make
a
great
point.
Ivan
I've
personally
experienced
this
as
well.
I
know
you've
made
a
comment.
Do
you
want
to
give
a
few
kind
of
like
10?
Second
answer
on
your
comment
like
I
know
you
get
stronger.
F
Yeah
I
can
so
yeah
matt
here.
So
my
I
have
some
very
strong
opinions
about
introducing
map
as
a
type
given
there's
no
way
to
differentiate
it
in
the
response
from
an
object
for
like
because
it's
essentially
when
we're
getting
it
as
a
response
that
looks
no
different
from
an
object
type
which
we
already
have
so
like
the
nice
thing
with
lists
is
hey.
We
know
this
is
explicitly
like
something
a
little
bit
different
because
it's
got
the
list
syntax.
So
when
we're
parsing
it's
easier
whatever.
F
Using
json,
like
not
all,
languages
have,
and
I'm
specifically
thinking
of,
like
c
plus
plus
how
you
would
use
maps
with
sequels,
plus
the
way
that
you
would
use
a
json
map.
It's
not
like
you
have
the
look
up
semantics
that
are
necessarily
exactly
the
same.
In
fact,
a
map,
a
like
standard
map
in
in
sequels
plus,
is
often
backed
by
a
list
of
pairs
right
and
given
that
I
do
think
that
there
is
a
real
need
for
user
supplied
generic
types
right.
F
We
have
no
concept
of
a
pair
of
arbitrary
types,
and
I
think
that
this
is
actually
a
real
problem
with
graphql.
In
that
you
can't
describe
okay,
I'm
I
want
to
have
a
pair
that
my
client
system
is
going
to
be
able
to
operate
over
generically.
So
when
I
get
a
list
of
this
pair,
I
can
treat
it
as
a
map,
regardless
of
how
it's
coming
over
the
wire
and
that's.
Another
kind
of
key
thing
here
is
that
graphql
is
not
defined
as
a
json
spec,
so
you
can
use
graphql
without
using
json.
F
So
making
sure
that,
like,
if
you
have
a
more
optimized
format
for
sending
graphql
from
server
to
client,
making
sure
that
will
work
with
this
new
map
type
adds
a
lot
of
complexity,
whereas
for
user,
if
we
had
a
more
like
user
generic
user
created
generic
types,
it
might
be
easier
to
do
what
you
want
without
requiring
every
implementation
to
do
the
same
thing.
E
Another
way,
I'm
just
going
to
toss
an
idea
out
there
too
matt,
because
I
I
actually,
I
think
what
matt's
proposing
here
is
really
intriguing.
It
puts
it
all
in
user
space
and
as
soon
as
we
add
generics,
things
are
going
to
get
really
complicated
in
our
type
system.
So
I,
my
heart
rate
rises
when
I
hear
generics,
because
I
don't
want
to
have
to
figure
out
all
the
details
of
it.
E
E
All
of
that,
if
you
define
a
map
purely
as
a
list
of
pairs,
it
would
also
allow
us
to
sidestep
the
ordered
non-ordered
problem,
because
in
the
in
the
output
form,
they
are
still
lists
and
still
therefore
ordered,
but
the
the
why
I
think
this
is
probably
unpopular
as
I
expect
the
reason
why
most
people
want
this.
Is
they
just
want
the
raw
json
output
to
give
them
a
json
object?
E
E
That
got
closed
was
what
is
actually
the
problem
that
we're
solving
here,
because
that
issue
tossed
out
many
very
different
problems
that
sort
of
glossed
over
as
like
a
map
type
could
solve
all
of
these,
and
I
think,
that's
probably
not
true,
like
a
solution,
would
work
well
for
one
and
work
really
poorly
for
the
other
right.
A
map
type
that
restricts
you
to
non-nullable
string
keys
broadly
describes
very
few
in
practice.
Maps
where
the
key
type
can
be
a
lot
more
variable.
E
A
lot
of
folks
just
want
to
blob
json
type
right
like
I
think
that
was
an
early
comment
on
on
your
new
issue,
open
which
was
like
hey,
I
don't
know
the
type
of
the
values
it's
arbitrary.
It's
like!
Oh
right,
yeah,
you
don't
want
a
map
type
you
an
arbitrary
json
type,
so
I
think
getting
a
better
understanding
of
exactly
what
the
problem
domain
is.
E
That
is
so
popular
that
people
want
to
solve
is
really
what's
necessary
here,
because
then
I
think
it'll
it'll
really
help
us
guide
where
we
want
to
go
to
solve
that
problem
and
whether
it
is
unlocking
something
new
in
graphql
or
whether
it
is
a
a
simplification
or
a
some
expressivity
over.
What
we
can
already
do.
I
think,
like
the
proposal
that
you
and
yvonne
have
prototyped
here
is,
is
certainly
really
interesting
and
compelling,
but
I'm
worried
that
it
might
not
pass
our
guiding
principles.
E
It's
it's
not
necessarily
a
new
capability.
It's
really
like
an
existing
type
system
that
you're
now
doing
some
post-processing
on,
and
I
think
it
maybe
goes
against
the
idea
of
simplicity
over
expressiveness
like
this
is
offering
expressiveness
express
it
and
like
that
principle,
is
there
not
to
say
expressiveness
is
bad.
It's
just
like.
We
have
to
take
a
stance
of
how
we
make
decisions
between
simplicity
and
and
expressiveness,
and
we've
decided
in
the
past
to
go
for
simplicity.
D
Right
right,
I
do
know
we're
on
the
20
minutes
time,
but
I
do
want
to
add.
Like
the
maps,
it
varies.
A
lot
of
different
problem
sets
and
one
thing
I've
seen
for
a
while
is
to
say
like
well
there's
so
many
problems.
Therefore
we're
not
gonna
solve
them,
but
I
think
they're,
very
specific.
If
you
break
down
the
problem,
there
is
like
the
id
string
id
with
a
type
right.
There
is.
D
I
do
think
that
is
as
a
problem
like
you
run
into
that
all
the
time,
especially
when
you
query
databases
which
represent
fields
as
maps,
which
you
then
have
to
turn
into
key
value
and
then
go
on
the
other
way
and
then
turn
it
back
into
another,
so
that
transformation
is
definitely
a
problem
that
I
have
experienced
and
I've
mentioned
others
who
have
experience
as
well.
But
that
being
said,
I
do
know
we're
on
time.
Just
wanted
to
mention
that.
M
F
Other
kind
of
point
that
you
could
look
at
is
the
connection
specification,
which
is
not
like
in
the
spec
per
se,
but
like
relays
connect
how
relay
deals
with
things
types
whose
name
ends
in
connection
is
essentially
creating
a
map
type
that
allows
you
to
paginate
through
it
as
a
map.
F
It's
definitely
more
complex
than
like
a
json
map
in
the
response,
but
it
is
a
handshake
that,
like
the
server
and
the
client
agree,
each
element
in
here
I
can
ask
for
from
the
server
I
can
ask
for
the
next
n
in
this
map,
like
I
can
get
any
one
of
these
by
passing
down
the
cursor
for
a
specific
item
in
the
map,
and
it
might
be
interesting
if
we
could
kind
of
batten
down
what
a
map.
If
we
couldn't
change
the
language.
F
What
would
a
map
generic
type
in
the
sense
of
a
connection,
generic
type
kind
of
look
like
and
is
there
a
way
that
we
could
change
the
language
to
simplify
that
or
make
that
more
clear
and
like
make
it
easier
for
everyone
to
use.
J
E
Yeah
another
way
to
maybe
kind
of
back
up
from
this
is
we
we
got
to
take
ourselves
out
of
the
javascript
world
like
json
json,
I
think,
is
an
easy
thing
to
pin
ourselves
on,
but
even
in
javascript,
it's
really
common
to
think
about
a
map
as
string
keyed,
just
because
up
until
es6
map
types
like
that's
just
the
way
that
javascript
developers
operate,
but
it's
not
necessarily
the
way
that
all
other
languages
do
that
so
and
just
to
say
like
as
as
people
who
are
more
familiar
with
other
languages
approach,
graphql
they'll
bring
their
own
internal
conception
of
what
a
map
is
and
then
be
like
surprised
or
not,
based
on
what
they
find,
how
it
works,
which
I
think
is
like
just
to
kind
of
reinforce.
E
E
We
have
here's
the
relative
importance
of
each
of
those
and
then
here's
the
suite
of
solution,
space
we're
going
to
dive
into
for
each
which
might
be
some
combination
of
post-processing
new
types
patterns,
the
json
type
scalar
or
even
like
recommending
like
patterns
for
people
like
we
might
find
that
the
answer
here
is
is
actually
doesn't
require
any
spec
change.
It's
just
a
matter
of
defining
a
community
standard
and
building
tools
around
that.
E
So
I
think
we
have
a
lot
of
space
to
explore
to
figure
this
out,
but
the
the
sooner
we
can
kind
of
pare
it
down
to
the
set
of
problems
that
at
least
you
as
a
champion,
are
most
interested
in
solving
and
then
make
sure
that
you
have
the
sort
of
the
community's
nod
that
that's
the
right
thing
to
go
into.
Then
I
think
that'll
give
you
a
lot
of
of
fervor
and
you'll
find
the
right
path.
E
Well,
thank
you
both
for
you
now
just
resurrecting
this
work
and
also
yvonne
for
the
heavy
feedback
and
iteration.
I
think
this
is
probably
the
most
valuable
conversation
we've
had
about
map
types,
since
it
was
first
posed
many
years
ago,
so
serious
progress.
B
I
will
also
try
to
share
my
screen.
Can
you
make
to
share
screen.
B
I
created
pr
for
a
description,
an
executive
definition.
First,
we
already
discussed
it
on
previous
working
group.
It
was
back
in
march,
but
back
when
it
wasn't
any
particular
proposal
we
just
have
like.
I
think
we
had
like
an
hour
of
free
time
very
short
agenda,
so
we
decided
to
and
discuss
like
if,
if
anyone
have
proposal
ended
it's
my
proposal
initially,
I
had
it
for
for
very
weird
use
case,
but
since
then
I
learned
it's
not
but
uncommon.
B
It's
actually
like
pretty
popular
use
case
when
you
generate
something
from
your
queries
like
most
popular
one
is
code
generation
and
you
either
generate
a
function
or
a
type
or
something
else
so
in
large
code
bases,
especially
if
graphql
files
live
separately
from
your
codebase.
It
makes
sense
to
attach
some
description
to
queries
and
fragments.
B
B
The
first
version
of
sdl
used
comments
as
description.
That's
why
the
results
see
a
lot
of
confusion
in
ecosystem,
but
since
then
we
settle
up
on
using
like
special
description
with
quotation
mark
before
types,
and
this
proposal
is
to
basically
allow
the
same
for
queries,
fragments
and
query
variables.
B
So
in
my
case,
I
wanted
to
generate
slack
command
from
from
from
a
query
file
and
use
operation.
Description,
as
common
description
and
argument
is
as
common
argument
description.
You
can
do
the
same
with
like
coi
commands
or
code
generation
or
like
a
form
or
a
bunch
of
stuff
and
key
difference
from
a
comments,
description
actually
attached
to
something,
and
it's
explicit.
B
So
if
you
write
instead
of
like
description,
write
comment
here,
it
can
be
like
fix
me
to
do
so
like
it
can
be
accidental
description.
B
I
think
apple
ios
team
or
apple
android.
I
think
a
power
android
team,
using,
I
think,
they're
using
comments
on
operation
to
to
as
description
and
putting
them
in
generated
code,
which
is
not
ideal.
Since
we
want
to
separate
comments
from
description,
so
basically
change
changes
simple.
I
need
to
figure
out
how
to
document
it
properly
in
pr,
for
some
reason
is
stuck
to
us.
B
I
cannot
switch
like
panels
yeah
yeah
working
out,
so
I
changed
like
in
grammar
toward
and
I
did
like
stop
section
to
language
paragraph
and
we
have
same
section
in
type
system
paragraph.
So
it's
we
still
need
to
figure
out
how
to
match
two
in
one,
but
this
is
basically.
B
The
idea
here
is
to
like
recognize
is
if,
if
it's
something
we
want
to
do
or
not
and
we'll
have
like-
and
I
will
start
working
with
the
autograph
kill
js
and
to
two
key
points
like
operation,
fragment
and
query
variables,
and
you
cannot
add
a
description
to
short
form
of
operation.
If
you
use
curly
braces,
you
cannot
add
description
and
it's
like
problematic.
B
It's
make
everything
easier
and
plus
it's
weird,
if
you
add
description
to
something
without
a
name.
So
technically
you
can
edit
without
a
name
you
can
add
description,
inquiry
and
curly
braces
as
well,
but
it's
like
it's
your
own
decision
so
like
for
short
form.
I
think
description
is
don't
make
sense
at
all.
So
any
any
questions
uncle
month.
B
And
yes,
it's
it's
mistake.
It's
actually
artifact
of
like
the
entire
situation
with
comments
and
description
is
sometimes
unconfused
from
time
to
time
and
finally,
we
remove
it
from
graphql
js,
so
we
remove
after
I
think,
like
two
or
three
years.
We
remove
support
from
for
comment
descriptions,
so
it
should
improve
situation.
F
Yeah,
that
makes
sense.
The
only
thing
with
adding
description,
strings
on
argument
are
on
variable
definitions
is
that
it
would
be
very
easy
to
accident
like
it'd,
be
easy
to
screw
up
and
confuse
that
for
a
default
value.
B
But
I
don't
feel
that
strong
for
for
query
variables.
I
still
think
it's
nice
for
the
same
reason,
especially
like
sometimes
query
variables
like
in
a
sense,
maybe
query
variables
are
more
important
than
operation
because,
like
operational
disk
like
because
sometimes
especially
for
skip
include,
you
want
to
document
what
you're
skipping
and
including
so,
and
we
cannot
change
description
format.
It's
already
set.
E
Yeah,
what
it's
worth
this
is
a
it's
a
pretty
clear,
parallel
to
input,
definitions
and
argument,
definitions
in
the
schema
language
right.
They
have
the
exact
same
potential
quark
with
default
values.
F
Should
be
a
like
blocker
on
this,
it's
just
something
we
should
know
or
whatever.
That's
that's
the
only
reason
I
would
find
any
roadblock
block.
In
fact,
for
this.
A
I'm
also
racking
my
brain
trying
to
think
of
problems
that
this
could
introduce.
I
I
really
like
it.
I
think
it's
a
really
good
idea.
One
thing
that
I
thought
of
is
in
descriptions
in
the
schema.
A
I
would
imagine
that
with
with
them
in
the
operation
like
this,
like
a
graphql,
minification
library
could
just
strip
them
out,
just
like
it
could
with
comments
and
with
quite
a
lot
of
white
space,
but
I
do
wonder
whether
anyone
might
at
some
point
try
and
leverage
the
fact
that
you
can
put
extra
detail
there
rather
than
doing
so
with
a
directive,
for
example,
and
cause
problems.
So
I'm
trying
to
think
you
know
do
we
need
to
prevent
people
from
using
this
foot
gun?
A
I
honestly
don't
think
it's
a
big
deal,
but
it's
literally
the
only
problem
I
could
come
up
with.
So
I
think
it's
a
really
good
idea
and
I
think
we
should
add
it.
D
D
B
Game
yeah
key
importance
here.
It's
like
we
have
three
mechanisms.
We
have
comments,
description
and
directives.
If
you
personally
want
to
change
our
behavior,
we
have
directives
like
in
json.
You
don't
have
directives,
so
idea
was
not
to
allow
you
to
do
that
and
we
already
paid
the
price
of
allowing
it
and
like
you,
can
use
what
dash
directive
to
screw
up
location
for
anything.
B
Another
thing
like
people
can
use
description
to
do
client,
specific
stuff
like,
for
example,
I
don't
know
like
you,
have
valid
data
in
your
project
and
you
can
use
description
to
disable
linked
check
on
particular
query,
but
for
it
you
have
comments
so
like
we
already
have
mechanists
to
do
that,
to
abuse
it
both
like
on
the
server
and
on
the
client.
So
I
didn't
like
yet
another
mechanism
that
can
be
useful
at
it's.
It's
not
changing.
A
Situation,
I
think
the
slight
difference
ivan
is
that
typically,
the
comments
would
not
be
represented
in
the
ast
right,
whereas
the
the
descriptions
would
be
so.
If
you're,
looking
at
like
your
resolve
info
or
whatever
in
graphql
js,
for
example,
you
could
look
at
the
ast
nodes
and
actually
pull
in
the
description,
whereas
you
wouldn't
be
able
to
do
so
with
a
comment,
because
it's
not
attached
to
any
particular
node.
B
Yeah
on
what
point
there
is
issue
on
graphql.js
to
add
commands
into
ist,
because
people
actually
need
it
for
for
what
reason
they
needed
to
to
to
provide
some
some
stuff.
That
is
not
description
like
disable
like
in
usda,
you
want
to
disable
validation
and
you
don't
want
it
to
be
part
of
documentation.
B
E
F
N
J
B
J
Just
just
be
a
little
careful,
I
think
I
totally
agree
with
that.
It
wouldn't
affect
the
query
result,
but
it
could
affect
the
server
like
the
server
could
do
different
translation
comments,
depending
on
what
the
comments
are
or
something
I
mean
it
certainly
sends
them
to
to
introspection
requests,
but
they
just
mean
like
it.
J
Could
some
server
could
do
something
with
not
your
comments,
your
descriptions,
but
I
think
I
mean,
if
you're,
okay,
with
saying
the
comment,
the
making
the
note
saying
that
it
shouldn't
affect
the
query
result,
and
I
I
feel
maybe
that's
what
you
already
meant.
E
Yeah,
but
certainly
the
the
point
being
like
it
shouldn't
you
shouldn't
like.
If
you
take
out
the
descriptions,
then
the
description's
gone
so
like.
If
the
server
wanted
to
extract
the
description,
then,
obviously
deleting
it
would
have
some
impact
on
that.
B
E
I
like
this,
this
is
very
aligned
to
one
of
the
the
principles
of
graphql's
documentation
as
a
first
class
concept.
So
I
think
it's
it's
highly
aligned.
B
Cases
here
so
nobody
opposed
to
moving
it
stage.
One,
and
I
will
work
for
for
reference
implementation
next
working
group.
I
can,
I
think
we
can
do
like
move
it
stage
by
station.
Every
working
group
shows
so
it
will
be
pretty
fast.
B
Yeah,
so
anything
else
before
we
switch
to
second
topic.
B
Go
for
it
okay,
so
there
is
like
two
use
cases
and
one
solution.
I
had
only
one
problem
and
recently
it
today
ago
it
was
raised
another
issue,
so
I
will
start
by
not
my
proposal.
No,
no,
not
my
use
case
so
jacob
from
graphql
to
his
maintenance,
graphql
tools
and
he
contributed
pr
to
graphql.js
to
allow
you
to
return,
multiply
errors
from
from
a
resolver
and
he
did
all
the
implementation.
B
I
I
just
was
a
concern
that
it's
bad
to
have
errors,
multiple
errors,
having
the
same
location
or
the
same
path.
It's
confusing
and
it's
bad
developer
experience
and,
as
especially
problematic
in
his
implementation.
He
used
aggregated
error,
a
new
new
addition
to
acmascar
to
javascript
and
aggregated
error.
Allow
you
to
provide
list
of
errors,
array
of
errors
and
description.
B
So
basically
you
have
a
grouping
and,
like
you
have
you
have
some
description
attached
to
that
grouping
so
by
just
putting
them
flat
and
errors,
we're
creating
multipliers,
pointing
to
the
same
location,
which
is
correct
in
current
version
of
a
spec.
I
just
think
it
will
be
confusing
for
any
any
tooling
try
to
show
it.
B
I
did
not
try,
but
I
expect
like
some
of
the
tools
like
graphical:
don't
handle
it
very
well,
if
you
point
to
a
couple
errors
in
the
one
location
and
second
thing
using
this
grouping
attribute,
you
don't
understand
that
we
service
one
group
and
you're
using
like
common
common
message.
B
So
motivation
for
this
is
the
same
as
like
for
help
for
having
for
grouping
errors
in
the
first
place
so
basically
like.
If
you
do
some
kind
of
like
parallel
execution
or
if
you
do
like
complex
validation,
when
you
cannot
figure
out
what
the
primary
validator
validation
criteria
so
yeah
don't
want
to
exit
pages
because
we
will
see
whole
screen.
So
so,
what's
yeah
yeah
eric
close
yeah,
I
initially
linked
it.
B
Error
calls
is
for
chaining
errors.
Only
so
you're
not
allowed
to
do
white.
You
can
only
go
deep
there
and
that's
why
it's
called
course.
B
And
I
choose
like
why
because
causes
for
me,
it
sounds
like
strange
so,
and
I
still
not
sure
about
the
name
is
on
the
discussion
and
second
use
case
is
like
exactly
a
slip,
went
out.
It's
like
for
chaining,
so
right
now
in
graphql
js,
we
return
you
error,
saying
quite
particular
scour
who
scoured
this
particular
name.
B
B
B
It
was
my
initial
use
case
for
for
that
proposal,
but
I
didn't
thought
it's
like
strong
enough
to
motivate
new
change,
but
second
use
case
is
more
appealing
even
more
appealing
and
in
in
javascript,
since
we
already
have
aggregated
errors,
people
added
error
calls
as
like
second
mechanism.
B
I
think
we
can
do
it
with
one
field:
key
difference
of
a
y
field.
Why?
Why
is
different?
Is
it's
not
recursive?
So
inside
array
it's
not
errors.
It's
like
simply
simplified
errors.
B
My
proposal
is
to
is
to
limit
them
to
only
message,
an
extension
for
now.
Maybe
later
we
figure
out
something
else.
We
need
there,
but
it
would
be
weird
if
we
have
error
pointing
to
particular
location
and
somewhere
pointing
to
different
location.
Another
thing
why
it's
not
errors,
because
errors
implies
recursive,
I
don't
want.
I
feel
it's
hard
to
provide
good
developer
experience
or
good,
like
ui,
if
you
want
to
present
with
error
to
user.
B
If
you
have
like
recursive,
if
you
can
have
like
one
chain,
so
basically
it's
limit
to
one
or
one
layer
yeah.
I
think
it's
a
little
bit
harder
than
description,
but
also
pretty
simple
proposal.
One
thing
I'm
the
same
as
previously,
I'm
like
totally
okay
with
by
shading
about
name
and
like
there's
some
restriction.
E
E
B
B
B
So
for
me
you
need
to
like
try,
but
what
happened
in
graphql
js.
We
have
like
error
from
graphql
js
itself
and
error
from
client
code,
so
there
is
no
way
to
present
both
without
concatenation,
and
so
I'm
with
this
proposal.
I'm
solving
that
issue
and
I
think
clients
should
try
as
much
as
possible
to
to
also
do
the
one
like,
like
concatenation
joining
and
in
future.
If
people
present,
we
can
allow
some
changing.
B
But
one
thing
I'm
totally
against
is
to
what
problem
of
cause
is
it's
a
chain
to
error,
so
it
change
to
something
that
can
have
the
same
attributes
like.
If
we
have
occasion
it
should
be
location.
Only
on
top,
if
we
have
path
for
error
inside
resolver,
we
should
have
like
it
only
on
top
level.
So
in
future,
I'm
okay,
if,
like
somebody,
come
with
use
case
to
evolve
to
deeper
chaining
and
just
think
it
should
be
like
simplify
theirs
or
like.
Why
causes
or
like
something
else,
is
it
recursive.
A
Just
as
a
slight
challenge
to
what
you
just
said
ivan
in
the
situation
where
you
say
that
a
bunch
of
fields
on
a
type
are
non-nullable
and
then
say
all
of
them
or
like
three
of
them,
come
through
as
null
that
would
be
represented.
I
think
I
can't
quite
remember
that's
represented
as
an
error
on
the
field
that
ultimately
becomes
the
null
placeholder
right,
the
the
the
shorter
path
length.
A
A
B
E
B
B
So,
even
if
there
is
like
use
case
for
for
doing
stuff
like
that,
it's
it's
like
confusing
how
you
visualize
it
it's
stuff
like
graphical
or
id,
or
something
else.
J
B
Feedback
on
feedback
on
that
we
have
like
built,
schema
function
and
it's
acceptable
and
it's
produce.
B
Error
and
wither
contain
new
line,
so
it's
contained
bunch
of
new
ones
and
it's
very
hard
to
read.
So
it's
it's
contradict
like
developer
experience
thing
my
main
concern
here,
it's
like:
if,
if
we
do
one
string,
what
we
do
right
now,
one
string
with
semicolons,
for
example,
or
new
lines,
it's
hard,
usually
it's
represented
as
a
string
in
json
or
like
in
another
format
best
we
discuss
like
we're,
not
tied
to
json
like
xml
or
anything
for
a
person.
B
E
It
makes
sense
to
me
that,
because
I
definitely
hit
the
point
of
you
know,
making
something
most
reasonable,
and
this
shouldn't
be
a
crutch
to
make
the
rolled
up
message
less
useful,
but
especially
when
it
comes
to
reporting
errors.
Having
as
much
information
as
possible
seems
like
it's
always
a
good
thing,
and
especially
if
the
puck
is
going
in
the
direction
of
aerochains
and
aggregate
errors
and
all
these
other
ways
in
the
actual
programming
language
ecosystem
to
model
the
complexities
that
raise
errors,
then
us
being
able
to
serialize.
E
B
E
Awesome
well,
this,
I
think,
is
worthy
of
stage.
One
seems
compelling
I'd
be
very
curious
to
see
if
there's
some
like
out
of
the
box
value
that
we
get
like
if
you
start
working
on
the
the
graphical
js
side,
pull
request
and
have
some
examples,
they
exemplify
this
that'll
really
help
us
understand
the
kind
of
value
that
we're
going
to
get
and
then
and
tweak
from
there
but
yeah.
This
is
great
thanks
for
work
on
this
salon.
E
That
is
the
last
agenda
item
we
have
and
we
it
literally
just
rolled
over
to
the
hour
so
holy
crap.
We
we
did
it.
We
got
through
the
entire
agenda
in
exactly
the
time
allotted.
I.
E
Congrats
most,
this
is
the
most
efficiently
and
effectively
run
meeting
I've
been
in
all
week,
yeah
all
right
thanks
everybody.
This
has
been
a
pleasure
very
excited
to
see
all
the
ongoing
work
very
much
appreciate
everybody's
energy
and
and
work
between
the
meetings.
It
shows
we're
moving
forward
on
a
lot
of
things
at
once.
It's
really
great
to
see.
So,
thank
you
all
and
I'll
see
you
all
again.
Next
month.