►
From YouTube: GraphQL Working Group - July 2, 2020
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
C
C
C
C
C
C
C
B
B
D
B
If
you're
not
on
the
attendees
list,
yet
please
feel
free
to
send
a
late
pull
request.
I'll
I'll
try
to
do
a
couple
reloads
and
catch
any
that
come
in
late,
but
always
good
to
make
sure
that
that
attendee
list
is
accurate
to
whoever's
here
all
right.
Let's
kick
things
off
so
at
the
top
per
as
per
usual,
a
reminder
that
by
joining
us
here
we
all
agree
to
the
spec
membership
agreement,
participation,
guidelines
and
code
of
conduct.
B
Hopefully
that's
no
news
to
everybody,
but
yep
those
links
are
there
in
case
you
want
to
reminder:
let's
do
a
quick
around
the
room
put
names
to
faces.
I
think
we
have
mostly
just
returning
folks
here,
but
always
good
to
have
a
reminder
for
anyone
who
might
be
new,
we'll
start
at
the
top
and
work
down
the
order
in
the
doc
and
anyone
else
who
hasn't
had
their
name
on
the
dock,
yet
just
hop
in
last,
so
everybody
I'm,
Lea
I,
think
Andy
said
that
he
was
not
gonna
be
able
to
make
it
today.
F
L
B
M
F
B
Happy
thanks,
Benji
your
treasurer
okay.
Let's
take
a
quick
look
over
our
agenda
and
make
sure
that
everything
that's
on
here,
stuff
that
we
actually
want
to
talk
about
today,
we're
not
missing
anything.
We
will
take
a
quick
look
over
the
previous
action
items.
I,
don't
know
if
we
actually
translated
last
meetings,
notes
to
action
items.
Yet
we
will
talk
about,
require
argument,
uniqueness,
moving
the
deprecated
directive
on
input
fields,
RFC
to
a
higher
stage,
will
get
an
update
on
defer
and
stream,
and
then
talk
about
custom,
scalar,
PR.
B
B
B
B
B
There
was
an
action
to
move
forward
the
graphical
namespaces
with
a
an
actual
stage:
zero
spec
I.
Don't
think
any
action
has
happened
on
that
yet,
but
that's
on
Courtney
and
then
there's
another
piece
that
was
related
to
input
unions,
which
I
think
we
already
mentioned
that
we
didn't
see
a
lot
of
action
on
in
the
last
month.
That's
okay,
but
we
need
to
draft
up
a
an
RFC
that
captures
the
tag
types
but.
B
Yeah
I
well
I
appreciate
the
update.
That's
great
progress
is,
is
excellent.
I'll
take
a
note
to
make
sure
I
get
these
previous
meetings
actions
translated
into
issue,
so
we
can
track
them
a
little
bit
easier
and
then
Benji.
If
you
have
any
of
that
to
share
or
work
in
progress,
always
great
I'm
happy
to
give
any
input.
That's
useful
and
you
can
just
kind
of
wait
there
until
if
you
get
all
the
fluff
around
it
thanks.
E
Yes,
so
I,
it's
a
quick
issue.
That's
why
I
identified
means.
So
basically
we
have
validation
for
that
system
in
Chapter
three
and
it's
like
demand,
uniqueness
of
fields
and
like
basically
mowers
everything
quite
uniqueness
of
type
times
the
field
names,
but
we
missed
to
specify
uniqueness
of
argument
names.
So
it's
like
oh
gas,
emission,
but
technically
so
I.
It's
you
change.
It's
not
an
editorial,
even
though
it's
like
obvious,
so
a
person
opened
PR
against
repo
and
I
can
actually
think
I
can
like.
E
B
E
I
actually
wanted
to
do
it,
but
yeah
I
had
some
issues
this
time.
Okay,
so
my
idea
is
like
at
least
preliminary
ask
people,
maybe,
like
somebody,
have
some
opposition
and
want
to
voice
it.
So
I
think
we
can
move
to
stage
one
without
without
recommendation,
and
at
least
you
know
just
want
to
to
start
ball
rolling.
B
E
In
code
for
schema,
when
you
use
in-memory
object
to
create
it,
do
you
use
mocks?
So
you
automatically
have
none
duplicated
argument
names
because
you
cannot
and
for
his
deal
validation,
I
added
only
in
1400
and
I,
actually
forget
to
address
validation.
So
right
now
we
just
over
radiant.
So
if
you
specify
two
arguments
with
the
same
name,
it's
the
second
one,
you
silently
our
eyes,
the
first
one
so.
E
B
E
B
E
We
actually
have
a
plan
to
start
working
on
new
version
of
crafting
JSON
new
breaking
chain
breaking
my
question
to
do
that.
Clip
migration.
We
actually
try
to
do
it
without
making
new
version,
but
it's
complicated
the
whole
right
now
I
actually
want
to
to
much
as
much
stuff
as
possible
into
current
release
and
switch
to
new
one
and
because
it
will
take
us
some
time
to
convert
to
tack
strips
and
stabilize
after,
but
hopefully
hopefully
others
in
you
Montaigne
who
helps
me
specifically.
We
start
with
migration,
so.
F
B
C
It
doesn't
seem
to
be
controversial,
so
I
I
took
the
existing
PR
and
just
rebased
it
on
master
cleaned
it
up
a
little
bit
so
that
it
is,
you
know
it
looks
like
it
should
be
mirja
ball
and
just
want
to
see.
If
there's
any
blockers
to
moving
this
to
stage
2
draft
status
and
and
Evon
might
have,
you
might
have
things
to
steaks.
I
know
you've
been
working
with
this
proposal
for
for
a
while
also.
C
So
and
so
we've
linked
here
we
have
the
initial
PR
and
then
then
I
had
linked
to
the
revised
PR.
But
Yvonne
has
has
helpfully
squashed
that
backends
that
that
it's
all
in
the
original
thread
of
discussion
there
and
one
of
the
requirements
for
draft
status,
is
that
there
is
a
graph
QL,
JSP
R,
and
so
there
there
is
one
there.
There
are
a
few
a
few
things
it
looks
like
needs
to
be
done
to
make
that
merger
bowl
just
ammunition.
K
E
Like
when
we
was
talking
a
couple
minutes
ago,
push
push
it
so
technically
it's
ready.
There
is
like
some
things
like
it's
missing,
some
features,
which
is
candle
tone
essential.
For
example,
we
have
a
validation,
roof
for
tracking
duplicated
usages
and
it's
need
to
be
implemented.
But
this
it's
like
it's
not
the
core
functionality,
so
a
utility
function
will
provide
so
it's
nice,
but
it's
not
required.
So
technically
we
are
for
alien
Krispies
with
fields
is
deprecated
and
deprecated
risen
to
introspection.
E
C
For
for
Stage
two,
you
know,
unlike
stage
three,
the
graph
your
gspr
does
not
have
to
be
merged,
yet
it's
it's
basically,
just
when
a
proposal
has
you
know,
set
of
problems
and
drawbacks,
they've
been
fully
considered
and
accepted
or
resolved,
and
the
solution
is
deemed
desirable.
So
we
do
have
consensus
that
that
requirement
is
satisfied.
I.
B
E
E
E
E
C
B
B
E
B
Thinking
about
the
case
where,
like
a
tool,
because
you
have
to
explicitly
ask
for
deprecated
fields
and
introspection,
so
some
tools
that
want
to
operate
only
on
the
non
deprecated
part
of
a
schema.
Could
you
know,
request
only
non
deprecated
fields
and
non
deprecated
arguments
and
then
you're
in
some
front-end
tool.
That's
doing
nice
type
of
heads
and
client-side
validation,
everything
and
it
says
everything
looks
great
and
then
you
go
to
submit
that
the
server
rejects
it
because
it
says
you're
missing
a
required
argument.
J
Yeah,
that
would
be
a
really
bad
state
to
be
in,
and
we
probably
don't
want
to
warn
people
even
even
warnings
we
should
be
treating
as
the
equivalent
of
oh.
We
could
do
like
a
see
the
claim
w
all
I
prevent
you
from
even
using
anything.
That
would
be
a
warning
and
if
that's
not
possible,
then
we
shouldn't,
then
it
shouldn't
even
be
possible
in
the
language
like
if
there's
a
way
that
you
can
end
up,
I
have
to
use
the
warning
in
order
to
move
forward.
You
know
a
brand
new.
B
System,
it's
a
Stevens
Point,
the
it's
a
safe.
It's
a
non-breaking
change
to
make
a
required
argument,
a
optional
argument,
which
presumably
is
what
your
we
would
do
if
you
were
gonna
deprecated
an
argument
anyway,
because
it
doesn't
make
sense
to
deprecated
an
argument,
that's
required,
and
so
it.
If
that's
the
case,
then
maybe
the
missing
piece
here
for
this
single
pitfall
is
just
a
schema,
validation
rule.
That
just
says
an
argument
can't
be
a
required
argument,
can't
be
deprecated.
A
A
L
Want
to
throw
a
counter
example
in
here,
because
we
have
an
internal
version
of
deprecated
inputs
atop,
a
file
that
you
know
doesn't
get
surfaced
in
the
spec
at
all.
But
we
do
have
a
use
case
for
deprecating
required
arguments,
mostly
in
the
form
of
like,
because
we
have
a
version
API.
We
have
it's
required
in
version
1
and
then
optional
in
version
2
and
then
removed
in
version
3,
and
we
want
a
market
as
deprecated
across
the
board,
because
that's
kind
of
an
informational
thing
and
it's
not
specific
to
a
version.
J
In
that
case,
would
you
prefer
to
deprecated
the
field
and
switch
to
a
new
field,
because
I
don't
know
how
you
can
both
I
guess
so
you're
saying
you're,
marking
the
input
type
as
hey
you're
going
to
need
to
migrate
away
from
this,
but
right
now
you
have
to
use
it
because
you're
on
the
deprecated,
you
decorate
everything
in
that
well
version.
Well,.
L
J
L
B
Be
a
little
icy,
so
what
you're
saying
is
that
the
timeline
in
which
you
introduce
the
deprecated
flag
is
broader
than
the
timeline
with
which
you
make
that
argument
optional,
so
that
you
think
of
it
as
three
phases.
First,
you
deprecated!
Then
you
make
it
optional,
and
then
you
remove
it
only
at
some
point
in
the
future
when
nobody
is
using
it
anymore.
Yeah
and
we've
committed.
L
It
as
well
to
make
note
once
a
version
has
been
released
if
our
API,
we
make
no
changes
to
the
schema
at
all,
even
stuff
that
is
compatible
such
as
making
an
argument
optional.
So
we
can't
just
like
make
it
optional.
Then
market
is
deprecated.
We
would
have
to.
You
know,
go
through
processes
to
that.
That's
it.
You
know,
I
realized
that
our
versioning
scheme
is
kind
of
weird,
because
nobody
else
critical
at
all
so
is.
I
This
whole
idea
of
deprecation
and
null
ability
a
little
bit
of
too
tightly
wound
up
here.
All
right.
It
feels
like
there's
two
separate
things.
One
is:
what
can
you
do
with
respect
to
no
ability
to
ensure
compatibility
while
you're
making
updates
to
the
client,
but
another
dimension
to
me
seems
to
be
that
if
we
look
at
other
languages
they
have
the
ability
to
mark
things
as
deprecated,
where
it
emits
a
warning
versus
an
error
and
I
I.
I
Wonder
if
that
captures
the
use
case
that
you're
describing
I've
been
without
changing
the
nil
ability
of
the
the
thing.
So,
in
other
words,
like
let's
say
you
know,
you
have
v1
no
changes.
Clients
are
very,
very
happy.
You
mark
a
field
is
deprecated
with
a
warning
level,
and
you
say:
hey
you
know.
Just
heads
up
this
field
will
be
changed,
so
you
can
get
ahead
of
that
great
and
but
that's
that's
a
minute
as
a
warning
and
the
client
can
still
operate
like
that.
I
I
Do
it
sure
I'm
sorry
I'm
not
expressing
myself
clearly,
in
other
words,
doing
the
tooling
phase?
Let's
say
you
know
when
you're
doing
graph
field
code
generation
its
emitted
there
as
an
error,
even
though
legacy
clients
still
sending
that
query
are
compatible
that
way,
it
decouples
the
notion
of
a
tooling
and
the
lifecycle
and
the
communication
of
the
deprecation
from
needing
to
change
its
null
ability.
Yeah.
B
L
B
Write
I'll
restate
my
concern
so
and
what
I'll
preface
by
saying
this
might
not
be
a
real
concern
based
on
how
actual
tools
work
but
imagine
a
tool,
client-side
tool
that
decides
to
run
an
introspection
query
to
learn
about
a
schema
without
providing
the
like
deprecated,
true
statements
in
the
introspection
query
to
get
deprecated
fields
and
arguments
and
input
fields,
and
therefore
it
only
gets
the
non
deprecated
piece
of
the
schema.
Then
it
uses
that
non
deprecated
portion
of
the
schema
to
do
pipe
heads,
client-side,
validation,
etc.
B
It
deems
that
that
client-side
code
base
free
of
errors.
Then
you
deploy
that
and
then
you
start
running
these
queries
only
to
find
that
the
server
rejects
them,
because
a
argument
that
that
client
didn't
even
know
existed
because
it
hadn't
fetched
deprecated
arguments
happen
to
be
required
and
therefore
that
that
query
was
rejected
out
of
hand
and
didn't
execute.
So
I
think
that
would
be
a
surprising
result,
but
that
assumes
that
tools
follow
that
path
where
and
so
far.
B
The
reason
why
I
frame
it
is
like
it's
a
little
bit
abstract,
but
it's
kind
of
the
way
that
the
introspection
system
is
originally
designed.
It
should
always
be
safe
to
say,
like
I'm,
a
brand-new
client
I,
don't
care
about.
What's
deprecated
I
only
want
to
know
what
is
like
the
new
fresh,
safe
piece
of
the
schema
to
use
then
like
that
should
always
be
a
safe
subset
to
use.
K
Learning
in
traditional
other
other
languages
and
stuff,
you
think,
usually,
when
you
get
a
warning,
you
can
fix
it.
There's
some
physical
way
and
many
groups
have
been
in
there's
like
you
know,
you
want
to
get
rid
of
all
your
warnings.
It
is
a
little
weird
as
a
like
as
a
programming
language
concept
to
have
their
system
tell
you
warning
this
is
deprecated.
You
know
you
can
stay
there
for
two
years,
but
please
get
off
it
as
soon
as
you
can
and
today
there's
no
possible
way
to
to
get
out
of
it,
because
it's
recording.
J
K
J
E
L
Like
that,
just
to
be
clear
on
what
we're
doing
here
like
when
we
mark
a
when
we
potentially
marked
a
required
input
as
deprecated,
there
is
a
way
to
move
off
of
it,
because
the
version
that
replaces
it
that
doesn't
have
that
input
at
all
has
already
been
released.
When
that
happens.
So
the
way
to
move
off
of
it
is
to
upgrade
the
API
version
that
you're
using.
J
Yeah,
there's
not
a
way
without
that
upgrade
similarly
like
if
I'm
on
Python,
2.7
and
I'm,
using
something
and
like
I'm,
using
something
that
does
not
exist
or
yeah.
That
doesn't
exist
anymore
in
Python
3,
but
there's
no
or
is
deprecated
in
Python
3,
but
there's
no
corresponding
Python
2
version
of
it
in
like
in
of
the
good
stuff
from
Python
3
I.
C
Instead
of
for
a
client,
a
warning
for
the
schema
creator,
and
so
then,
and
instead
of
making
it
a
hard
validation
when
you're
creating
your
schema,
yeah
I,
don't
know
there
is
a
standard
schema
validator
right
now,
but
if
there
were,
you
know,
comforting
pr2
that
that
would
say
hey
you're,
putting
deprecated
on
this
non
knowable
field.
You
probably
don't
intend
to
do
that
unless
your
shopify.
B
L
C
E
Think
it's
tied
to
version
necessary
because
what's
happening
in
quiz
is
sometimes
people
actually
duplicate
our
comments
and
ask
you
to
call
another
function.
What
if
you
try
to
split
one
field
into
two
fields,
and
basically
like
say
you
cannot
use
it?
You
don't
need
a
new
version
to
split
existing
fields
into
two
new
new
fields
and
basically
say
if
you
use
this
argument,
yeah
button
that
case
will
probably
duplicate
the
entire
field.
Okay,
so
many
scratches
it's
not
well
conserved
and
so
like
to
move
discussion
forward.
E
Like
second
issue
person
person
voice
on
PR
it's
about,
should
we
change
the
logic
of
include
duplicated,
because
he's
worried
that
old,
graphical
versions
not
aware
that
arguments
can
be
duplicated.
Should
we
like
try
to
address
that,
like
my
personal
position?
Is
that
we
concentrate
new
features
we
just
not
compatible
with
old
graphical
version
like,
for
example,
repeatable
directives,
so
graphical
versions
not
know
that
you
can
repeat
certain
directives.
So
if
you
write.
K
E
E
B
I'm
that
doesn't
bother
me.
You
know
I
I'm,
I'm,
more
worried
about
backwards.
Compatibility
than
for
its
compatibility.
You
shouldn't
make
a
change
such
that,
like
every
version
of
graphical,
should
support
all
old,
schemas
or
all
old
servers,
but
every
version
of
graphical
can't
possibly
support
all
new
features
like
it
can't
know
what
new
features
will
come
and
I
think
that
would
be
too
limiting.
B
B
But
you
know
I,
don't
know
if
it
would
have
been
the
right
decision
to
say
we
can't
do
repeatable
directives
because
existing
tools
don't
know
about
that,
and
it
seems
like
it's
probably
the
right
thing
here
too,
with
leaving
include
deprecated
as
false
that
matches
up
with
how
the
other
things
are
working
from
a
from
a
toolings
point
of
view.
That
argument
just
vanishes
like
it
doesn't
there's
the
concept
of
the
deprecated
argument,
isn't
something
that
a
tool
knows
how
to
deal
with
right
now.
So
it
would
just
disappear
from
the
schema
I
think.
F
F
I
always
feel
like
there's
there's
effectively
two
behaviors
for
this
deprecated
there's
this
like
actually
omitting
it
from
the
introspection
query.
So
we
don't
clog
up
new
clients
with
all
these
fields
that
they
don't
care
about,
but
there's
also
the
the
tooling
aspect
where
we
actually
want
to,
as
in
the
case
of
Shopify,
we
want
to
notify
developers.
These
are
the
parts
of
the
schema
that
aren't
going
to
be
supported
when
you
upgrade
to
the
new
version,
which
is
obviously
a
lot
of
us.
F
Do
graph
cure
with
our
versioning,
but
graph
kill
with
versioning
is
perfectly
valid
as
well,
and
many
large
providers
do
version
their
graphical
schemas.
So
there
is
still
definitely
value
in
that.
So
I
wonder
whether
whether
these
two
things
effectively
need
some
kind
of
separating
or
whether
there
needs
to
be
a
softer
rule
on
it.
So,
as
as
Yvonne
says
like
potentially
like
for
input
arguments
if
they
are
required
and
they're
marked
as
deprecated,
we
include
them.
Even
when
include
deprecated
in
introspection
is
false.
F
E
I
think
we
actually
starting
to
go
on
the
side
of
forbidding
duplication
of
unknowable
fields
because,
like
I,
actually
want
to
move
this
feature
for
world
and
if
we
introducing
a
concept
like
a
wooden
core
anything
new
it
stuck
with
it.
So
I
think
like
let's
start
from
like
right
now,
you
don't
have
any
way
to
duplicate
arguments.
If,
if
initially
we
took
harder
approach
off
lake,
forbidding
you
to
duplicate
unknowable
people
will
start
using
that
and
we'll
see
how
bigger
is
demand
for
making
unknowable
arguments
duplicated.
E
B
That's
right,
I,
sorry,
I,
just
I,
don't
understand
the
the
suggestion
here.
Are
we
suggesting
that
we
should
take
this
as
it
is
now
and
move
it
forward,
or
should
we
are
we
suggesting
that
we
should
include
schema
switch
mark
argit's
as
deprecated
should
not
most
but
should
ensure
that
they
are
not
required.
E
Required
arguments
even
as
they
duplicated
its
mimic,
it
potentially
can
break
some
to
Liaquat,
as
you
said,
and
some
existing
to
Lincoln.
Maybe
some
work
new
tooling.
If
person
don't
bother
to
redo
pre-k
that
stuff
to
us,
as
you
said,
like
initial
idea
for
included
included,
deprecated
was
to
stay
for
us
and
to
provide
quite
a
free
schema.
E
E
F
I
feel
like
deprecated,
isn't
really
like.
I
mean
it's
exposed
in
sto
as
a
directive,
but
it's
not
really
a
directive
and
similarly
for
other
directives
that
make
schema
changes.
So,
for
example,
if
you
say
like,
oh,
this
is
a
user,
and
then
you
tag
it
as
at
connection,
and
it
builds
a
tower
as
a
connection
instead,
which
you
could
do
with
a
transform
through
a
directive
was
constructing
a
schema.
F
E
Yes,
so,
like
maybe
yeah,
maybe
it's
like
implementation,
yet,
oh,
but
I
try
to
push
as
much
as
possible
validation
as
early
as
possible,
so
everything
that
can
can
be
validated
to
next
year.
I
try
to
do
next
year.
So,
basically,
we
will
have
validation,
rule
in
I,
see
saying
if
it's
like
required
view,
if
it's
unknowable
and
it
doesn't
have
the
fault
value
yeah.
E
E
B
Still
feel
like,
we
need
that
that
rule
otherwise
I
feel,
like
it's
gonna,
be
too
easy
for
us
to
create
pitfalls,
especially
since
Steven
your
point
that
defaulting
this
to
false,
which
means
that
existing
tools
will
not
see
deprecated
arguments
until
they
include
the
ability
to
do
so
means
that
this
is
actually
a
real
problem,
and
you
know
I,
don't
think
we
should
make
it
required.
It
should
be
a
should
rule,
which
means
actually
like
the
implementation
could
lag.
C
E
B
B
There
are
other
examples
of
graphical
j/s
of
disabling
rules,
there's
like
flags
that
can
be
passed
in
I
know,
and
so,
if,
in
the
future,
we
find
that
somebody
wants
to
explicitly
disable
that,
and
that
might
be
an
avenue
that
we
could
explore.
I
think
it's
better
to
come
out
of
the
gate
with
something
that
is
the
thing
that
we
think
is
the
least
foot
gun.
Okay,.
E
E
B
Feel
super
confident
about
this,
especially
now
that
we've
talked
through
this.
This
last
potential
edge
case
I
would
say
that
this
is
totally
ready
for
stage
2,
noting
that
there's
this
like
last
piece
that
we
want
to
get
onto
the
spec
and
then
that
way
you
can
as
soon
as
you
get
to
probably
across
an
emergent,
you
can
go
ahead
and
merge
it.
Okay,
good
anybody!
Disagree
with
that.
F
F
J
That's
so
right,
I
still
feel
like
that's
a
little
bit
weird,
especially
because
clients
like
as
a
client
side,
mostly
tool,
developer,
it's
very
easy
to
have
like
a
at
Facebook
deprecated
or
an
ad,
whatever
deprecated,
that
I
can
apply
everywhere
and
by
default
becomes
at
deprecated,
but
in
the
one
weird
edge
case
where
I
have
like.
Oh,
it's
a
required
input
like
now
my
clients
so
basically
like.
J
B
That's
the
problem:
yeah
yeah
I
think
the
question
is
just
whether
it
should
be
a
must
or
it
should-
and
you
know
Evan
already
pointed
out
one
case
where
it's
reasonable
to
not
have
that
rule,
and
in
that
scenario
that
implies
that
you
have
some
control
over
the
tooling
stack,
which
Shopify
does
to
a
large
degree.
So.
J
A
K
K
J
L
B
I,
don't
think
we
need
an
answer
right
now
because
sounds
like
the
next
actions
are
we're
gonna.
Add
this
as
a
schema
validation
rule
to
Jas
and
therefore
it's
on
the
I'm
gonna.
Do
it
side
of
the
should,
which
is
what
it
should
be
doing
for
a
reference
implementation.
We
can
leave
this
this
decision
or
whether
to
go
for
a
sugar.
A
must.
It's
literally
a
one
word
change.
B
So
even
if
we
come
back
next
meeting
and
you've
done
that
analysis
and
you
find
out
that
oh
yeah
actually
making
that
a
must
is
gonna,
be
a
hard
breaking
thing.
That's
gonna
cause
a
ton
of
problems
for
Shopify
and
that's
an
example
of
probably
they're
they're,
probably
more
than
just
Shopify.
That
has
that
kind
of
pattern
and
that
informs
that
should
is
the
right
thing
and
if
you
think
that
it's
reasonable
to
adjust
from
there,
then
maybe
we
can
keep
it
as
a
must,
but
I
agree
with
Matt.
B
K
K
L
The
distinction
between
like
it
that
or
rather
the
our
inability
to
make
that
distinction
is
why
we
ended
up
treating
decremented
inputs.
The
way
we
do,
which
is
that,
like
from
the
way
we've
been
treating
deprecated
like
the
real
deprecated
as
well
as
our
fake
input,
deprecations
etapa
fide
it
is
purely
informational.
It
is
purely
like
this
is
gonna,
go
away
at
some
point
and
it
can't
it
can't
be
used
to
communicate
anything
more
than
that,
and
so
it's
totally
fine
to
communicate
that
about
a
field.
L
C
L
B
Expectation
there
was
that
if
something
in
your
graphical
schema
was
deprecated,
there
should
be
an
immediate
action
that
you
can
take
to
resolve
it
and
the
implication
there
was
that
your
API
was
not
versioned.
So
you
should
be
able
to
tweak
your
query.
Your
client-side
query
in
some
way
in
order
to
get
around
the
deprecation
and
that
that's
the
reason
why
it's
set
up
that
way.
But
evan
you
mentioned
that
there's
you
already
have
something
in
place
to
communicate
deprecation
of
arguments
and
an
input
fields.
L
B
L
Have
a
deprecated
flag
on
our
internal
schema
definition,
if
you
put
it
on
a
field,
it
turns
into
directive.
If
you
put
it
on
a
and
input,
then
it
just
tag
tag,
something
appending
it
on
to
the
description
of
that
input.
I
see
and
either
way
it
triggers
some
logging
on
our
end,
so
we
can
see
who
is
using
deprecated
values
so.
F
That
actually
brings
nicely
onto
what
I
was
gonna
mention
so
you're
doing
the
the
tag
onto
the
description
approach,
which
is
I,
think
quite
common
at
the
moment
in
because
we
don't
have
this
ability
to
add
graphical
extensions
to
two
types.
But
that
is
something
that
I
think
has
been
talked
about
quite
a
few
times.
I'd
be.
F
E
Have
senior
PR
for
doing
two
stage
introspection,
so
my
person
plan
was
to
do
two
stage
introspection
when
the
war
us
to
to
have
extensions
inside
introspection
types
so
and
we
need
to
stage
introspection
for
other
things,
but
basically
I'm
stuck
because
we
migrated
into
typescript.
So
that's
why
I
want
to
flush
all
the
pipeline
of
proposals
with
like
unique
argument,
name
deprecated
stuff,
so
to
focus
on
touch
script,
migration
and
don't
do
like
two
things
in
parallel,
especially
experimenting
and
kind
of
have
something
how
cropped
down.
F
B
G
It's
just
a
little
bit
awkward,
if
you
we
had
to
say
that
is
final,
not
being
present
would
imply
that
it
was
true
which
is
kind
of
a
little
bit
of
an
awkward
condition
when
you're
coding
around
it.
So
we've
flipped
it
in
it's,
calling
it
as
next
so
how's
next,
not
being
there
means,
as
Nexus
pulse
and
everything
load
on
a
everything
love
this
part
of,
like
the
query
that
has
defer
a
stream
will
have
has
next
present
on
it.
So
I
just
updated
that
in
RFC.
G
It's
definitely
my
first
time
writing
something
like
this,
so
it's
not
expecting
it
to
be
anywhere
close
to
ready
to
be
merged,
but
I
think
that
it'd
be
good
to
start
getting
some
early
feedback
and
the
graph
q
oj
SPR
is
up
to
date
with
just
about
everything.
That's
in
there
with
one
exception
that
I'm
still
working
on
and
that's
the
ability
to
return
async
iterators
from
resolvers.
G
B
That's
super
exciting,
a
small
thing.
Would
you
mind
splitting
your
pull
request
into
two
one
that
hits
your
RFC
stock
and
then
the
other
one?
That's
against
the
spec
yeah.
All
job
is
I'm
happy
to
merge
in
the
RFC
improvement
house.
Next,
thanks
for
reframing
that
I
had
forgotten
exactly
the
context
there,
but
yeah.
This
makes
a
lot
of
sense.
The
idea,
let
me
restate
it
to
make
sure
I'm
understanding
it
correctly.
If
you
get
a
payload
and
the
house
next
property
just
straight-up
doesn't
exist.
E
It's
kind
of
cool
that
in
connections
back
in
row,
a
connection
spreads
that
is
people
mostly
most
of
the
IP
I
using
for
pagination.
The
also
have
a
field
has
next
page,
so
with
our
consistency
and
it's
similar.
So
it
was
confusion,
not
something
not
a
new
concept
seen
so
I
stream
is
basically
also
pagination
or
Samsung
in
some
sense.
H
Think
it's
feedback.
It's
a
roast
point
yeah
first
time,
we've
writing
an
RFC.
So
there's
anything
missing,
I!
Think
we'll
get
the
reference
implementation
in
line
of
code
I!
Guess
it's
in
line
with
the
speaker
supporting
executables
and
then
beyond
that
yeah.
Just
any
input
to
say
we
should
change
anything
or
if
it
makes
the
thing
that
would
be
really.
E
I
think
it's
important
distinguish
should
be
like
encourage
people
to
experiment
with
with
so
expect,
because
we
have
some
resources
in
a
way.
We
have
a
Twitter
account
like
Garfield
Foundation,
have
a
book,
and
this
is
recently
start
actually
posting
on
it
about
stuff.
So
we
feel
it's
in
a
stage
that
we
are
ready
to
encourage
people
to
start
using
it
as
experimental.
E
Maybe
it
were
to
use
or
a
conditional
resource
to
like
shout
out
and
say
like
it's,
this
experiment
place
and
permit
like
do
it
in
a
way
that
if,
if
we
change
it,
it
will
not
break
anything
production
but
like
experiment
with
it.
I
think
like
it's
a
big
feature,
so
we
need
some
real
experimentation
because
before
we
will
be
sure.
B
Yeah
this
is,
it
might
actually
be
a
good
reason
to
wait
on
the
spec
edits
and
but
be
proactive
about
the
reference
of
a
plantation
changes,
because
if
we
can
get
the
reference
implementation
changes
in
place
and
it's
great
that
we've
been
having
these
conversations
right.
So
there's
y'all
from
first
dibs
I
know
the
handful
of
folks
on
the
Facebook
team
have
been
contributing
as
well.
B
B
H
B
E
E
It's
actually
good
timing,
because
we
knew
contributor
and
we
clean
up
the
code
base.
So
it's
a
it's
a
right
time
for
us
to
to
walk
into
it,
because
we're
also
thinking
about
first
stable
release,
Express
the
rocket
as
good
that
actually
miss
it,
and
mr.
e
re-released
an
interview
it
Rosa
its
address.
My
question
and
another
thing,
which
was
also
super
cool
for
previous
big
change.
Interface
implemented
interfaces
is
to
have
a
article
explaining
at
the
community,
so
I
think
like
when
we
merged
into
graphical
dress.
We
have
actually
systematic
in
graphical
dress.
E
We
have
systematic
problem
with
documentation.
It's
like
it's
outdated,
it's
not
like
so
I,
think
temporal
substitution
and
actually
working
good.
A
company
thing
would
be
to
have
article
somewhere
like
Express
graph.
Here
we
must
crackle
just
Express
the
rocky
release,
both
packages
and
somebody
published
a
book
post
in
release
notes.
We
refer
to
a
book
post,
so
people
know
how
to
use
it
and
what
to
do,
and
what
is
the
stage
of
it.
Things
like
that.
B
Nice
all
the
more
reason
for
getting
this
merged
and
enabled,
with
a
pretty
easy
to
turn
on
experiment,
flag
I
noticed
that
the
Express
graph
QL
changed
requires
you
to
use
the
NPM
graphical
experimental
version
as
a
death
dependency,
which
is
kind
of
interesting,
but
I,
guess
that's
as
close
as
you
can
get
with
the
way
that
it's
set
up
at
the
moment,
but
this
I
think
this
will
work
out
quite
well
I'm.
Looking
at
that
that
pull
request-
and
it
looks
like
exactly
what
you
would
hope
you
would
see
have
on.
B
So
you
know
one
thing:
that's
great
is
the
the
subscriptions
spec
required
like
a
live
connections,
WebSockets,
something
like
that
I
pretty
sophisticated
back-end.
This
really
doesn't
like
any
existing
Express
server
could
should
really
be
able
to
start
opting
into
different
stream.
So
it
seems
like
this
is
something
we
could
enable
for
the
majority
of
existing
graph
QL
services
without
a
ton
of
changes
since
HTTP
chunked
encoding
is
just
not
that
difficult
to
enable.
B
B
I'll
I'll
add
a
link
in
the
agenda
file
under
one
of
the
bullets
in
this
just
so
that
we
don't
lose
track
of
it.
F
This
is
awesome.
One
other
thing
I
wanted
to
mention.
Rob
is,
since
we
have
the
the
graphical
over
HTTP
working
group,
we're
not
yet
in
a
state
they're
two
to
merge
the
the
different
stream
stuff
into
the
the
spec.
We've
not
even
got
our
version,
one,
which
is
only
meant
to
cover
basic
queries
and
mutations,
but
we
are
working
towards
there.
It
would
be
great
to
have
the
specification
of
the
HTTP
network
for
that
over
over
on
that
project.
G
F
L
I
think
actually,
we've
largely
covered
this
one
already.
It
was
mostly
a
question.
I
was
talking
to
Andy
and
we
were
both
not
sure
what
the
next
step
was
to
get
that
merged.
Now
that
the
reference
implementation
is
in
the
reference
implementation
for
in
graph,
no
js'
exists
now
for
the
scalar
URLs,
and
so
the
spec
should
just
be
merchantville,
but
I
think
we
covered
that
when
you
said
you
wanted
to
do
to
do
an
editorial
pass.
So
yeah.
B
E
E
B
Like
the
single
point,
I
wanted
to
write,
I
think
we.
We
actually
discussed
this
in
a
previous
meeting
as
originally
those
examples
included
stuff
about
time
and
some
other
scalars
that
have
a
lot
more
variability.
I
think
URLs
are
widely
agreed
upon
and
their
formatting
and
there's
a
super,
clear
and
pretty
old,
IETF
RFC
doc
that
describes
them,
and
that
was
the
reason
why
we
decided
to
use
that
one
I
think
UUID
was
the
other
example
that
was
put
in
here.
That
one
also
is
like
extremely
well
specified
and
agreed
upon.
B
E
But
with
our
decision
to
have
like
repo
with
specs
and
weight,
so
technically
I
expect
yeah
like
her.
She
would
be
the
same
but
as
example
with
date
and
time,
sometimes
we
need
to
restrict
it
more
to
make
it
more
compatible
or
add
some
clarification
or
some
examples.
So
basically,
if
it's
improbability
for
for
URL
and
yogi
is
like
it
probably
one
of
top
top
dense
colors.
So
at
some
point,
if
we
set
up
with
repo
somebody
will
add
Adam
in
the
repo.
E
So
we'll
have
one
example
through
like
actual
thing,
would
reference
graph
kill
the
dog
scours
or
something
yeah
and
stuff
in
a
specular
reference
RFC?
So
that's
why
I
actually
want
to
change
it
to
example.com
you
ad
example.com
URL
or
something
which
is
always
always
understand,
direct
it's
a
little
bit
worse
in
a
sense
in
a
sense
of
illustrating
how
you
should
reference
with
URLs.
But
it's
asking
I.
B
Honestly,
I
think
that
might
be
more
contrary.
I,
don't
know,
maybe
it's
a
more
controversial,
but
certainly
I
don't
have
personally
at
least
I.
Don't
have
a
problem
with
anybody
writing
their
their
schema
in
this
way
that
points
to
these
I
ATF's
I
see
what
you
mean,
though,
if
they
just
kind
of
cargo
cult
the
pattern
and
put
in
the
date
time
one
and
then
that's
perhaps
under
specified
I,
do
want
to
make
sure
that
these
examples
are
are
real
and
understandable,
so
they
can't
like,
if
they
just
have
the
word
example
all
over
them.
B
L
So
I
think,
for
completeness
sake.
You
would
really
like
for
URL
you'd
want
a
dot
that
says
reference
the
IETF
spec
and
also
serialize
it
as
a
string
which
is
like
technically
an
addition,
but
I
think
if
we're
in
practice
for
a
lot
of
these
scalars
like
that,
can
almost
be
implied
and
similar
to
to
Lee's
point
like
these
are
examples.
We're
not
we're
not
mandating
any
of
this,
so
I
think
we
can
figure
it
out
and
do
their
end
editorial
change
it
to
the
right
place
at
some
future
date.
Yeah.
B
Maybe
one
thing
because
I
think
URL:
nobody
has
ever
I'm
fairly
certain
that
the
ITF
RFC
for
URLs,
don't
say:
here's
the
string,
formatting
of
URL,
here's,
the
binary
formatting
for
like
euros
or
strings.
That's
just
well
known
so
I,
don't
know
that
we
could
add
anything
for
URL
UUID,
on
the
other
hand,
does
actually
like.
There
is
some
potential
ambiguity
there.
Maybe
because
there
is
like
a
binary
representation
of
a
UUID,
even
though
graphical
doesn't
have
a
binary
type.
Hopefully
it
should
be
obvious
on
how
to
interpret
that.
B
But
daytime
is
a
great
example
where
there
is
ambiguity,
and
you
have
to
be
clear
about
the
serialization
rules,
and
that
requires
a
wrapping
document.
But
I
don't
know.
Maybe
we
can
split
the
difference
here
and
say,
like
we'll,
have
one
example
for
URL,
since
that
one
should
be
pretty
non-controversial,
but
we
could
have
another
one.
That's
you
know
something.
That's
that's
more
exotic
and
they
specified
by
can
be
an
example.
B
E
But
actually
I'd
like
work
like
a
vendor
in
Europe
to
show
that
yeah,
actually
I
hadn't
work
very
visited.
It
will
benefit
both
cases
and
it
shows
that
it's
over
the
pressure
on
our
project
of
standardizing
scours.
If
people
like
feel
that
they
it's
normal
to
use
vendor
specific
stuff,
they
will
be
was
pushy
about
pushing,
say,
scours
to
be
like
standard
I
think
it's
actually
beneficial
in
general.
B
B
B
But
you
can
kind
of
point
to
the
latest
version
of
a
particular
spec
and
it
has
a
super
low
barrier
to
entry
for
anyone
who
wants
to
add
a
spec.
So
there's
no
like
approval
process
or
working
group
like
there
is
for
this
one,
but
the
trade-off.
There
is
none
of
the
specs
none
of
the
scalar
specs
there
would
be
official.
It
would
just
be
a
centralized
place
to
track
them
all
and
therefore
a
centralized
place
to
search
over
all
of
them
and
I.
B
Think
that's
really
the
value
that
we
would
get
is,
if
you
wanted
to
say,
like
hey,
is
there
a
spec
for
date
and
you
find
that
there's
like
13
of
them
and
then
you
can
go
pick
the
one
that's
most
reasonable
for
you
or
send
a
pull
request
to
improve
an
existing
one.
I
think
that
could
be
a
really
healthy
part
of
the
ecosystem
of
scalars.
B
So
that
was
cool,
great
great
discussion
about
the
pieces
that
we
wanted
to
build
and
we
started
a
new
repo
for
that
and
I.
Think
Andy
has
already
migrated
some
of
his
initial
prototype
into
that
repo.
So
some
some
progress
happening
there.
Something
that's
interesting
to
you
feel
free
to
check
out
that
repo.
It's
in
the
the
graphical
github,
org
I,
think
it's
just
called
graphical
dash,
scalars.
B
All
right
well
for
those
of
you
in
the
u.s.
happy,
Independence,
Day
and
long
weekend,
hope
you
get
a
chance
to
go
hiking
or
grill
outside
or
shoot
a
firework
for
the
rest
of
you
around
the
world
thanks
for
joining
late
in
the
day
and
hope
you
enjoy
your
evenings
and
for
those
in
Canada,
happy
Canada,
Day,
that's
right!
Happy,
Canada
Day
was
that
yesterday,
yes,
okay,.