►
From YouTube: GraphQL Working Group - December 5, 2019
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
Coming
up
later
this
this
month,
we've
got
a
pretty
solid
agenda
today,
lots
of
good
stuff
to
talk
through,
but
first
as
we
always
do,
let's
go
around
and
introduce
ourselves
that
way
everyone
can
put
names
to
faces
so
that,
while
we're
in
discussion,
we
know
who
everybody
is
we'll
go
through
in
the
order
listed
on
the
agenda.
B
C
Hello,
I'm
victor
and
I'm
representing
advents
and
issue
at
the
final
end
of
the
agenda.
D
Hello,
this
is
anton
way
I
work
on
aws
appsync
and
I'm
from
amazon
and
interested
in
old
old
legend
iodines.
E
Place
from
apollo,
I'm
hugh
wilson,
a
core
dev
with
apollo
nice
to
see
you
and
talk
to
everybody.
B
Sorry
about
the
mix-up
go
ahead
and
send
up
a
request
with
your
name
again
I'll
make
sure
it
gets
merged
for
sure.
Thanks
lee
yep.
F
I
don't
think
michael
or
russell
are
here
yet
I
hope
they
join
later
on.
My
name
is
fosgot.
It's
the
first
time
I
attend
the
meeting.
F
H
Hi,
my
name
is,
and
I
work
mostly
on
graphql
js
and
help
with
other
projects,
and
I
accidentally
login
on
the
graphql
foundation
account.
So
I
will
disconnect
and
connect
back
under
my
personal.
I
Sorry
yeah,
I'm
probably
not.
I
work
at
hofstra
graphql
engine.
This
is
my
first
meeting.
I'm
just
excited
to
this
power
space.
J
K
See
is
mike
here,
mike's,
not
here
yet
all
right.
Well,
I
am
I'm
stephen
and
I
work
at
netflix.
L
Hey
folks,
I'm
vince
I
work
at
new
relic
and
I'm
a
maintainer
of
the
absinthe
elixir,
graphql
library-
and
this
is
ada
down
here.
A
N
Hello,
I'm
greg.
I
work
for
intuit.
I
contribute
to
graphql
java
journal
of
the
graphic
registration
at
intuit
and
now
we
are
planning
to
open
source
our
into
equation.
B
I
think
we
got
everybody.
I
see
that
there's
already
some
action
happening
in
the
notes
file,
which
is
amazing.
B
B
B
Today,
go
I'll
take
silence
as
confidence.
Let's
take
a
quick
look
at
the
previous
meetings,
action
items
and
currently
open
items
and
see
if
there's
anything
here
we
need
to
address.
B
Oh,
I
think
the
primary
issue
here
that
is
still
open
on
me
is
to
go
back
through
all
previous
meetings.
Many
previous
meetings,
action
items
that
are
still
open
and
translate
them
all
to
github
issues,
so
I'll
actually
do
that
today,
I'm
gonna
do
that
today,
but
otherwise
looking
at
these
other
previous
action
items,
oh,
I
think
the
only
other
one
that's
still
open
is
having
a
draft
plan
for
freezing
release.
H
As
a
suggestion,
maybe
maybe
we
can
like
delegate
some
stuff
to
other
people
like
involve
like
volunteers
into
into
some
stuff,
like
actually
like
going
through
previous
action
items.
It
can
be
done
by
somebody
also,
maybe
somebody
volunteered
for
it.
If
anybody
is
interested
in
helping
with
that,
that
would
be
amazing.
H
Maybe
I
didn't
like
help
wanted
on
action
items
would
be
a
great
idea
because
I
think
like
in
one
term,
we
need
to
distribute
what,
especially
like
for
things
that,
like
you
know,
bureaucracy,
think
of
maintaining
processes.
B
I
totally
agree.
Well
let
me
take
this
first
step
of
moving
everything
into
action
items
I'll,
do
that
today
I'll
do
it
right
after
a
meeting
actually
and
I'll
go
through
as
many
as
possible
and
mark
them
help
wanted.
B
All
right,
let's
move
on,
let's
take
on
our
first
agenda
item
of
the
day,
because
I
anticipate
we'll
we'll
spend
a
fair
amount
of
time
on
it.
Evan
and
andy
I'll
hand
it
over
to
you
guys.
Evan
do
you
want
to
get
us
started.
A
Yeah,
excuse
me
absolutely
so
we
have
sorry
tabs
right
at
the
last
meeting.
A
We
kind
of
talked
through
the
basics
of
the
custom
scalar
specification
since
then
andy
and
I
have
put
together
a
proper
rfc,
a
proper
pr
to
change
the
spec
with
all
of
the
changes,
and
so
there
are
just
a
few
things
left
to
talk
about.
The
first
thing
that
I
wanted
to
ask
about
is
this
current.
A
The
rfc
currently
proposes
a
new
standard
directive
as
part
of
the
spec
and
plausibly
like
that
is
technically
a
breaking
change
if
there
are
schemas
that
exist,
which
already
use
that
directive
name
for
something
else.
A
So
I
wanted
to
kind
of
pull
the
the
group
here
to
know.
If
well
a
is
there
any,
are
there
any
schemas
in
the
wild
that
we
know
of
that
would
be
broken
in
this
way,
and
then
I
guess
also
figure
out
a
little
bit.
How
do
we
want
to
handle
this
sort
of
thing
going
forward?
Do
we
want
to
say
that
we
can
just
add
more
directives
to
this
back
at
any
time,
or
do
we
need
to
have
a
bit
more
of
a
process
around
that.
A
H
D
Maybe,
as
I
don't
know,
if
it's
I'm
reading
the
the
notes-
but
maybe
it's
been-
if
it's
been
suggested
already
sorry
about
that,
but
maybe,
as
we
could
put
in
spec
that
if
any
implementation
or
developer
as
a
directive
that
as
a
best
practice,
they
should
add
like
a
namespace
like
a
prefix.
That's
what
we
do
for
the
directors
that
we
we
add
on
top.
So
there's
no
there's
no
breaking
change.
If
the
spec
were
to
introduce
some
directives,
I
don't
know
that's
just
just
an
idea.
A
A
B
We
I
don't
know,
thoughts
on
that
yeah.
It
doesn't
have
to
be
a
formal
rfc.
I
don't
think
especially
if
it's
just
sort
of
like
we're
searching
the
crowd
here
for
some
best
practice,
wisdom
and
what
we
hope
people
will
do
with
directives.
A
Cool
antoine
is
that
something
you
want
to
tackle,
or
this
is
your
idea
yeah.
I
could
add
that
yeah.
A
Well,
that
was
an
easy
way
to
address
that
one
issue,
the
only
other
thing
I
actually
wanted
to
talk
about
since
we
covered
a
lot
of
the
more
detailed
stuff
at
the
last
meeting
was
if
people
have
had
a
chance
to
read
through
the
rfc
and
read
the
photographs
on
the
spec
changes
do.
Does
everybody
agree
that
we're
ready
to
move
to
stage
two
and
call
this
undrafted
rc?
At
this
point.
A
No,
I
don't
speak
javascript,
and
so
I
won't
have
to
ask
for
help
from
the
community
for
that
one.
F
H
H
One
issue
I
want
trace:
it's
not
like
rfc
itself,
just
examples
on
rfc,
I'm
kind
of
so
it's
not
the
book
stage.
Two,
I'm
part
totally
okay
for
stage
two,
but
an
examples.
I
saw
some
discussion.
I
did
have
time
to
read
for
enjoy
discussion,
but
it's
like
give
links
to
rfc
directly
so
like
rfc
for
urls
is
pretty
complex
and
rfc
for
daytime
really
complex.
So
if
we
just
referencing
them,
we
still
a
lot
of
freedom
of
implementation.
H
It's
not
like
we
narrowing
down
like
url
and
daytime
from
a
string
to
something,
but
they
see
like
pretty
big
something.
So,
as
we
discussed
like
presley
with
daytime
idea,
was
to
have
a
document
saying
some
document
between
rfc
and
like
like
saying
we
don't
support
like
entire
entire
rfc.
We
support
some
subset
of
rfc
and
I
think
something
similar
makes
sense
for
euro
and
other
complex,
complex
rfcs.
A
Andy-
and
I
talked
about
this
a
little
bit-
we
don't
want
to
block
this
part
of
the
rfc
on
having
all
of
these
sub
scalar
specifications
right
now.
So
maybe
we
just
need
to
find
better
examples
than
that
where
we
can
reference
an
existing
rfc
with
an
existing
stack
for
these
a
better
example
scalar
without
without
running
into
this
issue
in
the
short
term,
but
I
don't
know
what
examples
to
use
for
that
case.
So
suggestions
are
welcome.
I'll,
do
a
little
digging,
if
not.
H
B
I
just
want
to
say
I
think
your
examples
are
reasonable
and
I
think
it's
totally
reasonable
to
I
mean
I,
I
we've
talked
about
daytime
on
and
off
for
a
long
time,
but
I
actually
really
like
pointing
directly
to
an
ietf
rfc,
because
it
makes
it
clear
that
the
spec
doesn't
have
to
be
a
custom
thing
and
it
doesn't
have
to
be
a
graphql
specific
thing.
So
I
really
like
that
aspect
of
it.
B
I
hope
you
don't
lose
it
and
I
think
that
especially
the
daytime
one,
the
3339
one,
is
actually
pretty
crisp
and
I
don't
know
that
we
would
subset
it
much
if
at
all,
and
it's
probably
pretty
rare-
that
people
subset
that
spec
in
their
own
code
bases.
I
I
can't.
A
B
M
Can
I
ask
one
question
about
like
where
this
started,
and
now
where
it
is,
it
seems
like
this
was
initially
suggested
as
like
a
url
like
permitted
type.
But
then
we
it
got
morphed
into
like
the
at
specified
directive,
and
I
wonder
if
it
still
solves
the
goals
that
were
listed
in
the
problem.
Just
where,
like
specifically,
the
second
bullet
point
talking
about
how
like
client
tools
would
be
able
to
introspect
this.
M
I
wonder
if
by
using
like
the
the
buy
url,
if
that's
at
all,
problematic
like
if
one
person
implements
it
with
http
versus
https
and
the
urls,
and
how
clients
would
be
able
to
introspect
that,
I
think
it
definitely
helps
a
lot
with
the
documentation
side
of
things.
And,
if
that's
the
current
goal
of
this,
I
think
that
makes
a
lot
of
sense.
But
I
just
wanted
to
make
sure
that,
since
it
did
more
that
we're
still
solving
the
problem
that
it
was
initially
trying
to.
B
I
think
that
it
does.
I
think
that
that
was
only
a
syntactical
shift
that
but
correct
me
if
I'm
wrong
evan,
but
the
introspection
change.
The
introspection
didn't
change
at
all
when
you
shifted
from
putting
a
url
directly
in
line
versus
changing
it
to
a
directive.
Is
that
right,
that's
correct!.
A
I
think
I
might
have
tweaked
the
field
name
a
little
bit,
but
that's
not
a
big
deal
yeah.
As
far
as
like
the
fluidity
of
the
url
and
the.
A
I
mean
yes,
but
I
don't
think
there's
anything
we
can
use
to
identify
a
plus
a
specification,
that's
any
more
precise
than
a
url.
At
this
point
I
mean,
hopefully,
people
use
https
and
don't
tack
on
weird
anchors
and
and
just
kind
of
put
a
base
url
in
there
and
then
and
even
if
they
don't,
then
it
won't
work
with
the
tools
that
I
assume
that's
the
url
they're
going
to
see,
and
so
you
know
that's
the
problem.
B
I
also
think
in
practice
what
is
likely
to
happen
with
this
is
you'll
have
a
handful
of
very
popular
tools
that
advocate
for
specific
cases
that
they
support.
So,
for
example,
you
could
imagine
that
the
apollo
client
would
say
that
if
you
say
that
you
have
a
type
called
date
or
date
time
or
call
whatever
you
want,
but
as
long
as
it
says
that
it
is
specified
by
rfc
3339
then
like
magically
it'll,
show
up
as
date
objects
in
your
javascript
code.
B
Then
that
will
incentivize
people
to
to
do
that
right
and
if
they
put
in
http
instead
of
https,
all
of
a
sudden
it
breaks,
then
they'll
notice
and
they'll
go
fix
it.
So
if
clients
all
disagree
on
http
or
https
and
we've
got
a
bigger
problems
on
rans,
which
hopefully
that
won't
happen,
but
I
expect
that
in
practice
that's
likely.
B
What
will
happen
is
that
we'll
have
sort
of
a
pool
of
tooling
that
all
sort
of
agrees
on
a
handful
of
the
most
common
ones,
and
then
people
will
go
in
and
customize
from
there
with
their
own
supported
ones.
That's
kind
of
what
I
expect
will
probably
happen.
H
I
also
want
to
ask
like
for
confirmation,
like
last
time,
we
discussed
this
issue.
We
also,
if
I
remember
correctly,
we
agreed
that
graphql.js
as
a
reference
implementation,
also
for
it
also
to
make
sense
to
contain
some
scholars
like
daytime
and
other
so
like
what
would
we
procedure
for
for
accepting
like
new
scholars
into
reference
implementation,
because
it?
Actually
it's
actually
like
some
in
some
sense,
it's
it's
like
approving
this
cover,
maybe
not
including
the
spec,
but
at
least,
while
proving
through
reference
implementation.
A
Question
that
I
haven't
thought
too
much
about,
I
think
I'd
like
to
kind
of
handle
that
separately
and
just
for
now
not
accept
any
scalars
into
the
graphical
js
like
that
and
wait
and
see
a
little
bit.
What
comes
out
of
the
community
and
like
what
because
there's
like
there's,
also
like
what
scalars
does
graphical
support
is
also
some
another
way
that
we
can
kind
of
quasi-bless
particular
implementations,
and
I
want
to
be
careful
with
that,
because
it
really.
A
H
H
B
Yeah,
I
think
it
would
be
reasonable
in
the
in
any
documentation
in
graphical
js
to
mirror
the
same
examples
that
are
in
the
spec.
So
you
know,
if
you
say
like
hey,
if
you
want
to
use
this,
here's
an
example
of
how
you
could
use
it
with
a
date,
and
then
you
can
use
the
exact
same
example.
That's
listed
in
the
spec.
B
I
think
that's
reasonable,
but
I
agree
we
might
want
to
just
like
wait
a
little
bit
with
supplying
an
out
of
the
box
date
type
that
already
uses
this
just
to
avoid
the
can
of
worms
that
that
evan
is
talking
about.
B
But
in
order
of
how
we
get
there,
I
think
that's
a
good
question.
I
think
we
want
a
warranted
like
dedicated
discussion
to
that,
especially
since
I
know
andy
cares
a
lot
about
this
and
and
he
hasn't
been
able
to
make
the
last
couple
of
meetings.
So
we'd
probably
want
to
talk
it
through
with
him
and
figure
out
what
we
want
to
do
there.
B
But
it
is
pretty
clear
that
at
some
point
we
will
have
to
come
to
some
consensus
on
one
that
we
want
to
start
supporting
and
tooling,
and
it
doesn't
have
to
be
the
only
one
like
there
could
be
two
or
three
that
we
end
up
supporting
for
variance
of
date,
but
at
some
point
we'll
figure
that
out,
but
it
doesn't
have
to.
I
don't
think
we
would.
We
would
block
this
particular
rfc,
advancing
stages
on
that
yeah.
I'm
great.
A
All
right
are
there
any
other
questions
or
any
other
concerns.
I
will
take
silence,
as
this
is
ready
to
go
to
stage
two.
B
I
think
having
a
having
working
changes
in
the
reference
implementation
is
criteria
for
stage
two,
but
beyond
that
all
looks
good
I'll
file
the
ticket
then,
and
we
can
move
that
along
cool
and
we
can
advance
to
stage
two
outside
of
working
group
meetings.
Since
that's
the
last
remaining
piece
and
the
reason
that
it's
an
important
criteria
is
that
it's
always
possible
that
you
stumble
on
some
implementation
detail
that
ends
up
being
weird.
That
reminds
you
of
something
that
you
didn't
think
about
when
you
were
just
writing
spec
text.
B
In
this
case,
this
rfc
is
simple
enough
that
I
think
that's
unlikely,
but
it's
still
probably
a
good
idea
to
make
sure
that
the
rfc
is
in
or
that
the
pull
request
to
the
reference
implementation
is
in
good
shape.
First
yeah.
A
M
A
Yeah
I'll
file,
the
ticket
and
I'll
ping,
you
an
item
and
you
can
sort
it
out.
I
mean.
B
Cool
all
right,
moving
on
vince
I'll
hand
it
to
you.
L
Great,
so
I
put
a
link
to
the
input
union
dock
in
the
chat
and
it's
in
the
notes.
It's
gotten
a
bunch
of
work
in
the
last
few
weeks,
lots
of
emojis
which
have
helped
give
it
some
structure
and
we
started
doing
evaluations
of
the
various
criterias
and
solutions.
L
So
there's
a
little
like
color
coded
system
for
that
and-
and
you
can
see
where
the
where
we
stand-
sort
of
with
the
various
criterias
and
the
various
solutions-
and
I
think
our
goal
with
that
was
basically
like-
let
anything
in
and
evaluate
it,
even
if
it
may
or
may
not
be
become
a
requirement
for
the
eventual
solution.
L
So
some
of
these
criteria
kind
of
are
mishmash
some
past
all
of
them
past,
some
of
them
most
of
them
sort
of
don't
pass.
L
But
I
I
encourage
folks
to
take
a
look
through
here
and
and
soak
some
of
that
in
I
added
two
new
criteria
to
try
and
push
things
a
little
further
along.
They
both
have
to
do
with
backwards
compatibility,
so
it
seems
like
there's
kind
of
two
spaces
in
which
we
haven't
covered
that
may
pro
where
problems
might
arise.
If
we
make
any
changes
to
the
sdl,
we
would
want
those
changes
to
be
backwards
compatible
with
existing
sdl
parsing.
L
So
if
there's
like
some
funky
new
syntax
and
all
of
the
existing
tools
start
breaking,
that's
like
a
bad,
a
bad
deal
and
similarly
with
any
changes
that
might
have
to
happen
to
the
introspection
result,
we
don't
want
that
to
you
know,
break
existing
tooling,
especially
graphical,
so
maybe
it
doesn't
adopt
the
new
capabilities
until
the
code
is
updated
to
reflect
that,
but
we
wouldn't
want
existing
stuff
to
straight
up
break.
L
So
so
those
criteria
have
been
added,
they
haven't
been
evaluated.
Yet
I'm
hoping
folks
can
help
kind
of
think
that
through
hopefully,
we
can
simulate
that
without
necessarily
like
doing
full
implementations
of
each
of
the
solutions.
So,
like
maybe
wire
up
a
dummy
introspection,
result
and
toss
it
into
graphical.
L
What
this
kind
of
pushes
us
to
do
is
think
a
little
bit
more
about
fourier
the
various
solutions.
What
would
the
introspection
and
the
sdl
changes
really
look
like?
We
have
examples
of
kind
of
the
stl
and
kind
of
the
query
in
in
the
doc,
but
we
haven't
really
started
thinking
about
what
that
means
for
the
introspection.
L
Necessarily.
So
that's
like
an
area
where
folks
who
want
to
help
push
this
forward
could
start
contributing.
L
L
So
so
those
are
the
if
folks
get
a
chance
to
take
a
look
at
the
doc.
Now,
there's
been
a
good
amount
of
work
and
I'm
hoping
folks
can
help
contribute.
L
And
then
we're
kind
of
getting
into
the
stage
where
we
can
really
think
more
deeply
about,
like
which
of
these.
These
solutions
are
really
on
the
table.
L
So
that's
kind
of
the
state
of
things.
I
guess
I
want
to
open
it
up
with
the
hope
that
we
can
get
action
items
and
think
about
how
we
move
it
to
the
next
stages
or
to
any
stage.
I
guess
in
the
spec.
B
This
is
a
dramatic
improvement
over
the
last
month,
especially
the
like
crosswise
evaluation
makes
it
much
much
easier
to
read.
K
Yeah,
I
agree
the
you
know
the
the
ideas
from
previously
to
to
do
like
the
letter
numbered.
You
know,
criteria
and
solutions.
This
yeah.
This
definitely
shows
that
that's
super
useful
for
people
getting
up
to
speed
with
with
all
these
solutions
that
have
a
lot
of
nuance,
and
you
really
see
that.
Obviously,
when
you
look
at
the
chart
and
see
that
there's
trade-offs
with
all
of
them
now
one
thing:
that's
not
immediately
obvious
to
me
when
I
look
at
the
criteria
is,
which
ones
are
most
important.
L
K
L
That
yeah
I've
had
similar
thoughts
and-
and
I
was
kind
of
at
one
point
pushing
to
like
remove
some,
because
I
didn't
think
they
were
important.
But
I
got
pushed
back
on
that
and
I
think
using
the
results
of
the
evaluation
can
help
us
inform,
which
ones
we
put
in
kind
of
like
a
should
or
a
must
kind
of
category.
L
B
B
Of
course,
how
we
ever
decide
on
what
that
stack,
ranking
is,
could
alone
be
like
another
total
rat
hole.
So
I
don't.
I
don't
want
us
to
like
burn
time
on
that,
but
I
wonder
if
there's
something
slightly
more
coarse,
that
would
be
much
easier
to
agree
upon
that,
maybe
to
follow
on
your
idea
of
the
like
shoulds
or
must
sort
of
thing,
but
changing
the
vernacular
a
little
bit.
B
Maybe
if
there's
like
a
a
category
of
these
they're,
just
like
broadly
agreed
upon
just
like
everyone
agrees
that,
like
these
are
critical
like.
If
you
didn't
have
these
like
this,
wouldn't
be
worth
doing,
and
then
you
could
have
just
another
set
they're
like
controversial
yeah
and
then
that
way
at
least
there's
the
course
ones,
and
I
don't
know.
L
So
one
thing
I
I
got
on
an
emoji
kick
here
and
there
are
gold,
silver
and
bronze
medals
that
I
could
use
to
designate
the
like.
If
we
come
up
with
three
tiers-
and
we
just
give
those
names,
then
we
can,
you
know
at
a
glance
see
like
uh-oh.
We've
got
like
two
gold
criteria
failing
across
the
board.
L
Probably
need
like
some
more
tangible
words
associated
with
those,
but
but
for.
L
K
Love
it
if,
if
we
wanted
to
get
all
mathematical
with
the
evaluation,
then
from
like
a
gold,
silver
bronze,
for
example,
we
could
you
can
apply
weights
to
the
criteria
and
use
something
like
a
decision.
Matrix
is
it's
a
concept?
That's
that's
used
in
some
some
industries
to
to
make
decisions
like
this,
and
basically
you
you,
you
put
all
this
in,
and
you
get
a
score
for
for
every
for
every
potential
solution.
L
H
I
personally
think
it
should
be
like
two
stage
so
right
now
we
like
brewing
stage
we
like
adding
everything
to
his
pack
and
to
rfc
and
when
it
should
be
deceiving
stage,
so
we
should
like
distill
it
down
so
like
maybe
unify
some
criteria
or
even
like
to
find
out.
Some
criteria
is
not
really
one
so,
but
like
one
thing,
I'm
worried
about
is
like.
Currently
it's
like.
H
We
don't
need
consensus
on
anything
because
we're
just
saying
stuff,
so
I
can
allow
myself
to
miss
some
rfc,
because
I
know
like
nobody
like
more-
was
removing
anything
people
just
editing
stuff
for
watching
for
later
phases
for
later
discussion.
If
we
start
ranking,
ranking
stuff,
we
kind
of
need
consensus,
which
slows
down
things,
so
I
would
suggest
like
finishing,
adding
like
everything
and
when
switching
to
like
distilling
mode
and
discussing
criterias,
but
to
make
it
like
separate
stages
because,
like
for
second
stage,
we
need
consensus.
H
B
I
agree,
I
think,
what
we
should.
I,
like
the
gold
silver
bronze
thing.
I
think
it
I'm
totally
comfortable
with
that
being
vince's
opinion
at
this
point,
just
in
the
matter
of
adding
some
clarity
and
being
out
add-only
and
moving
quickly.
B
You
can
consider
that
part
of
the
same
phase
of
information
gathering,
if
there's
really
contention
over
whether
something
has
been
marked
silver,
but
should
have
been
bronze
we'll
deal
with
that
later.
But,
like
again,
I
think,
as
as
vince
already
pointed
out
in
this
document,
particular
passing
and
failing
is
is
not
the
final
word
here.
This
is
just
purely
information
gathering
and
trying
to
help
us
lead
towards
making
some
kind
of
decision,
and
even
you
know
I
look.
I
like
the
idea
of
like
a
decision
matrix
weighted
score.
B
It
doesn't
mean
that
we'll
use
that
to
decide
on
what
we're
gonna
do,
but
it
is
helpful
to
like
look
at
this.
You
know
five
by
n
grid
and
be
like
okay.
How
does
it
add
up
and
if
there's
some
quality
of
the
score,
then
you
can
at
least
look
at
that
and
disregard
it
or
treat
it
with
some
amount
of
weight.
L
G
Totally,
we
also
need
to
evaluate
some
of
the
standard
solution
criteria
as
well
like
the
backwards
compatibility
performance
as
a
feature
and
the
rest,
and
I
think
some
of
those
particularly
things
like
performance
is
a
feature-
are
kind
of
hard
to
evaluate
at
this
stage,
they're
really
important,
but
without
implementations
we
can't
measure
them
and
it's
just
sort
of
opinion
really
or
guess
work.
B
I
think
there's
two
problems
there.
One
is
about
document
clarity,
so
vince
helpfully
listed
out
the
guiding
principles.
That's
what
you're,
referring
to
here
right
yeah,
then
there's
the
solution
criteria
that
are
all
lettered.
So
maybe
what
would
be
interesting
is
listing
the
specific
letters
that
apply
to
that
guiding
principle.
B
So
performance
is
a
feature,
is
a
guiding
principle,
but
then
there
is
actually
one
down
in
here
somewhere
l
input
union
should
be
performant
for
servers,
so
you
could
see
that
l
comes
after
that
one
and
then
that
would
make
it
clear
that
we
do
actually
have
a
solution
criteria
that
has
been
guided
by
that
guiding
principle.
B
The
and
the
second
one
I
think
more
more
tactically.
What
you're
asking
about
is
how
like
for
performance?
How
would
we
even
know
without
building
something?
Certainly
we
can
do
some
like
back
of
the
napkin
sort
of
analysis,
like
understanding.
If
something
is
a
of
one
problem
versus
o
of
n
problem
is,
is
already
somewhat
helpful,
but
then
knowing
if
that's
a
meaningful
difference
versus
an
not
meaningful
difference
is
tricky.
B
So,
if
they're,
if
we
want
to
get
real
with
it
and
and
we
we
probably
can,
especially
if
we're
going
to
land
on
something
like
that
as
being
important,
we
could
build.
B
You
know,
like
demo,
runs
essentially
write
the
smallest
bit
of
code
that,
whether
it's
like
a
pull
request
against
an
existing
graphql
implementation
or
something
relatively
similar
enough
and
then
put
extreme
cases
into
it
and
then
measure
them
so
that
we
know
that
like.
Oh,
then,
oh
yeah,
this
one's
of
n,
however
the
largest
like
reasonable
one
is,
you
know
you
input
union
with
300
or
a
thousand
different
features,
and
then
it
takes.
B
You
know
if
it
takes
100
milliseconds
to
run.
That's
probably
bad.
If
it
takes
a
tenth
of
a
millisecond
to
run,
that's
probably
fine,
and
so
we
can
actually
just
write
a
bit
of
code
to
to
try
that
out.
Well,
it's
not
perfect,
you
know,
but
it
might
at
least
give
us
some
order
of
magnitude
to
understand
where
things
might
lie.
A
A
L
B
Yeah
yeah
totally,
that's
why
I
I'm,
I
think
you're
both
right,
vince,
you're,
totally
right
to
point
out
that
it's
it's
not
the
like.
B
Here's
a
note
for
implementers
if
this
ends
up
being
the
path
that
we
take,
so
that
kind
of
information
is
incredibly
valuable,
so
we
should
still
continue
to
collect
that
and
it
could
I
mean
you
might
be
right.
It
could
be
that
one
of
these
actually
has
a
a
particularly
terrible
performance
hit
in
some
odd
or
extreme
case
that
we'd
want
to
know
about.
A
B
One
nuance
I
do
want
to
add
to
that
is:
I
want
to
create
a.
I
want
to
make
sure
that
we're
zoomed
in
on
the
appropriate
resolution
of
of
what
that
criteria
means.
More
specifically,
what
I
mean
is
because
we're
looking
at
this,
as
you
know,
even
in
the
worst
case,
these
are
probably
going
to
have
fairly
acceptable
performance,
which
means
that
they
shouldn't
all
get
green
checks
except
ones
like
maybe
yellow
you
know.
Actually,
maybe
they
should,
but
anyway,
we
should.
B
We
should
be
able
to
see
which
one
of
these
is
guaranteed,
that
the
best
performance
which
one's
likely
to
have
the
worst
and
then
understand
exactly
what
that
means.
I
think
the
reason
why
we're
highlighting
it
is
bronze
is
that
we
expect,
or
the
reason
why
vince
had
suggested,
highlighting
it
as
bronze
is
because
we
expect
all
of
them
to
have
fairly
decent
performance
and
what,
but
what
you're
saying
is
is
totally
true
which
is
like
performance
is
super
important.
That's
why
it's
guiding
principle
shouldn't
that.
B
Maybe
we
should
articulate
that
as
being
gold,
because
it's
really
important,
but
then,
if
it
is,
then
we
would
have
to
sort
of
understand
that
all
of
these
are
probably
well
within
the
realm
of
reasonable
when
it
comes
to
performance.
B
So
there's
a
little
bit
of
nuance
there,
but
I
think
we're
probably
already
spending
too
much
time
talking
about
it,
considering
that
all
of
these
are
likely
to
be
reasonable
and
we
don't
have
any
data
yet.
But
I
think
we
should
be
gathering
that
data.
L
So
it
looks
like
where
we
stand
is
some
next
steps
include
getting
the
sort
of
gold
silver
bronze
labels
on
all
of
these,
and
that
incorporated
link
the
guiding
principles
to
the
various
criterias
that
are
relevant
to
them.
L
That's
some
good
stuff
to
do,
and
then
it
seems
like
we
talked
about
this
sort
of
decision
mode
we
enter
into
after
that.
All
is
done.
Oh
also
include
getting
all
the
criteria
evaluated,
they're,
not
all
done
yet.
B
B
B
And
looking
at
the
solution
criteria
now,
I
imagine
both
are
going
to
be
relatively
tricky
because
there's
fairly
even
coverage
of
just
with
like
different
caveats,
but
I
mean
we
kind
of.
We
knew
that
going
in
that's
that
was
kind
of
the
whole
point
of
getting
really
detailed
with
our
analysis.
L
I
think
the
gold
silver
bronze
will
help,
because
some
of
these
you
know
just
aren't
going
to
be
that
meaningful
or
some
of
them
are
going
to
be
super
critical
and,
like
an
obvious
one,
fails.
It.
L
Okay,
so
that's
cool,
we
have
a
sort
of
sense
of
I
think.
Yeah
cutting
cutting
the
weak
ones
is
gonna,
be
the
the
least
controversial
if
they're,
clear
and
and
gonna
be
a
good
step.
Even
if
we
then
you
you
know,
maybe
we
have
three
and
then
we
have
to
decide
between
them.
We
don't
go
all
the
way
with
the
weakest
link
style,
but.
B
Yeah
another
thing
that
I
might
propose
and
this
this
might
be
a
little
bit
tricky,
but
presuming
that
the
whole
purpose
of
this
is
to
result
in
an
rfc
that
will
be
firmly
championed.
It
might
make
sense
for
the
possible
solutions
to
list
champions
plural.
B
So
if
there's
a
set
of
people
who
feel
strongly-
and
someone
could
be
a
champion
for
multiple
right,
if
they
their
mind,
isn't
made
up
but
they're
like,
I
would
be
really
happy
to
champion
one
of
these
and
then
they
kind
of
list
those.
B
Then
that
is
also
helpful
and
that
it
gives
us
a
sense
of
support
from
a
maintainer
audience
and
from
a
like
if
we
end
up
voting
this
one's
the
best.
But
then
we
find
out
that
it
was
only
the
best
via
attrition
and
nobody
actually
cared
enough
about
it
to
champion
it
like.
That
would
also
be
a
really
sad
outcome.
I
don't
think
that's
going
to
happen,
but
but
then
it
also
makes
it
clear.
It's
like
how.
B
How
do
we
decide
that
one
gets
cut,
and
I
think
the
answer
to
that
has
to
be
that
the
person
who
is
championing
that
one
sort
of
agrees
they're
like
they
want
to
take
their
name
out
of
the
hat
and
say
I
no
longer
want
to
champion
this
one,
because
I'm
convinced
that
it's
the
weakest
link
and
once
something
drops
to
zero
champions.
Then
it's
like
very
clear
that
we
remove
it
out
of
the
possible
solutions.
B
Part
of
what
makes
that
tricky.
The
reason
why
is
a
little
bit
hesitant
is
it's
really
easy
when
you
start
putting
names
to
things
that
it
becomes
about,
like
which
person
is
best
and
as
opposed
to
which
idea
is
best,
and
it's
really
easy
to
like.
Let
our
own
emotions
get
tangled
up
into
things
and
that's
human
nature
and
that's
pretty
tricky,
and
it's
part
of
the
reason
why
we
have
purposefully
left
champion
names
out
of
the
possible
solutions.
B
So
I
think
we'll
just
have
to
be
cognizant
of
that
and
when
you
put
your
name
on
something
as
a
champion,
it
means
not.
This
is
my
idea
and
if
it
gets
voted
out,
I'm
going
to
be
pissed
off,
but
this
is
an
idea
that,
if
it
succeeds,
I
would
be
happy
to
champion
and
it's
and
I
take
accountability
and
responsibility
for
helping
aid.
The
decision
of
whether
this
particular
path
gets
trimmed
from
the
tree,
which
is
tricky,
but
hopefully
that
we
can
make
that
work.
H
H
H
H
And
maybe
we
should
have
like
a
person
like
if
some
company,
for
example,
have
a
real
real
use
case
for
input.
Unions,
and
I
think,
like
input
from
from
this
company
from
this
person,
would
be
valuable
because
he
can
evaluate
like
different
solution
against
a
real
life
use
case
and
see
how
how
certain
solution
feed
certain
use
case.
L
H
Yeah
but
like
we
have
like
six
or
seven
different,
different
seven
different
use
cases,
maybe
it's
actually
like
we
should
emphasize
it
more
at
least
include
that
all
the
proposed
solutions.
Actually.
So
we
know
what,
because,
like
I'm
not
sure
this
is
the
case
and
do
I
have
example
of
how
they
like
how
they
sold.
L
So
I
I
kind
of
get
the
feeling
that
this
is
pushing
us
pretty
far
back
in
the
discussion
like
we
covered
this
long
long
time
ago,
like
use
cases
are,
I
feel
like
we
were
pretty
well
agreed
that
there's
pretty
universal,
like
set
of
use.
Cases
that
are
have
are
pretty
legitimate
that
are
looking
for
this
solution,
so
I
I
don't
really
want
to
back
tread
into
that
can
of
worms
of
being
like.
Oh,
are
there
even
use
cases
for
this.
H
Like
I
agree
with
the
list,
I'm
just
saying
like
we
have
fixed
one,
it's
already
in
document,
I'm
just
saying
like.
Maybe
we
should
do.
I
have
a
valuation
of
solution
against
this
use
cases
so
like
if
we
have
abstract
syntax
free.
Maybe
one
of
the
thing
would
be
to
write
how
abstract
syntax
3
will
look
like
with
every
solution,
and
if
you
have
champion
for
every
solution
it
can
be
like
we
can
create
a
folder
for
every
solution
and
can
have
like
examples
of
how
certain
use
cases
so
by
certain
solution.
B
H
Because,
like
for
example,
we
can
have
solution
criteria
for
me
like
it's
very
important
criteria
is
developer
experience,
but
it's
hard
to
quantify.
That's
why
I'm
don't
identify
as
solution
criteria.
So,
like
experience
of
a
person
who
write
an
acquiry,
I
think
we
have
it
inside
graphql,
spec
and
guiding
principles.
Risk
one
saying
like
graphql
is
driven
by
front-end
engineers
and
the
experience
of
writing
queries,
but
if
we
just
put
it
in
solution
criteria,
it's
not
like
binary.
It's
not
like
something
is
fitting
or
not
like.
B
Good
yeah
there
there
is
some
important
stuff
here.
I
think
one
is
making
sure
that
we,
because
yvonne
you're,
totally
right
that
that's
like
the
top
principle,
is
that
we,
we
are
doing
things
to
make
clients
lives
easier.
More
so
than
making
servers
lives
easier.
B
We
should
make
sure
that
developer
experience
is
is
clearly
very
good,
so
making
sure
that
we,
maybe
that
factors
into
vince
as
you're
sort
of
figuring
out
your
opinions
on
what's
gold,
silver
bronze
things
that
affect
developer
experience
should
be
given
a
strong
amount
of
weight,
yeah
and
then
the
I
like
the
idea
of
listing
out
more
examples,
perhaps
instead
of
ending
up
with
like
yet
another
grid
of
like
every
possible
use
case
and
examples,
because
that
might
end
up
just
getting
kind
of
repetitive.
B
But
there
are
examples
listed
in
each
of
the
possible
solutions
which
is
great,
but
maybe
what
might
help
is
if
there
is
a
a
case
with
the
best
develop
like
what
is
what
are
the
bounds
of
the
developer
experience
for
that?
It's?
What's?
B
So,
for
example,
there's
a
couple
in
here
like
member
types
being
able
to
be
leaf
types,
you
can
fix
that
by
wrapping
a
leaf
type
in
an
object
right.
There's
there's
a
lot
of
these
that
are
more
about
developer
experience
and
convenience
than
they
are
about
expressiveness
or
allowing
you
to
do
something
new,
which
doesn't
necessarily
mean
that
they're
not
important.
It
just
means
that,
they're
being
that
they
represent
the
developer
experience-
and
maybe
this
gets
back
to
this
suggestion-
we're
talking
about
earlier
about
tying
the
solution
criteria
back
to
guiding
principles.
B
Yeah
because
we
have
at
least
two
in
there
that
are
related
to
developer
experience,
one
about
simplicity
and
consistency
over
terseness
and
expressiveness
or
overexpressiveness
and
another
one
about
understandability
being
just
as
important.
So
those
are
two,
but
maybe
it
could
even
be
important
to
just
like
list
out
yet
another
one.
I
think
maybe
it's
even
worthwhile
to
go
back
to
this
guiding
principles
document
and
making
it
even
more
clear
because
we
kind
of
like
open
graphql
as
like.
B
B
L
So
it
sounds
like
we
have
a
variety
of
action
items
I
have.
L
What
the
ask
I
would
have
of
anyone
who
wants
to
help
here
is
to
help
complete
the
evaluation,
there's
a
few
criteria
that
haven't
been
evaluated
yet
and
then
there's
the
two
that
I
added
about
backwards:
compatibility
with
sdl
and
introspection
that
need
a
little
thinking.
So
that's
the
place
where
I
think
the
most
help
could
be
provided.
L
One
other
thought
I
wanted
to
bring
up
is
with
there's
one
solution:
that
is
the
that
is
directive
based
the
sort
of
one
of
tagged
unions
thing,
and
I
I
kind
of
wonder
if
that
has
value
on
its
own.
Aside
from
this,
like,
I
could
see
a
world
where
there's
the
input
union,
but
also
this
directive
provides
value
as
well
in
other
situations.
So
I
was
curious
what
people
thought
of
that.
Q
P
B
Yep,
I
see
it
as
a
totally
possible
path
it.
It
is
a
little
bit
weird
and
that
you
know
usually
suggests
that
there
there
should
be
one
right
way
to
do
things.
That's
not
always
true,
sometimes
there's
more
than
one
one
way
that
you
can
do
something.
G
If
I
can
speak
on
this
for
a
moment,
I
think
one
of
the
other
uses
of
one
of
potentially
and
I've
not
extended
the
spec
to
cover
this
or
anything
like
that,
would
be
actually
for
input.
Arguments
as
well.
So
at
the
moment
we're
in
the
situation
where
input
objects
and
arguments
are
very,
very
similar,
but
they
are
different
and
there
are
cases
where
a
field
may
want
to
accept
exactly
one
argument.
G
For
example,
if
it's
a
finder,
you
might
want
to
find
a
user
by
their
username
or
by
their
email
address
or
by
their
globally
unique
identifier,
and
these
are
three
valid
ways
of
finding
the
same
user.
At
the
moment
we
express
that
with
three
separate
fields,
but
doing
it
with
one
field
and
a
one
of
could
well
or
one
field
or
whatever
could
be
a
valid
way
of
doing
that.
G
There's
also
I've
seen
interest
in
people
who
would
like
to
see
it
supported
on
the
output
as
well.
It's
kind
of
simpler
to
implement
than
unions
and
interfaces
from
a
back-end
perspective.
G
Personally,
I've
tried
to
discourage
people
from
that
way
of
thinking,
because
obviously,
interfaces
in
particular
have
a
lot
of
benefits
on
that
front,
particularly
when
it
comes
to
things
like
supporting
objects
that
aren't
explicitly
supported
with
a
particular
fragment
so
having
a
fullback
effectively.
But
it
is
something
that
there
has
been
interest
in.
B
Cool
yeah,
the
output
ramifications
are
a
little
more
tricky
but
yeah
you're
right
to
point
out
that
input
objects
and
arguments
are
intentionally
quite
similar.
So
it
makes
sense
that
that
use
case
would
also
appear.
L
B
K
B
For
the
notes,
vince
is
going
to
do
the
bronze
silver
gold
and
we're
going
to
tie.
L
One
for
folks
who
want
to
champion
to
offer
themselves
up
on
particular
solutions.
H
And
one
it's
not
discussion,
just
a
shout
out
for
people
to
think
in
prior
art.
I
think
there
is
like
swift
and
rust
and
they
have
ideas
that
you
try.
A
news
is
not
like
just
a
numerator
of
something
you
can
tie
like
types
to
news.
H
But
like
I
really
like
idea,
it's
like
similar
to
what
benjamin's
suggestion,
but
as
a
part
of
a
language
I'm
like
thinking
about
this
for
a
month,
but
I'm
I
don't
have
anything
concrete
so
like
just
just
idea
for
for
people
to
study
prior
art,
section
and
brainstorm.
I
think
like
there
is
still
possibility
to
find
some
some
hybrid
solution
or
new
solutions.
N
The
only
difference
is
that
in
union
the
number
of
choices
well
known
and
unlimited
in
case
of
interfaces,
it
is
open
end,
but
in
general
the
behavior
behavior,
or
at
least
in
graphical
for
graphical
perspective,
is
very
similar
in
order
to
say,
render
or
output
the
value
of
union
or
value
of
interface.
You
have
to
provide
a
fragment,
then
then,
look
at
the
input
part
on
the
input
part.
N
If
I
have
this
similar
construct
like
what
would
we
would
be
discussed
with
one
off
for
let's
say
you
know,
if
you
would
assume
only
one
of
multiple
choices
or
maybe
a
field
can
be
a
polymorphic
type
of
let's
say,
of
type
of
interface.
If,
let's
say
we
don't,
I
know
that
we
don't
have
the
input
interfaces,
but
I
think
in
the
future
maybe-
and
we
have
some
use
cases-
maybe
we
will
bring
them
up
later,
but
in
that
case,
how
do
I,
as
a
user,
I
decline?
N
How
do
I
specify
a
value
on
input
of
the
type
that
is
that
belongs
to
the
set,
not
the
only
let's
say
the
type
of
that
implements
an
interface
or
a
type
that
is
component
of
the
union.
In
my
mind,
those
cases
are
quite
similar.
I'm
not
saying
that
we
need
to
do
the
input
interfaces
right
now,
but
when
we
work
on
the
unions,
I
would
suggest
that
we
keep
that
in
mind,
because
in
the
future
that
might
but
it
might
come
up,
it
can
come
up
as
a
very
case.
L
There
wouldn't
actually
be
a
tangible
difference
as
to
how
you
interacted
with
the
api,
whether
it
was
a
union
or
interface
and
the
interface
like
the
fact
that
interfaces
have
shared
fields,
kind
of
doesn't
matter,
because
you're
publishing
all
the
fields
explicitly
you're,
not
asking
for
them.
Yeah.
L
Down
the
route
of
just
sticking
with
input
union,
because
you
can't
tell
the
difference.
N
Sure
we
don't
have
respect
for
the
interviews,
but
but
again,
even
if
we,
the
unions,
just
just
try
to
use
funded
korean
interfaces
even
in
the
union
in
order
to
be
able
to
provide
a
value
for
a
particular
type
for
a
particular
variant
of
that
union.
I
need
to
tell
what
kind
of
variant
it
is
right.
Yeah,
the
same
is
similar
with
interface.
If,
let's
say
I
assume
that
I
have
the
input
interface,
I
need
to
provide
a
concrete
value
for
that
interface.
Interface.
Definition.
How
do
you
specify
the
type.
L
B
Cool
sounds
like
we
have
good
action
items
to
take
from
there.
I
want
to
move
on.
Let's
move
on
to
victor's
root,
query
operation,
types
being
optional,.
C
All
right,
hello
thanks,
so
I
was
in
the
october
working
group
meeting
where
I
talked
about
a
initial
proposal
to
allow
empty
composite
types
in
general,
and
I
got
some
valuable
feedback
and
basically
what
I
got
from
that
meant
that
I
think
the
only
thing
which
can
be
sort
of
immediately
solved
was
to
maybe
make
the
root
query
type
optional.
C
C
C
C
So,
in
the
initial
my
initial
pr
631
to
the
spec,
I
proposed
to
not
make
the
introspections
reliant
on
that.
But
then
I
got
some
feedback
on
that
and
now
I
think
basically
the
proposed
lesson
stands
would
effectively
create
a
kind
of
stub
query
type
on
all
schemas.
If
you
don't
define
one
of
your
own,
which
only
supports
introspection,
but
other
than
that
you
don't
have
to
add
dummy
fields
like
hello,
world
test
or
just
underscore,
all
of
which
I
have
had
to
do
myself
at
various
points
in
time.
C
C
C
B
The
problem
seems
relevant
to
me:
I'm
glad
you've
been
searching
for
what
a
solution
might
look
like.
I
do
think
the
devil's
in
the
details.
Writing
writing
a
change
to
the
spec
text
itself
might
make
it
clear
how
complicated
this
will
end
up
being.
P
Just
for
word
it's
worse,
so
we
in
hot
chocolate.
We
allow
that
already
today
to
do
that,
and
so
basically,
if
there
is
no
query
type
specified,
we
basically
specify
a
query
type
automatically.
That
just
has
the
introspection
fields
and
we
do
that
for
schema,
stitching
scenarios
where
you
have
basically
you're
building
just
parts
of
your
schemas
and
yeah
like
domain
services,
and
there
are
cases
where
you
just
have
mutations,
maybe
on
one.
P
So
we
support
that
and
it's
I
think
there
is
it's
quite
easy
to
should
quite
easy,
be
to
implement
so.
B
That's
the
that's
the
variant
where
the
we
allow
the
type
to
be
empty.
P
Yes,
it's
no!
No,
it's
not
the
type
to
be
empty.
It's
like
basically
allowing
to
omit
the
query
type
so,
basically
in
hot
chocolate
we
allow
just
to
specify
a
mutation
type
and
then
we
under
the
reps
basically
generate
a
query
type
that
just
has
the
introspection
fields
so
that
we
have
again
a
valid
schema.
G
The
main
hesitation
that
I
have
with
that
particular
particular
solution
is
that
it
means
that,
if
you're
doing
the
query
for
them,
you're
also
giving
the
query
object
a
name
and
in
future
you
may
want
to
specify
a
custom
name
so
personally,
I'd
allow
them
to
specify
their
own
name
for
that,
for
that
empty
query
type,
but
other
than
that,
I
think
it's
a
solid
way
of
going
forwards.
P
But
I
mean
in
the
schema
stitching
scenario
that
we
have
in
mind:
it's
actually.
Basically,
if
there
is
no
real
query
type
on
this
domain
service,
we
are
not
really
stitching
it
in
and
you
can
actually
rename
the
actual
query
type
at
the
gateway
level.
So
it
depends
on
your
solution.
P
P
P
B
I
see
okay,
so
the
suggestion
then,
is
that
there's
the
introspection.
B
The
introspection
shows
that
there
is
a
query
type,
but
only
in
order
to
expose
the
introspection
fields,
but
then
the
sdl
would
not
print
the
query.
Yeah.
B
H
So,
for
example,
if
I
remember
correctly
in
the
relay
classic
you
needed
to
to
a
reference
acquired
type
from
a
query,
and
you
could
not
ask
for
introspection
fields
a
second
level,
even
if
it's
the
same
query
type.
So
I
think
there
is
like
confusion
is
already
present
in
spec
because,
like
introspection
fields
are
not
fields
inside
the
type,
the
fields
that
you
can
apply
on
acquire
so
yeah.
P
Exactly
we,
we
viewed
it
like
that,
because
the
the
introspection
fields
on
the
on
the
query
type-
you
wouldn't
print
that
as
well
in
the
stl.
P
So
when
you're,
not
printing,
those
there's
no
worse
than
printing
an
empty
query-
and
I
mean
there
are
the
the
introspection
fields
itself
are
kind
of
magically
just
in
your
query
type.
So
that's
why
we
went
down
that
road
to
allow
that.
H
P
Ivan
we,
we
actually
put
them
really
into
the
query
type
in
our
implementation,
because
this
way
we
don't
have
to
specify
an
extra
extra
code
pass
in
our
execution
engine
that
works
differently,
just
because
someone
is
asking
for
those
internal
fields,
but
we
have
we.
We
have
kind
of
modifiers
and
all
fields
like
these
fields
are
internal,
so
the
user
can't
really
accesses
access
them.
It's
kind
of
like
we
see
sharp
classes
where
you
have
public
public
properties
and
internal
properties,
and
basically
these
are
internal
fields
to
us
internally.
B
B
And
this
is
interesting.
I
don't
know
if
your
if
your
solution,
michael,
is,
is
generalizable
because
of
that
detail
of
how
how
you're
building
that
the
spec
says
that
those
are
meta
fields
that
shouldn't
be
on
that
type.
So
either
we
would
have
to
have
no
type.
But
you
can
still
technically
write
a
query.
However,
that
query
must
only
include
meta
fields,
but
that
might
be
tricky
for
some
tools
or
we
allow
empty
types.
P
Yeah
the
the
question
for
me
from
an
implementation
perspective,
I
mean
from
the
user
perspective,
who
does
some
internal
introspection
on
our
types?
Basically
gets
a
types
object
cannot
access
these
types,
but
from
an
execution
engine
perspective,
it's
we
don't
have
to
write
extra
code
that
says:
okay,
that
field
is
actually
there.
Then,
if
that
field
is
queried,
then
it's
actually
not
there.
So
we
have
to
automatically
do
something.
P
B
C
To
be
honest,
I
I
think
I
I
think
it's
a
I
mean,
given
the
fact,
because
you
can't
see
these
fields
if
you
do
the
introspection
and
they
wouldn't
be
printed.
If
you,
if
you
were
to
print
an
stl
of
the
schema
right,
they
would
and
then
but
then
you
either
have
to
basically
hide
the
type
or
you
have
to
be
fine
with
being
empty,
and
so
I
think,
like
automatically
creating
a
type
I
mean.
C
You
know
I
might
actually
go
go
you
know
hearing
this.
I
might
actually
say
that
I
mean,
for
all
intents
and
purposes
like
this
is
saying.
If
you
don't
define
this
root,
query
type
you're
going
to
get
one
anyway,
but
it's
not
really
there.
It's
just
sort
of
there
for
various
reasons.
So
maybe
I
haven't.
I
might
I'm
a
little
bit
jumbled
just
now,
but
I'm
thinking
that
maybe
actually
it
would
be
better
to
well.
C
I
still
think
there
are
different
use
cases
for
empty
types
in
general,
so
but
maybe
restricting
it
specifically
to
the
empty
root.
Query
type
would
be
more
conservative
without
sort
of
introducing
spooky
types.
If
you
will
spontaneously,
I
mean
there,
there
are
a
number
of
issues
with
allowing
them
in
general,
but
maybe
that
was
actually
mostly
to
do
with
interfaces
more
than
just
object
types.
N
N
Understand
yeah,
and
maybe
we
we
can
work
on
the,
and
this
is
a
network
suggestion.
Maybe
we
we
can
work
on
the
backwards
compatibility,
but
I
am
just
throwing
this
idea
out.
Maybe
that
would
help
to
solve
this.
This
use
case,
and
maybe
some
others
in
the
future.
C
K
C
No
sorry,
sorry
interpreting
trophy
go
ahead.
No
I'm
just
thinking
that
I
mean
the
stl
already
supports
empty
types
right.
So
that's
not
really
strange.
C
E
P
B
Right
so
I
think
there's
two
paths
forward
here
and
they
have
somewhat
different
implications
and
they
solve
slightly
different
problems.
So
I
think
it's
worth
being
concrete
about
what
problems
we
actually
want
to
solve.
B
One
path
is
to
revisit
the
the
rfc
that
you
closed
earlier,
of
supporting
empty
types
and
and
really
doing
that
across
the
board,
so
changing
the
grammar
to
allow
empty
selections
allowing
empty
objects
anywhere
in
the
tree,
going
full
force
with
that
there's
some
motivation.
B
That
explains
why
that
might
be
useful
and
evaluate
whether
that's
reasonable
or
not.
That's
one
path
that
would
allow
us
to
get
to
a
point
where
you
could
have
a
query
type,
that's
empty
another
path
which
I
think
might
get
closer
to
the
specific
problem
that
you're
trying
to
solve
is
not
allowing
there
to
not
be
a
query
type
at
all.
So
there's
no
query
type
and
similar
to
how
no
subscription
type
implies
that
this
server
does
not
support
subscriptions
and
no
mutation
type
implies
the
server
does
not
support
mutation.
B
B
In
that
case,
I
think
what
we
need
is
language
in
the
spec
and
some
noodling
around
in
one
of
the
reference
implementations
to
make
sure
this
is
reasonable
to
see
what
what
would
it
look
like
to
write
a
query
of
meta
fields
so
asking
for
introspection
when
there's
not
a
query
type
right
now,
that's
probably
a
little
bit
confused,
but
that
seems
like
a
viable
path
to
try
out.
C
C
I
was
kind
of
just
salvaging
this
problem
because
I
thought
it
was
interesting,
but
I
mean
to
be
honest.
I
I
was
mo.
I
I
came.
I
came
at
this
from
the
whole
extensible
introspection
thing,
which
is
somewhere
else
completely,
so
I
mean
I'm
willing
to
pursue
both
just
sort
of
to
get
things
keep
things
going,
but
but
I
would
I
I
can't
hide
my
bias
in
the
first
path
that.
B
You
mentioned
totally
yep,
I'm
not
suggesting
that
you
have
to
follow
both
just
suggesting
that
this
is
our
two
potential
paths.
I
could
see
this
taking
each
with
their
own
set
of
trade-offs,
but
ultimately
you're
the
champion,
and
you
should
decide
which
path
is
more
of
being
sketched
out.
Further
sure
sounds
fair.
H
I
would
subject
action
item
to
to
for
me
and
anybody
else
who
actually
implement
this
feature
to
document
it
inside
like
inside
pr.
So
we
keep
like
a
discussion
history
inside
in
an
issue.
So
let's
show.
G
Hey,
okay,
cool,
so
last
last
agenda
item
is
we've
been
working
hard
on
graphical?
G
As
I
said
last
spec
working
group,
it's
primarily
ricky,
is
doing
a
lot
of
code
and
pushing
the
code
base
forward
at
an
incredible
pace
really
for
someone
doing
it
in
their
spare
time
and
there's
a
few
of
the
rest
of
us
who
are
trying
to
keep
up
with
reviewing
pull
requests
and
trying
to
stay
on
top
of
the
issues
as
well.
Obviously,
it's
a
widely
used
project,
so
it
does
get
quite
a
lot
of
issues
and
pull
requests.
G
We
are
struggling
to
keep
up
as
a
group.
All
of
us
we
have
been
bringing
on
other
maintainers,
but
it
seems
that
what
we,
what
we
want
to
do
and
the
reason
that
we
spawned
off
the
gra,
the
graphical
working
group
from
the
graphql
spec
working
group
is
to
enable
this
greater
functionality
that
should
be
beneficial
to
basically
all
of
the
different
qlids
in
the
ecosystem.
G
So
things
like
playground
and
altair
things
like
vs
code,
extensions,
language,
server
stuff
so
integrations
with
your
editors
like
vm
and
whatnot
as
well,
a
whole
load
of
stuff
that
can
be
enhanced
by
our
system
and
we
want
to
make
it
extensible
so
that
all
these
different
tools
can
use
it
without
necessarily
having
to
sort
of
fork
an
old
version
and
then
struggle
to
keep
it
up
to
date,
it's
better
to
have
like
a
shared
core
and
then
to
implement
the
the
innovations
on
top
of
that.
G
So
that's
what
we
want
to
enable,
but
we
are
struggling
in
terms
of
human
resources
to
actually
be
able
to
do
that.
So
I've
been
speaking
with
chris
from
the
linux
foundation,
graphql
foundation
and
he's
proposed
that
effectively,
the
linux
foundation
have
their
own
crowdfunding
platform
funding.communitybridge.org
and
there's
a
graphql
project
on
there.
G
B
Benji
are
you
thinking
of
from
the
current
set
of
maintainers,
just
like
making
sure
that,
like
setting
up
official
contracts
so
that
they
spend
dedicated
time
on
graphical,
or
are
you
thinking
of
trying
to
attract
contractors,
new
people
to
help
that
we
would
pay.
G
I
think
it
would
be
more
along
the
lines
of
what's
the
other
site,
open,
open,
collective,
that
style
of
thing
where
effectively
there
is
a
pool,
and
then
the
the
group
can
agree
to
spend
money
from
the
pool
on
funding
someone
to
do
a
thing.
It
may
well
be
that
there
are
regular
contributions
going
out
from
that.
So,
for
example,
if
one
of
us
were
to
stay
on
top
of
issues
for
a
few
hours
a
week,
it
might
be
that
there's
a
regular
payout
for
that.
G
It
might
be
that
if
we
want
to
fund
a
particularly
large
task
like
converting
the
entire
system
to
touchscript,
for
example,
then
that
might
be
a
chunk
that
we
can
effectively
fund
to
them.
As
a
as
a
one-off
thing,
I
don't
think
it
necessarily
has
to
be
limited
to
the
maintainers,
so
it
could
be
external
developers
as
well
and
contributors,
but
I
think
that's
more
of
a
thing
for
the
linux
foundation
graphql
foundation
to
to
govern
over.
G
Yeah,
I
think
you
can
also
do
regular
stuff
from
it,
but
I'm
not
super
knowledgeable
on
it.
So
I'm
I'm
not
sure.
Okay,
yeah.
B
I
haven't,
I
haven't,
actually
used
open
collective
in
depth,
cool.
Well,
one
thing:
actually
I
might
ask
of
you
benji
is
to
we
can.
We
can
take
this
into
a
separate
discussion
just
so
we
don't
have
to
burn
everybody's
time
and
dig
in
deeply
about
the
various
paths
and
and
kind
of
like
what
we
think
tactically
will
be
most
valuable
to
the
graphical
project
in
terms
of
just
like
getting
funds
available.
That
I
think
shouldn't
be
that
hard.
B
We
have
a
pool
of
graphql
foundation
funds
that
are
specifically
intended
to
go
towards
maintainers
of
graphql
foundation,
projects,
of
which
graphical
is
one
so
that
we
already
have
set
up
it's
just
a
matter
of
figuring
out
how
exactly
we'd
like
to
divvy
it
out.
B
So
how
about
you
and
I
chat
offline,
and
we
could
figure
out
some
more
specific
details
of
how
we
want
that
to
work
out.
G
B
Sounds
great,
I
think
something
that
is
actually
pretty
valuable
for
this
group
is
coming
up
with
some
either
easier
way
to
contribute
to
those
or
easier
ways
to
take
from
those
right
now.
The
one
that
the
linux
foundation
has
set
up
for
us
is
pretty
coarse,
so
I
I'd
love
to
make
it
easier
for
for
people
to
contribute
into
those
pools.
B
So
if
anybody
ever
has
ideas
on
how
to
do
that,
even
if
it's
just
setting
up
open
collective
or
I
don't
know-
we
might
experiment
with
the
github
sponsorship
as
well,
the
accounting
of
how
all
these
things
connect
to
each
other
might
be
tricky,
but
if
we
can
make
them
work,
I
think
that'd
be
pretty
interesting
to
do.
H
I
think
we
can
reach
out
at
least
like
investigate.
Is
there
is
any
other
foundations
having
this
set
up
in
under
linux
foundation?
Maybe,
like
I
don't
know
like
kubernetes
foundation
or
other
foundations,
doing
open
collecting
for
other
crowdfunding,
and
we
can
just
reuse
the
experience.
B
Yeah,
I
know
that
the
js
foundation
has
some
specific
stuff
set
up
too,
because
the
js
foundation
operates
as
sort
of
a
collective
of
a
lot
of
projects
and
so
I'll
ask
what
they're
doing
might
be
something
interesting
that
we
can
try.
H
Yeah
because
like
when,
in
a
sense
like
we
started
in
graphical
team
and
like
there
is
a
lot
of
progress
and
a
lot
of
like
distribution
and
team
is
growing,
so
I
think
like
effectively
right
now,
we
like
kind
of
like
free
projects,
reference
implementation,
graphical
and
spec.
H
G
I'd
like
to
actually
victor
you
mentioned
previously
about
is
victor
still
online
on
the
line.
Yes,
yes,
I'm
here
cool
you
mentioned
previously
about
the
schema.
I
forget
what
we
call
it,
but
like
a
schema,
enhancements
effectively
the
ability
to
customize
the
the
introspection
of
the
schema
so
that
it
can
pass
through
an
initial
additional
data.
Do
we
have
anyone
who's
specifically
championing
this
right
now?
I
know
you
were
working
towards
it
and
that's
where
the
empty
object
stuff
came
from,
but
I
haven't
seen
much
talk
about
it
recently.
C
Speaking
for
myself,
I'm
not
I
I
wouldn't
say
I'm
championing
it
any
more
than
well.
That
comment
I
made
specifically
when
I
made
that
comment
I
I
had
not
seen
so
what
I
saw
was
that
ivan,
I
think,
made
a
presentation
about
something
similar
in
me
and
I
just
hadn't
seen
that,
but
it
was
very
similar.
I
think
to
do
that.
But,
speaking
for
myself,
I
have
not
done
anything
more
in
that
area,
specifically.
H
So
it's
number
one
on
my
list,
but
I
don't
want
to
accelerate
like
stuff.
I
think
we
first,
we
need
to
add
to
stage
introspection
and
see
how
it's
adopted,
and
only
when
we
should
discuss
like
adding
extensions
to
to
use
like
two-stretch
introspection.
I
I
don't
think
we
should
put
like
carriage
before
a
horse.
We
should
not
discuss
like
ways
to
how
to
additionally
use
to
search
in
transparent
until
we
actually
like
be
sure
that
it's
working
and
sample
mind
and
then
a
community
switch
into
it.
H
So
when
we
can
have
rfc
and
discussion
for
adding
an
extension
type,
it
can
be
empty,
it
can
be.
We
can
have
some
some
field
in
it
or
we
can
figure
out
some
way
or
say
anyway.
Extensions
are
optional,
so
if
you
have
something
inside
with
type
exist,
if
we
don't
have
something
inside,
that's
not
exist.
H
I'm
just
saying
it
should
not
be
it's.
It's
not
a
use
case
for
empty
types,
because,
like
it's
depend
on
something
that
it's
not
yet
implemented,
it's
not
yet
adopted.
So
it's
not
a
valuable
use
case,
but
yeah
I'm
champion
to
stage
introspection
and
I'm
working.
P
On
it
at
the
moment,
but
I've
been
with
two-phase
introspection,
you
mean
the
asking
for
what
features
you
have
on
the
graphql
server
and
then
doing
the
actual
introspection.
H
H
P
H
P
We
are
basically
doing
the
first
introspection.
Then
we
are
building
the
actual
introspection
yeah.
I
think
we
can
take
it
to
fine,
because.
O
G
So
it
seems
like
no
one
is
working
concretely
on
schema
extensions
on
the
introspection,
extensions
right
now.
It's
more
of
the
two
stage
is
something
that
you're
working
on,
which
may
enable
us
to
do
that.
G
Yeah,
I'm
still
interested
to
push
well,
to
be
honest,
I'd
be
interested
to
see
how
you
think
the
two-stage
introspection
will
enable
the
the
schemer
extensions
thing
as
well.
So
maybe
I
can
talk
with
you
again
offline
about
something
like
this.
B
Super
excited
that
michael
you've
already
gone
and
built
the
two
phase,
so
that,
hopefully
yvonne
can
pick
up
from
where
you
left
off,
and
we
can
get
to
something
that
we
can
share
beyond
just
the
chili
cream
tools,
but
benji.
You
should
certainly
feel
free
to
pick
up
that
stuff.
If
you're
excited
to
champion
it,
I
don't
think
anybody
is.
G
Yeah
cool-
I
probably
don't
have
enough
time
right
now,
but
at
some
point
definitely.
B
H
Another
like
small
thing
chris
richman
reached
to
me
and
asked
if
I
want
to
write
a
blog
post
after
every
working
group
about
what
we
discussed.
So
I
will
try
to
create
a
draft
and
I
will
probably
create
an
issue
on
repo
for
like
with
the
link
to
draft.
So
if
anybody
wants
to
to
help
with
that
or
like
review
it,
because,
obviously
I'm
not
a
native
speaker,
it
would
be
greatly
appreciated.
M
I
think
I
have
a
specified
directive
basically
done.
Would
we
want
to
like
add
graphical
support
for
that
too?
Just
as
like
an
example
of
like
a
client
consuming
that.
B
Certainly
yeah,
we
can
certainly
make
that
I,
I
don't
think
we
would
hold
stage
two
for
that,
but
that
would
be
helpful
to
help
move
the
process
along
absolutely
great.
B
All
right,
we'll
wrap
up
for
the
day.
We've
got
a
lot
of
great
stuff
to
to
do
next
and
I'll
see
all
of
you
after
the
winter
holidays
in
early
january.
Goodbye,
great
folks,
thanks.