►
From YouTube: GraphQL Working Group (Secondary, EU) - 2023-01-19
Description
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools. Get Started Here: https://graphql.org/
A
Having
one
of
those
days,
I
keep
justifying
my
third
coffee
as
well
at
least
I'm,
not
drinking
energy
drinks
that
have
three
times
the
caffeine
in
them.
So
you
know
I'm,
okay,
I,
think
at
some
point,
I'll
be
on
to
the
energy
drink,
kick
and
probably
be
drinking
three
of
those
a
day.
Anyways
I.
B
A
I
I
totally
do
that
and
get
the
do.
You
get
the
whole
mass
of
caffeine
headache
thing
too,
which
is
just
super
frustrating
but
yeah.
It
takes
about
four
days,
I
find
for
those
headaches
to
just
kind
of
go
away
where
I
start
to
feel
normal
again,
and
then
it's
usually
about
four
days
before
I
get
back
onto
the
caffeine,
so
yeah
yeah,
very
much
how's,
the
how's,
the
weather.
B
A
B
A
A
A
E
A
Would
have
done
the
same
thing
so
yeah
like
I,
get
it
and
then,
but
you
did
make
it
on
time.
Somebody
picked
you
up
and
then
drove
you.
E
A
E
A
Oh,
it's
funny:
yeah
Derek,
Derek
who's
sometimes
joins
these
calls.
I
was
talking
to
him
about
that
because
he's
from
Poland
and
I
said
hey.
So
how
close
are
these
places
he's
like
yeah,
not
very.
G
E
A
E
B
I
I
certainly
had
a
few
questions.
I
I
did
wonder
if
it
was
a
little
bit
of
of
filling
time.
One
of
the
things
I
really
liked
that
they're
that
they
do
is
they
give
free
t-shirts
to
anyone
who
asks
a
question.
Oh.
E
Is
a
really
good
idea:
yeah
I
mean
the
mirror
meal.
People
are
really
really
quite
nice.
People,
I
would
say
one
of
the
Polish
that
I
met
yeah.
Well,
like
they're,
more
like
the
Americans
like
this
easy
going.
You
know
what
I
mean
yeah
just
standing
in
a
queue
somewhere
and
they
start
chatting
is
chatting
that's.
C
A
That's
great
where
they,
knowing
you
were
getting
a
free
t-shirt
for
asking
a
question:
did
that
impact
the
quality
of
the
questions
or
were
they
still
all
pretty
good?
Oh.
E
E
Yeah,
my
in
my
q,
a
there
also
like,
and
they
were
asking
a
lot
of
questions
but
good
quality
questions.
That's.
E
I
mean
that's
actually
I
that
that,
if,
if
you
go
to
conference,
speak
there
and
you
have
an
audience
that
really
asks
a
lot
of
questions,
it's
kind
of
nice
as
a
speaker,
because
you
know
okay,
people
reflected
on
what
you
actually
totally
talk.
There
yeah.
A
A
Feels
it
feels
a
little
bit
strange
when
you
don't
you're
at
a
conference
and
there
isn't
room
for
questions
in
a
lot
of
ways,
because
you
don't
have
a
way
to
gauge
to
to
calculate
that
engagement,
so
yeah
Miss
Lee
the
host
today
or
you
Benji.
Sorry.
B
Lee
has
just
asked
me
to
to
host
today
for
something
else,
so
that
was
a
kind
of
a
last
minute
thing.
I
think
I
think
we're
still
waiting
on
yeah,
Cove
and
mats.
Yes,
I'm
reading
the
right
agenda,
yeah,
Governor,
Matt,
but
I
think
we
we
may
as
well
get
started.
So
as
a
reminder.
By
joining
here,
we
oh
about
the
band's,
not
on
the
list.
B
B
Let's
go
through
and
do
an
introduction
of
attendees
we'll
do
it
in
the
order
that
it
is
in
the
agenda.
With
the
exception
of
me,
first
hi,
everyone
I'm
Benji,.
B
Foreign,
thank
you
iPhone,
okay,
so
volunteers
for
note-taking
I
have
just
updated
the
agenda
document,
so
the
link
to
the
live
docs
does
now
work.
B
So
if
someone
could
take
notes
or
if
multiple
people
could
take
notes,
that
would
be
incredibly
helpful.
Is
anyone
able
to
do
that.
B
E
B
Okay,
let's
have
a
look
at
the
agenda
for
today,
so
we
are
gonna,
do
a
review
of
the
of
the
primary
meeting
and
I
guess.
If
anyone
was
there,
a
review
of
the
secondary
meeting
as
well
would
be
ideal.
Matt
has
just
arrived
and
I
think
Matt
was
probably
there.
So
if
you
could
do
that
in
a
moment,
that
would
be
fantastic.
A
quick
summary
of
that
last
week's
meeting.
B
After
that,
we
will
have
a
quick
glance
over
the
action
items,
I'm
not
aware
of
any
of
those
having
Advanced,
but
do
let
me
know
if
they
have
then
we'll
go
to
Rob
for
defer
and
stream
updates,
which
is
quite
exciting
and
then
on
to
Roman
for
a
discussion
of
what
backwards
compatibility
means
for
the
graphql
spec.
Is
there
anything
that
we're
missing
from
the
agenda
or
that
anyone
wants
to
add
to
the
agenda.
J
I'm
happy
to
sorry
a
bit
hectic
I'm.
If
there
is
time
I've
discussed
this
in
the
past
too,
so
it's
not
necessary,
but
I
can
do
a
quick
call
to
action
on
fragment
arguments,
but
it's
basically
just
like
I'm
gonna
put
stuff
up.
People
can
start
reviewing
it.
It
should
be
in
a
reviewable
state.
B
Sounds
good
yeah,
hopefully
the
other
two
items.
Major
items
are
20
minutes
each.
So
hopefully
there
will
be
time
fantastic.
All
right!
Thank
you,
everyone!
So
the
last
meeting,
well,
the
primary
meeting
I
should
say
we.
What
do
we
do?
I'm
just
scanning
over
the
notes.
Now
we
had
Matt
talk
to
us
about
fragment
arguments
which
maybe
we'll
hear
a
bit
more
about
later.
B
B
This
proposal
going
strong
and
I
think
there's
General
support
for
it
for
it
from
the
working
group,
so
pretty
exciting,
happy
to
see
that
moving
forwards,
Roman
raised
about
the
pr
review
process
that
we
have
on
the
graphql
specification
itself,
there
being
pull
requests
raised
and
being
potentially
approved
by
one
or
two
people,
but
not
merged.
So
we
had
a
discussion
around
that
about
what
process
should
be
in
place.
B
Who
can
do
the
merging
what
types
of
things
can
get
merged
and
mostly
I
think
the
main
outcome
of
that
was
when
someone
approves
April
request
they
should,
in
addition
to
approving
it.
They
should
also
give
like
a
next
steps
like
this
is
approved
and
I
think
we
should
merge
it
or
this
is
approved,
but
I'd
like
to
hear
something
else
from
these
people
that
maybe
know
more
about
that
or
from
other
TSC
members
or
similar
things
like
that.
B
So
there
was
a
quite
a
nice
outcome
from
that,
then
we
had
yaakov
talking
about
the
default
value,
validation,
status,
checks
where
yaakov
has
rebased
work.
That
Lee
has
previously
done.
I
believe
this
is
still
waiting
on
lead
to
advance
it
further,
but
it's
a
massive
amount
of
work
that
Jacob
has
done
to
make
it
current
again,
which
is
great,
thank
you
Yakov
and
then
updates
on
defer
and
stream,
which
I
will
not
summarize,
because
I
think
Rob
will
hopefully
do
that
for
us
later
fantastic.
B
B
No
I'm
just
having
a
scan
through
I
know.
A
couple
of
these
are
waiting
on
me
as
well.
No
okay,
well
we'll
skip
over
that
and
take
you
straight
to
Rob,
then
please.
D
Yeah,
so
we
had
another
meeting
earlier
this
week
on
Monday,
which
is
now
a
recurring
Monday
meeting
to
talk
about
defer
and
stream,
and
we've
been
going
over
this
problem
of
clients
identifying
if
defers
are
inlined
or
not
as
well
as
streams
and
it's
kind
of
been
evolving
a
lot
of
the
behavior
of
how
a
deferring
stream
will
work.
D
D
Yeah,
so
the
first
of
which,
being
the
suggestion
that
we
remove
labels
entirely
and
merge
all
deferries
that
are
under
the
same
object
together.
So
I
have
an
example
of
that.
We
have
this
list
of
items
and
a
whole
bunch
of
deferred
fragments
under
there,
with
a
slightly
overlapping
but
different
selection
set,
and
the
results
would
be
basically
one
defer
for
each
of
these
items
since
they're
all
under
the
same
object,
they'll
get
merged
together,
they'll
be
treated
as
one
defer
and
we
have
the
three
fields
that
are.
D
The
combination
of
the
two
I
think
that
this
is
not
controversial.
At
this
point
and
but
there's
somewhat
of
a
consensus
around
this,
there
was
the
one
issue
that
I
brought
up
last
time
was
this
case
where,
if
you
have
defer,
is
nested
like
this,
we
definitely
want
to
make
sure
that
you
do
only
get
one
defer
per
path.
D
So
in
this
case,
there's
two
payloads
one
with
the
path
at
the
root
where
you
got
this
nested
object
here
and
another
one
where
you
get
both
Foo
and
bar
they're
merged
together.
The
the
algorithm
I
was
originally
working
with,
did
not
do
that,
but
Yakov
has
done
a
lot
of
work
on
this
and
has
an
algorithm
that
does
do
this
and
I
think
that
makes
things
pretty
nice
where
you
should
not
need
a
label.
You
can
use
the
path
and
you
can
know
whether
something
was
inlined
or
not.
D
You
can
you
know
you
can
know
you
can
uniquely
identify
the
payloads
based
on
the
path
and
just
the
one
other
caveat
is
that
while
we
had
said
that
servers
can
choose
to
inline,
deferred,
fragments
for
performance
reasons,
I
think
that
if
a
server
does
inline
something
it
should
either
it
should
either
honor
all
the
deferries
that
are
at
this
object
or
inline
all
of
them.
D
So
this
way
there
isn't
a
case
where
I
got
this
path
back,
but
only
half
of
the
payload
is
there
half
of
it
was
in
line
I,
think
that
could
be
confusing
for
clients
and
I
broke
this
out
to
a
separate
issue
now,
which
is
how
to
handle
the
deduplication
of
deferred
fields.
That's
this
example
that
we
that
we've
been
kicking
around
there
isn't
really
a
clear
answer
on
this,
but
just
want
to
highlight
this
example.
D
D
Both
of
these
are
requesting
the
field
EF
and
there's
these
two
Fields
here,
which
one
of
them
may
be
slow,
maybe
the
other
one's
fast,
and
if
the
deferrer
for
this
payload
is
sent
first,
that
it
would
be
okay
to
drop
EF,
because
the
client
already
has
that
data,
but
I
think
that
it
would
be
dangerous
to
drop
EF
if
this
payload
is
coming
later,
because
now
a
client
that
maybe
has
a
fragment,
that's
tied
to
a
UI
component
that
expects
all
these
fields
to
be
there
at
the
same
time
wouldn't
be
so
the
way
the
last
update
from
the
meeting
is
we
were
discussing.
D
I
Yeah
I
spoke
with
Benoit
and
what's
interesting
at
least
like
in
apple
or
kotlin.
There
is
like
imagine
of
stuff,
so,
like
all
this
stuff,
that
I
was
saying
you
need
to
have
normal
rest
or
something
similar
like
there
are
already
Howard
I
I'm,
not
sure
if
I
or
was
a
client
to
have
it
or
not.
But
since
we're
like,
since
we
already
can
invite
some
fields.
I
They
duplicate
some
Fields.
You
need
to
do
magic
anyway,
between
at
least
between
initial
payload
and
like
one
of
the
defaults.
We
need
to
match
it
because
it's
like
the
duplication,
so
we
first
coins
do
to
do
magic
anyway
and
what's
interesting,
I
think
I
figured
out
by
talking
with
benowa
I
figure
out
that
you
can
do
labels
and
do
duplication
at
the
same
time,
which
is
interesting
like
because
previously
we
we
had
labels
attached
to
a
shape.
I
So
if
you
specify
a
fragment
with
specific
web
or
you
get
the
swayable
and
specific
shape
together,
but
it's
not
working
with
matching
what.
Instead,
you
can
do
and
like
like
still
figuring
it
out
how
to
solve
all
edge
cases.
You
can
have
like
a
path,
and
you
can
have
like
such
a
way
fulfill.
The
labels
in
every
pair
was
saying
like
after
after
this
I
would
getting
matched.
I
There
is
enough
data
to
fulfill
this
visual,
so
I'm
I'm
here
right
now,
sorry
yeah
and
it
was
very
insightful
to
talk
about
because
now
I
understand
how
like
clients,
work
and
especially
like
coins
that
do
co-generation
in
static
languages,
I
think
it's
the
most
complicated
use
case
for
a
clients
for
what
specific
feature.
A
I
I
think
currently
what
it
can
be
done
without
labels,
but
there
is
some
much
cases
about
duplication
right.
F
Yeah
I
think
I
think
it's
yeah.
It
should
be
possible
for
at
least
for
us,
in
our
case,
for
Apollo
Kathleen
to
do
something
without
labels.
But
what
you
were
thinking
about,
even
with
still
keeping
label,
so
looks
good
too.
So.
F
So
yeah
I
guess
waiting
for
something
more
concrete
there,
so
we
can
can
look
at
it
and
compare.
I
Yeah
and
the
way
both
Bernard
explained
me
why
it's
hard
for
for
a
client
to
check
like
if
it's
enough,
that
or
not
in
in
current
situation,
where
we
have
like
initial
response
and
one
big.
I
E
Do
you
have
use
cases
because
the
way
I
I
don't
see
the
the
the
use
cases
anymore
for
it,
because,
with
the
constraints
that
we
now
have
actually
what
does
the
label
help?
You.
I
So
level,
one
of
the
thing
label
allow
us
to
currently
without
initial
response
and
a
single
D4
at
at
most
single
D4
per
path
right.
It's.
I
I
One
thing
and
if
invisible,
what
we
can
do
we
can?
Oh,
my
electricity
was
is
down
sort
of
picture,
but
but
you
hear
me
right:
yes,.
I
When
you
talk
about
when
we
talk
about
the
duplication,
you
you
said
like
being
situation
when
One
Pilot
need
to
wait
on
another
pivot,
they
were
kind
of
in
in
a
walk
State,
because
you
don't
know
what
what's
coming.
First
with
labels,
you
can
like
ship
data
as
you
want
and
just
Mark
when
certain
label
is
fulfilled.
That's
all
you
don't.
E
With
slavery,
we
introduce
all
the
other
issues
that
we
just
got
rid
of.
I
A
web
of
Splash
shape.
Previously
we
have
like,
with
this
idea
that
label
require
you
to
ship
everything
in
one
I
will
find
Mobile
it's
hard
to
explain
these
words.
It's
even
had
like
couple
examples,
and
we
are
now
more
or
less
on
the
same
page.
What
I
want
to
try
so
I
will
yeah
I
wanted
to
add
on
all
the
details,
but
now
I
see
maybe
like
other
people
will
help
me
so
not
to
quarter
the
threat.
I
will
open
a
separate
one
and
give
example
of
what
I'm
thinking
right
now.
C
A
To
your
examples
in
discussion,
64.
Ivan,
because
it's
not
a
cluttered
thread
yet
it
was
just
started.
Rob
broken
out
as
a
separate
thread.
C
E
C
D
You're
thinking,
if
I
understand
correctly,
that
we're
not
we're
no
longer
going
to
have
the
basically
like
one
defer
like
a
single
defer,
could
correspond
to
multiple
responses,
and
you
would
use
the
label
to
know
when
all
of
the
responses
added
together
mean
that
that
label
is
completed.
I
Yeah
yeah,
absolutely
like
100.
You
got
the
idea,
so
we
have.
We
can
have
more
than
one
by
what
per
per
oh,
so
server,
ships
stuff
as
they're,
ready
server
can
do
like
button
or
it
can
ship
like
any
field
separately
and
client
is
signalized
when
just
signal
wise,
when
amount
of,
if
you
match
everything
you
get
all
the
fields
for
particular
fragment,
which
is
like
idea,
yeah.
E
E
Because
with
that,
so
just
just
to
wrap
it
up,
I
don't
want
to
spend
too
too
much
time
on
it
without
having
really
something
to
read.
But
the
idea
was
like:
if
you
want
to
duplicate
data,
shapes
and
break
them
out
into
separate
deferred
passes,
you
could
use
a
fragment
aliasing.
E
D
Yeah
I
feel,
like
the
important
part,
isn't
specifically
about
the
label,
but
it's
about
the
changing.
The
contract
that,
like
a
single
defer,
could
yield
multiple
results,
maybe
with
different
paths
or
something,
and
then
the
label
is
just
a
way
to
point
back
to
it,
but
it
could
probably
be
done
in
another
way.
Yeah.
D
E
G
Us
I'm,
not
I'm,
not
sure
I,
think
I
would
reward
that
a
little
bit.
I
think
what
Ivan
is
saying
is
that
me.
Let's
say
we
take.
We
we
don't
reintroduce
labels.
Ivan
is
is
still
suggesting
that
I
think
that
we
could.
G
We
could
ensure
the
all
a
complete
deduplication
of
data,
so
I
mean
it's
a
different
solution
than
fragment
aliases
but
ensure
complete
deduplication
as
long
as
we're
free
to
spend-
and
you
know,
order
Independence
as
long
as
we
are
free
to
you,
know,
send
multiple
send
the
same
path
multiple
times
and
then
separately
signal
when
when
the
Deferred
fragments
have
been
completed,
but.
E
The
the
way
I
under
understood
to
know
that
is,
if
you,
if
you
label
a
fragment
right,
then
we
cannot
merge
out
the
fields,
because
you
want
to
have
that
essay.
Yeah.
I
They're
not
working
on
a
particular
payload.
It's
not
working
they're
working
on
merge
a
tree
of
all
the
payloads
up
to
this
point.
So
it's
not
matter.
If
you
how
you
split
stuff,
it's
like
quite
a
parade
with
much
tree
with
fully
mostly
so
Jason
from
my
first
response,
initial
response
and
all
subsequent
response
up
to
responders
merged.
I
So
it
doesn't
matter
like
what
what
they,
what
had
What
fields.
The
question
is:
if
this
much
spray
would
have
enough
data
to
fulfill
fragment
or
not,
but.
E
Wouldn't
this
this
counter
the
the
use
case
where
you
have
fragments
differed,
and
you
need
to
really
know
if
the
fragments
are
fulfilled.
I
Yeah,
so
here
is
a
here
is
a
strict
like.
Instead
of
you
need
the
way
to
signalize
that
particular
fragment
is
fulfilled,
and
but
so
you
don't
need
to
in
previous
iteration
initial
iteration,
we
tied
fragment
to
very
tight
label
to
a
shape
so
pivot
with
the
label
had
all
the
fields
for
wet
fragment.
Here,
it's
like
the
average
yeah
we're
taking
too
much
time
from
all
other
discussion.
If
you
look
at
got
really
good
suggestionado
added
to
Fred
64
right
yeah,.
I
Yeah
actually
to
the
duplication
and
as
Mike
non-working
stuff
so
like
if
certain
fragments
need
like
two
fields
and
another
few.
Another
fragment
need
like
two
other
fields
on
the
same
path:
they're,
not
waiting
for
each
other.
They
can
be
fulfilled
independently
in
different
Pilots.
G
That
we
could
solve
through
through
other
means,
I
mean
this
seems
like
the
the
the
main
new
use
cases
and
I
mean
I'm,
just
highlighting
that
because
I
think
well,
yeah
I
think
that's
the
main
new
thing
here.
I
think
it's.
G
But
it
was,
the
question
is
whether
how
you
know
whether
or
the
benefit
pros
and
cons,
I
guess
for
their
cost
benefits.
Yeah
yeah.
I
So
you're
right,
the
duplication
is
mine,
one
because
for
me
it's
like
really
bad
objects.
We
promise
shipwreck,
remove
duplication
and
triple
only
data
that
you
need,
but
we
should
work
in
duplication
in
graphql
response.
For
me,
it's
like
it's
like
a
contradict
somethings
and
a
second
thing
is
like
we
have
this
Assumption
of
one
default
per
path,
so
I
think
it
should
be
like,
as
many
differs
as
server
once
eventually
like
it's
still
much
to
single
object,
so
yeah
I
will
work.
I
A
good
idea
is
to
provide
like
benefits
of
that
approach.
I
will
do
section
on
web.
B
Fantastic,
thank
you
for
the
discussion.
Everyone
and
I
guess
we're
all
looking
forward
to
the
outcome
of
Monday's
meeting
there.
A
H
Can
you
see
it?
Yes,
all
right,
so
backward
compatibility,
I
made
a
big
post
yesterday.
I
actually
thought
that
there
is
nothing
on
agenda.
If
so,
why
don't
we
discuss
this
turns
out?
There
are
other
important,
maybe
more
important
things
on
agenda
and
that's
okay.
So,
but
we
have
time
now
to
discuss
this.
This
is
I,
think
seemingly
deceptively
trivial
topic,
but
I
think
it
matters,
and
sometimes
it
gets
in
the
way
and
backward
compatibility.
H
Yes,
it's
important
thing,
but
when
sometimes
discussing
something
anybody
mentions,
oh
it's
backwards,
incompatible
and
then
suddenly
everybody
starts
running
away
screaming.
No,
no,
no!
No!
No!
No
and
that's
actually
a
kind
of
kills
all
discussion,
and
it's
not
the
place
in
particular
other
topic
to
discuss.
Does
it?
Is
it
really
backward
compatibility
issue
or
not,
and
that's
why
I
think
it
deserves
a
separate
discussion
to.
H
To
decide
on
the
issue
what
it
is,
what
is
not
and
make
sure
that
we
are
kind
of
on
the
same
page,
so
I
hope
you
guys
read
the
this
long
post,
sorry
for
being
so
long,
but
I
think
I
I
described.
This
is
my
opinion.
H
My
view
and
I
would
like
to
hear
your
opinions
and
I
suggest
to
break
it
in
two
parts,
and
essentially
the
first
part
is:
let's
do
warm-up
and
look
at
one
particular
issue
and
it's
kind
of
important,
because
it
is
the
issue
in
the
spec
the
backwards
compatibility
mentioned
in
the
spec
in
regards
to
deprecated
directive
and
I.
H
Think
that's
where
the
term
is
used,
the
reference
to
backward
compatibility
is
used
incorrectly
and
I
think
it
should
be
fixed
and
let's
look
at
this
and
exchange
opinions
to
see
how
actually,
we
think,
and
that
probably
will
show.
H
Maybe
any
differences
in
our
understanding
of
the
backwards
compatibility.
So
basically,
the
section
about
deprecated
directive
says
that
this
directive
is
to
support
the
management
of
backward
compatibility
and
I.
Think
it's
incorrect,
because
deprecated
is
about
incompatibility
that
is
coming,
and
this
is
a
warning
that
the
code,
your
code,
if
you
use
this
field,
it
will
be
incompatible
and
it
will
break
so.
This
is
the
opposite
of
backward
compatibility.
H
Backward
compatibility
in
general,
as
I
discussed
previously
in
this
post
is
means.
Simply
old
code
continues
to
work
with
new
version,
with
upgrades
with
everything
if
you
have
old
code
written
10
years
ago,
but
if
the
infrastructure
is
Backward
Compatible,
it
means
that
it
continues
to
run
just
like.
We
can
run
today.
Applications
on
Windows
that
were
written
20
years
ago,
Windows
versions
are
backwards
compatible.
Your
old
code
continues
to
run
while
deprecated
is
a
signal
of
coming
incompatibility,
but.
E
H
E
H
They
do
not
recommend
it:
yes,
because
they
they
have,
they
actually
forced
to
use
oh
versions
as
Backward
Compatible,
but
they
kind
of
strongly
recommend
and
they
do
not
guarantee
actually
that
it
will
continue
to
work
in
your
applications.
But
the
thing
is
yeah,
it's
it's
a
separate
issue,
but
basically
what
I'm
saying
is
that
this
is
about
incompatibility,
and
probably
the
explanation
should
be
rephrased
like
this-
that
it
helps
to
manage
the
gradual
evolution
of
applications.
H
So,
inevitably,
if
you
have
an
application,
graphql
application
and
when
time
goes,
new
features,
I
mean
end
application
features
added
removed.
So
you
need
to
make
sure
that
it
doesn't
have
some
abrupt
break
effect
on
your
clients
and
that's
how
you
manage
it.
You
put
an
early
warning
so
that
they
can
see
and
they
can
take
action.
B
So
I've
got
a
couple
of
opinions
on
this.
First
of
all,
as
Michael
points
out,
the
deprecated
directive
doesn't
mean
that
that
thing
has
to
go
away.
It
can
just
be
saying
that
this
used
to
be
the
way
that
we
did
things,
but
now
it's
better
to
use
this
alternative
pattern,
which
is
maybe
more
efficient
or
some
other
Improvement.
B
It
doesn't
mean
that
there
has
to
be
a
breaking
change
coming
up
in
the
graphql
schema
sorry,
so
it
doesn't
necessarily
mean
that
there
is
going
to
be
an
incompatible
change.
Secondly,
I
would
say
that
the
management
of
backwards
compatibility
does
include
saying
when
that
backwards
compatibility
will
stop.
That
is
management
of
backwards
compatibility.
We
are
maintaining
backwards
compatibility
whilst
we
have
the
deprecated,
but
at
some
point
in
the
future
we
may
lose
that
backwards,
compatibility
that
is
still
management
of
it.
So
I
think
the
terminology
isn't
used
incorrectly.
B
There
I
do
quite
like
the
correction
or
the
the
alternative
wording
that
you've
got
there.
However,
the
advanced
warming
warning
to
clients
about
upcoming
changes
in
the
schema.
B
It
isn't
necessarily
upcoming
changes
in
the
schema,
as
I
said
before
it
could.
Just
be
changes
that
have
happened
and
now
there's
a
more
efficient
way
of
doing
this
thing,
so
it
could
just
be
changes
to
the
schema
rather
than
upcoming,
but
other
than
that
I.
Actually,
quite
like
the
wording
that
you
have
here.
H
E
No,
it's
still
not
incompatible,
it's
more
like
if
you
are
building
a
new
application
with
it
or
you're
updating
an
application
with
it
use
the
other
field
like
I
re
I.
Remember
that
Mark
Andre
was
talking
about
that
day
in
in
one
second
in
GitHub,
they
were
like
adding
in
the
text
that
okay,
this
field
is
not
any
more
than
most
efficient,
but
please
use
the
other
field
here,
so
it
could
also
be
just
that
you're
pointing
people
to
as
Benji
said,
to
a
more
efficient
way.
H
Well
again,
I
think
that
although
we
do
allow
that
these
deferred
fin
stays
forever
and
that's
probably
big
vendors,
what
they
prefer
to
do
to
keep
it
there
if
possibly
forever.
H
But
basically
it's
a
signal
do
not
use
this,
even
if
the
more,
if,
if
it's
only
a
more
efficient
way,
but
then
you
have
duplication
of
functionality
in
schema,
and
it's
just
recommendation
change
the
code.
H
H
But
okay
anymore
opinions.
I
I
Yeah
on
this
particular
issue,
because
I
understand
we're
discussing
quite
a
general
topic
of
backward
compatibility
in
a
schema,
but
for
this
particular
one
small
topic
about
deprecated
directive
I'm
like
I,
agree
that
current
tax
is
wrong
and
the
policy
of
what's
deprecated
and
if
it's
removable
it
just
discouraged,
it
should
like
be
up
to
a
person,
maintaining
particular
graphql
server.
So
in
a
chat,
I
suggest
formulation
that
we
should
just
say
like
deprecated,
discourage
usage
in
a
new
client
and
it's
to
notify
old
coins
to
migrate
to
some
new
functionality.
I
I
might
I'm
against,
like
heaven,
animation
of
like
removal
or
breaking
changes
because,
like
as
as
Michael
point
out,
wait
it's
up
to
it's
up
to
maintenance
to
decide
if
breaking
changes
are
coming
or
not.
C
I
Yeah
is
what
we
want
to
client
to
do
so
we
want
one
to
do
two
things.
Do
not
use
this
thing
and
change
a
code
odd
code
to
move
away
from
it
like
everything
else
we
don't
know
like
here-
is
it's
pretty
concrete,
so
in
graphical
deprecated,
stuff,
I,
think
it's
not
suggested
by
default
and
after
completion
and
if
duplicated
stuff
is
already
inquiry,
it's
like
a
strikethrough,
so
you
basically
show
a
person
you
should
make.
It
should
change
it
to
something
else.
I
H
No
I
I'm,
actually
not
suggesting
that
we
put
it
there
that
something
like
statements
like
data
that
this
might
go
away,
but
at
least
I.
What
I
hear
is
that
we
kind
of
agree
that
we
should
reformulate
this
paragraph
and
something
like
along
the
lines
that
it
helps
evolution
as
I,
say:
I
I,
don't
quite
like
myself.
They
suggested
sentence,
but
I.
Ask
you
guys
for
help
to
maybe
the
the
better
phrasing
of
this
paragraph
and
we
we
can
probably
I
I,
have
with
suggestions.
H
I
can
make
a
PR
to
change
this
and
I
suggest
to
remove
mentioning
of
backward
compatibility
in
this.
That's
essentially
just
to
yes,
I
understand
it's.
What
was
expressed
in
the
comments
that
it
might.
It
might
mean
it
goes
away.
It
might
not
mean
goes
away,
but
let's
just
get
rid
of
this,
because
I
think
it's
improper
place
to
reference
it
in.
H
In
this
case,
it's
a
evolution
of
the
schema
and
transmitting
the
warning
to
change
the
code
and
that's
what
actually
is
against
suggestion
to
change
the
code
and
that's
what
a
kind
of
gets
against
the
notion
of
backwards
compatibility,
which
means
you
don't
need
to
change
the
code.
I
Ide
yeah
yeah
would
be
great
like
support,
because
as
understand
you
want
to
to
make
this
discussion
bigger
and
discuss
like
horseback,
but
like
can
you
create
separate
there
for
just
like
for
this
deprecated
directive
text?.
H
Yes,
that's
what
I'm
talking
about?
Okay,
no
and
I,
actually
don't
other
than
that
I,
don't
suggest
any
more
changes
regarding
this
in
the
spec
entire
spec.
What
what
I'm
the
the
goal
of
this
discussion
is
to
set
up
our
own
kind
of
understanding
for
the
future
cases
when
it
suddenly
pops
up
the
subject
of
backwards
compatibility.
Everything
else
looks
fine
for
me
in
the
spec
and
I
I.
Don't
challenge
it!
H
Okay,
we
can
move
on
to
the
second
more
General
discussion
of
the
subject.
Basically,
my
suggestion
is
this
basic
principles
for
the
spec,
so.
H
H
If
we
have
restrictions,
something
is
not
allowed
to
do
like
recursive
fragments
in
we
remove
it
in
most
cases,
it's
it's,
of
course
Case
by
case
basis,
but
in
general
it
should
be
okay
backwards,
compatible
because
old
code
doesn't
use
recursive
fragments.
It
should
never
run
into
this
issue.
Now,
regarding
what.
E
Is
if
we
phrase
that,
like
that
it
depends,
it
depends
removing.
H
Restrictions
can
also
like
that's
the
case
yeah
Case
by
case
yes
I,
say,
but
in
general,
the
the
mere
fact
that
we're
removing
restrictions
should
not
be
immediately
or
no
so,
and
what
I'm
arguing
the
important
Point
primary
concern
is
with
existing
apps
and
their
graphql
assets,
schemas
and
code.
H
So
our
primary
concern
that
they,
we
don't
break
them
so
that
the
application
written
10
years
ago,
using
some
old
stuff
only
continues
to
work
and
regarding
the
spec,
the
asset,
the
schema
or
query
mutation
request,
graphql
text,
which
is
valid
for
version.
One
of
the
spec
continues
to
be
absolutely
valid
for
any
future
versions
of
the
spec.
So
it
means
that
the
primary
focus
is
the
apps
now
regarding
tools
and
Frameworks
implementing.
H
This
is
less
concerned
for
us,
because,
first
of
all,
we
we
directly
don't
have
control
and,
for
example,
the
server
framework
that
helps
build
the
applications
they
they
can
break
the
compatibility
internal
compatibility
without
any
spec
change,
just
some
upgrade
and
boom.
Everything
is
broken.
H
Mean
no,
let's
say
hot
chocolate
releases,
some
new
version,
improving
something
and
internal
API
is
broken,
and
the
old
some
old
application,
which
has
been
sitting
there
for
five
years
and
working
without
hot
chocolate,
now
stops
working
I
mean
that's
bad
case.
Of
course
you
would
never
do
this,
but
eventually
we
don't
it
might
break
because
of
the
internal
API
break,
not
because
of
spec.
H
E
So
it
I
think
even
pressed
it
very
well.
So
a
query
that
you
have
written
10
years
ago
should
mean
the
same
thing
that
it
meant
10
years
ago,
exactly.
H
E
H
Exactly
yes,
and
so,
but
what
I'm
saying
is
that
it's
the
apps?
It's
the
queries,
the
graphql
assets
that
our
concerned
and
libraries
and
tools
they
should
make
the
teams.
The
makers
should
make
their
own
effort
to
make
sure
that
they
are
backwards,
compatible
internal
repairs
and
so
on,
but
it's
less
our
concern
as
as
an
illustration
of
how
this
issue
comes
up.
For
example,
graphql
assets
versus
tools,
I
want
to
bring
up
to
your
attention.
Benji's.
H
Just
yesterday
posted
this
update
to
extract
RFC
and
once
sentence
that
actually
triggered
me.
Look
at
this.
It's
selected,
I'll
read
it.
However,
it's
talking
about
allowing
input,
objects
as
outputs
so,
and
it
reads
like
this,
however:
It
suffers
from
some
backward
compatibility
concerns,
namely
that
an
input
object
being
used
on
output
is
likely
to
confuse
existing
tooling
such
as
graphical
and
it's
entirely
unknown
to
them
whether
an
input
object
should
require
a
selection
set
or
not,
and
I
think
this
is
a
kind
of
a
wrong
reasoning.
H
Basically,
what
it
says
is
that
all
tools
might
break
if
they
encounter
some
new
functionality
unknown
to
them.
Of
course,
they
will
so.
Basically,
let's
look
at
the
extreme
scenario
like
this:
it's
exaggerated,
but
I
think
it's
illustrate
the
point.
So
let's
say
there
is
a
developer
today,
who
is
build
some
application
and
he
installed
graphical.
As
of
the
latest
version,
2023
then
10
years
passes
by
is
2033..
We
advance
the
spec.
We
introduced
lots
of
stuff
there.
E
E
So
the
the
one
thing
I
think
that
is
important
is
that
that
change
has
a
cost
to
the
to
the
ecosystem.
So,
ideally,
if
we
can
do
things
without
breaking
change,
I
would
always
prefer
no
breaking
change,
because
then
we
don't
pay
the
cost
in
the
ecosystem.
H
Wait
wait,
wait,
wait
but
listen.
So
we
do.
Let's
say
we.
We
advance
the
spec
right
for
10
years.
We
did
introduce
otherwise
what
the
hell
are
we
doing
here.
So
let's
say
we
did
introduce
some
very
useful
features
and
they
would
justify
it
based
on
change
in
10
years
the
user
opens
his
old
graphical
and
tries
to
use
the
latest
things
and,
of
course
it
breaks.
H
Of
course
it
breaks
because
it
it
doesn't
know
about
input
as
output,
about
the
new
Strat
thing
and
defer
and
stream,
and
so
on
so
yeah.
E
E
Because
I
can
use
all
the
old
features
and
graphical
will
just
work
with
it.
I
I,
don't
say
that
this
is
the
default
state
or
is
with
with
every
feature
we
have
to
decide
and
that's
why
Benji
correctly
outlines
here
a
couple
of
options
and
outlines
the
the
cost
of
each
option.
E
H
Yes,
of
course,
and
I'm
not
saying
that
we
are
doing
change,
but
if
we
can,
but
realistically
in
the
real
world
as
we
advance,
we
introduced
new
things
that
will
break
and
I
give
an
example,
for
example,
that
I
tried
to
introduce
to
introduce
inputs
as
outputs
and
it
did
break
the
graphical
in
one
part,
no,
it
didn't
crash
it
continued
to
work,
but
it
didn't
show
me
anything
in
the
schema.
H
B
No
in
general,
I
would
say
yes,
it
does
mean
that
we
shouldn't
do
this,
and
the
reason
for
that
I
would
say,
is
I,
find
it
very
hard
to
draw
a
line,
as
you
have
done,
between
apps
and
tools
and
libraries,
you
take
graphical
as
an
example.
It's
actually
a
really
good
example.
It's
a
really
good
counter.
Example.
Graphical
is
designed
to
be
embeddable
in
projects,
and
there
are
many
products
on
the
market
that
embed
graphical,
there's,
hasura,
Apollo,
hot
chocolate,
postgraphile
to
name
just
a
few
off
the
top
of
my
head.
B
It
is
extremely
widely
used
and
widely
embedded
into
various
different
graphql
projects
and
when
I'm
talking
about
projects,
I
mean
like
the
the
apps,
as
you
call
them
people's
actual
businesses,
they
are
used
by
internal
Tooling
in
massive
companies
as
a
one
of
the
primary
ways
of
querying
particular
apis.
So
if
you
break
that
tooling,
by
doing
an
update
to
graphql
but
not
doing
an
update
to
the
actual
project
itself,
the
app
as
you
call
it,
you
have
broken
that
app.
B
H
Should
no?
No,
no,
you
are
you're
bringing
different
Keys.
You
are
talking
about.
Yes,
it
is
part
of
the
app.
But
the
question
is
this
old
app.
It
will
never
use
the
new
features
because
it
doesn't
know
about
them.
This
old
app
will
continue
to
work
and
all
graphical
will
continue
to
work
because
the
assets,
the
queries-
they
don't
use
the
news
I'm
talking
about
the
situation
when
user
opens
the
old
graphical
and
tries
to
use
it
as
usual.
You
know.
Oh,
the
latest
thing
allows
me
defer.
I
will
try
to
use
it
yes,
defer.
H
Syntactically
is
just
a
unknown
directive,
but
oops.
Suddenly
it
starts
returning
some
stuff
after
returning
the
main
response,
you
know,
and
this
will
break
so.
The
question
is
the
use
of
new
stuff
in
old
version,
and
so
this
particular
issue
that
all
old
versions
from
10
years
ago
should
be
compatible
forward
compatible
because
this
is
actually
forward
compatibility,
the
but
then.
E
You're,
the
new
misery,
then
you're
misreading
I
think
what
Benjamin
wrote
here
it's
about
when
you
upgrade
inputs
of
an
old
test,
so
you're
upgrading
your
graph
with
structs,
for
instance.
E
Well
in
this
particular
case,
it's
about
introspection
right,
Benji,
yeah,
so
introspection.
For
instance,
if
we
introduce
a
new
type,
could
break
a
lot
of
tooling
because
suddenly
we
we
are
introspecting
and
getting
this
new
type,
so
we
haven't
supported
exceptional
or
whatever,
and
that
is
a
cost
that
the
ecosystem
pays,
and
we
should
be
very
careful
with
with
doing
that.
E
B
B
B
An
input
object
and
allowing
it
to
be
queried
through
the
output
system
as
well,
so
allowing
it
to
be
used
in
both
directions
and
in
Roman's
example.
This
caused
an
old
graphical
that
was
pointed
at
a
schema.
Using
this
functionality
to
to
not
even
start
up
is
what
I'm
understanding
it
through
an
error
like
a
schema,
validation
error
like
I,
can't
understand
this
schema
How.
Can
there
be
an
input
object
here?
It's
for
output.
H
It
didn't
break
it,
it
break
only
part.
The
introspection
when
it
queries,
tries
to
show
me
the
schema.
This
query
failed
because
it
encountered
field
in
output,
object,
output
field,
it's
supposedly
the
types
of
output
of
objects.
Types
should
be
either
primitive
types
or
output
objects,
but
it
encountered
that
this
field
returns,
input,
object,
input
type
and
it
had
broken
one
part.
It's
refused
to
continue
and
just
didn't
show
me
the
schema
so
basically
yeah
it's.
Yes,
it
is
breaking,
but
it's
not
backward
compatibility.
H
We
should
not
expect
from
you
call
it
existing
tooling,
like
graphical
and
basically
it's
old
tools.
We
should
not
expect
them
to
be
automatically
forward
compatible
with
changes.
H
We
do
because
it's
inevitably
we
do
changes
that
might
break
the
tooling,
but
they
don't
break
the
old
apps
old
apps
will
never
return
any
field
with
input
a
type,
so
basically
old
apps
will
continue
to
work
and
all
schemas
will
continue
to
work
even
with
graphical,
updated
or
not
it's
only
when
we
try
to
use
it
with
a
new
schema
that
uses
input
objects
as
type
of
the
output
field,
then
it
freaks
out.
But
what
I'm
saying
is
that
this
is
inevitable
and
you
should
not
call
it
backwards
compatibility.
C
H
Give
advanced
warning
and
they
fix
the
code.
I
Yeah,
so
we
have
like
with
design
principle
or
photography.
I
It's
in
a
dock
I
send
the
link
in
the
chat
and
citation
from
there
and
basically
like
we
have
strict
guarantees.
We
cannot
break
so
like
any
proposal
that
change
like
that
phrase
that
I
send
you
sorry
I
cannot
link
like
in
particular
paragraph
because
it's
a
markdown
document,
so
I
just
send
the
document,
but
you
can
quickly
find
the
backward
country
yeah
so
Michael
you
posted
it
one
more
time.
I
So
idea
is
that,
with
with
like
things,
we
cannot
break
like
introspection
query
also
acquiry
and
people
like
we
can
never
know
like
if
it's
query,
introspection,
queries
used
in
in
developer
development
time
time
to
link
or
it's
used
in
production.
People
use
enough
values
for
drop
down.
Lists
like
in
transaction
queries
normal
query.
So
there
is
no
distinguish
between
queries
that
query
data
and
queries
that
require
schema.
I
But
what
particular
phrase
basically
say
if
you
have
like
the
same
schema
and
the
same
query,
but
you
update
graphql
like
execution
engine
Library,
whatever
right,
spec,
algorithms,
nothing,
nothing
should
change.
You
should
get
the
same
shape
and
the
required
should
still
be
valid
and
executed
and
you
get
the
same
shape.
We
cannot
break
what
so
in,
like
100
cannot
break
well.
So
we
guarantee
that
in
case
of
introspection,
it
basically
guarantees.
If
you
don't
change
your
schema,
it's
mean
and
it's
been
like
introspection.
All
the
introspection.
I
Query
should
return
quite
the
same,
and
it
should
make
sense,
but
so
I
can
think
that
Venture
Point
out
in
his
RFC
it
doesn't
break
that
principle
because
it
requires
you
to
start
using
struct
in
in
your
schema.
So
you
change,
schema
yeah,
an
old
query
like
returns.
I
think
shape
is
the
same,
but
like
content
inside
doesn't
make
sense
for
old
clients.
I
So
I
would
say
it's
not
it's
not
like
preventing
us
from
from
imagining
it,
but
I
agree
with
boundary.
It's
like
significant,
it's
great
like
a
problem
and
like
a
system
so
like
I'm
I'm,
for
distinguishing,
like
backward
compatibility,
that
we
have
in
design
principles
and
that
we
absolutely
cannot
wait,
break
and
and
stuff
like
Avenger
point
out,
but
doesn't
fit
what
at
the
same
time,
it's
like
can
be
a
problem
for
community,
so
I
would
say
like
I'm,
okay,
with
what
we
have
like
now
in
design
principles,
it
can
be
like
extended.
I
We
can
add,
like
some
examples
to
it
and
all
the
other
issues,
because,
like
some
stuff,
we
discussed
during
when
we
had
deprecation
for
for
arcs
people
like
had
some
some
had
some
like
similar
problem,
but
we
still
measured,
and
it
was
like
examples
when
we
changed
sdl
syntax.
We
also
break
like
two
link
that
consumers
there.
I
So
what
thing
can
happen,
but
if
you
can
avoid
it,
it's
better
to
avoid
it
I'm,
just
like
not
mixing
for
not
mixing
two
things
together,
like
our
compatibility
promise
that
we
have
in
design
principle
and
like
backward
compatibility
like
bigger
promise
of
backward
compatibility.
That
can
be
used.
As
argument
for
saying
like
with
which
version
of
a
change
buttons
on
this
version
of
a
change,
both
of
them
can
be
applied
in
theory,
but
this
one
is
better
because
it
was
breaking
so
I'm,
pretty
distinguishing
with
two
things
and
not
mixing
them
together.
H
So
but
basically
I
I
didn't
quite
understand
these
two
things,
but
you
are
from
the
first
part.
You
are
insistent,
so
this
phrase
in
The
Guiding
principles
that
the
query
should
be
written
should
mean
the
same
thing
should
never
break
and
the
results
that
it
delivers
should
should
not
break.
You
essentially
say
that
this
also
applies
to
introspection
queries
as
well,
so
it
means
that
introspection
queries
should
never
bring
anything
that
breaks,
but
then
what
about
subscriptions
when
you
introduce
was
it
against
the
principles
because.
C
I
I
E
No
old
queries
work
as
well
as
they
used
to
before.
A
good
example
is
also
differ
in
stream.
It's
a
huge
change
to
the
spec,
but
anything
old
will
work.
E
From
it,
doesn't
it
doesn't
give
you
guarantees
that
new
stuff
works?
So
if
you,
if
you
put
the
defer
directive
actually
on
something,
then
your
whole
tooling
might
not
understand
that.
E
E
B
B
This
is
more
to
do
with
making
sure
that
the
tool
itself
can
still
operate
can
look
at
a
newer
schema
and
not
just
crash,
because
the
new
schema
uses
new
features.
It
doesn't
mean
that
the
new
features
have
to
be
usable
in
the
old
client.
It
just
means
that
they
have
to
not
break
it.
I'm
very
conscious
of
time
and
I'd
like
to
give
Matt
a
chance
to
talk
about
the
fragment
argument.
So
if
that's
okay,
I'd
like
to
move
us
on
to
Matt.
J
So
part
of
this
is
just
I've
talked
about
it
now
at
APAC,
at
the
APAC
meeting
in
the
main
meeting
want
to
give
everybody
in
Europe
a
chance
to
basically
know
what's
going
on.
The
short
of
it
is
I'll
post
in
the
discussion.
I
have
a
new
working
group.
Discussion
can.
J
Yeah
all
I
should
all
I'll
update
the
working
group
as
well,
but
that's
a
new
discussion.
It's
empty
right
now,
but
it
points
to
two
clean
PR's
on
graphql,
JS
and
graphql.
Spec
I
will
update
this
with
the
open.
J
J
I
was
doing
this
last
minute
today,
which
is
why
it
didn't
get
on
the
agenda
before
the
meeting,
especially
as
I
was
having
issues
with
prettier,
whatever
so
yeah,
basically
I'm
still
making
progress,
I
think
the
short
of
it
is.
We
took
I
took
the
input
about
variable
using
variable
definitions.
J
Instead
of
a
new
argument:
definitions,
node,
that's
applied
everywhere,
I
attempted
to
do
scoping
like
properly
scoping
in
graphql.js
and
in
the
spec
and
I'm
opting
not
to
do
proper,
like
have
a
scope,
object
that
gets
passed
down
and
instead
do
essentially
AST
replacement
in
both
the
implementation
and
the
spec,
and
the
logic
for
that
is
the
Delta
of
like
spec
changes
and
implementation.
Changes
goes
down
a
lot,
but
that's
going
to
be
an
example
of
an
open
concern.
J
J
Besides
that,
yeah,
basically
I,
think
I.
Think
the
spec
in
jsprs
are
ready
for
at
least
a
cursory
review,
but
yeah
I'll
probably
have
more
for
the
next
working
group
in
a
couple
weeks,.
A
J
Yeah,
sorry,
sorry,
it
wasn't
as
fleshed
out
as
I
wanted
it
to
be
before
this
session.
So
I'll
make
sure
just
an
action
item
for
me
that
I'll
make
sure
to
buy
tomorrow
morning
to
have
like
the
open
concerns
in
the
discussion
sections.
J
You
know,
but
the
other
thing
is
I
closed,
the
other
two
PR's,
the
old
ones
that
had
all
like
various
contexts,
including
like.
Oh,
we
should
do
this
purely
client
side
I've
closed
those
because
that
was
causing
confusion,
so
the
spec
and
jsprs
are
now
for
like
PR
discussions
like
is
this
feasible?
Is
there
something
we
need
to
consider?
Is
it
like?
Is
there
a
test?
We're
missing
is
there,
like?
Is
the
wording
off?
J
Is
this
confusing,
whereas
the
I'm
planning
to
use
the
working
group
discussion
board
basically
or
discussion
topic
for
actual,
like
we
should
consider
doing
like
using
argument
definitions
instead
of
variable
definitions,
we
should
consider
like
a
different
syntax.
We
should
consider
what
are
the
performance
concerns
going
to
be
like
there
were
questions
about,
for
instance,
graphql
Java
has
a
different
validation.
J
E
A
I
By
the
way
about
like
I
didn't
review,
but
you
mentioned,
like
a
pain
point
of
graphql,
Java
version
of
fields
can
be
much
it's
something
that
we
need
to
do
in
graphql.js,
graphql
version
like
not
a
particular
implementation,
but
in
general
algorithm.
It's
like
somebody
from
sync
who
wrote
about
it
and
it's
very,
very,
more
effective
and
like
it's
better
in
cold
like
so
just
to
notify
it's
not
graphql
Java
in
general
issue,
it's
like
if
there
is
issue
with
but
I'll
get
it
it's
like.
J
I
J
Looked
through
graphql,
Java's
implementation
and
I
will
have
a
discussion
topic
on
their
algorithm
and
why
I
don't
think
that
it's
actually
like
a
concern?
Okay,
I
might
even
I,
might
even
pull
a
PR
on
graphql
Java,
because
I
don't
think
it
should
be
that
difficult.
I
J
C
B
This
is
a
fantastic
map.
Have
you
started
looking
at
integrating
relay
with
this
current
proposal
already
yeah.
J
So
the
good
thing
is
like
in
terms
of
so
I
I
believe
relay
may
already
support
the
syntax
exactly
as
is
and
I
believe,
like
I've
talked
to
the
relay
team
about
what
specific,
like
their
concept
of
scope,
is
exactly
identical.
J
They
we
would
need
to
like
the
action
items
in
relay
I
think
would
be
allow
relays
compiler
not
to
compile
away
the
arguments
and
then
like
make
sure
that
the
client
side
works
as
expected,
but
it's
basically
the
only
thing
for
real
way
should
be
reduction
in
complexity,
not
addition,
but
all
that's.
That
is
an
action
item
for
me
to
go
over.
Realize
code
specifically
just
verify
like
their
validation,
Rules
match
and
they're
like
there's
no
mismatch,
and
if
there
is
that
we
like
resolve
it
in
some
way.
B
Right
well,
if
there's
nothing
else
on
this
topic,
I'm
happy
to
hand
it
back
to
Roman
for
the
last
few
minutes,
because
I
know
we
had
to
cut
off
your
topic
a
little
early
to
make
sure
Matt
had
time.
If
you
wanted
to
talk
any
more
about
that,
Roman.
H
So
basically,
we
kind
of
expressed
opinions,
I
kind
of
disagree
with
some
of
them,
but
let's
I
urge
you
guys
to
continue
discussion
because
I
see
what
in
some
comments
in
the
chat.
For
me,
some
of
these
interpretations
actually
actively
forbid
progress
of
the
specification,
because
treating
this
to
the
extent
that
so
much
compatibility
must
be
preserved
in
all
tools
is
too
much.
It
really
impedes
the
progress
that
we
can
make.
H
Tools
are
different
from
existing
apps
tools,
have
teams
which
are
ready
to
change
them,
improve
them
and
accommodate
upcoming
changes
so
and
that's
the
progress
that
I
think
this
is
the
best
way
kind
of
to
progress,
give
early
one
into
two
makers:
they
upgrade
the
tools
and
everything
works
for
everybody.
Yeah.
J
So
on
this,
specifically
like
one
of
the
levers
that
we
have
is
the
is
the
introspection
query.
So
we
expect
we
allow
breaking
changes.
For
instance
such
that
you
old,
tooling,
would
not
be
able
to
parse
new
versions
of
the
schema
sdl,
and
we
allow
this
because
we
expect
tooling,
to
operate
against
the
introspection
version
of
the
sdo.
So
the
introspection
of
the
sdl
is
always
done
through
a
graphql
query.
So
long
as
an
old
version
of
the
introspection
query
remains
valid
when
hitting
new
versions
of
the
server.
J
Your
old
tool
that
uses
the
old
introspection.
Query
will
like
be
able
to
reconstruct
the
old
versioning
like
the
old
spec
version
of
your
server's,
updated
schema.
J
And
so
like,
that's
the
like.
That's
the
level
of
ensuring
compatibility
with
unupgraded
servers
that
we
try
to
maintain.
So
it's
not
that
we
block
all
progress,
but
it's
like
if
you're
going
to
break
an
old
version
of
the
introspection
query,
that's
where
we
start
being
like
whoa.
This
is
a
major
thing
like
this
is
going
to
be
problematic
to
add
to
the
spec.
H
H
J
Yeah,
it
might
be
the
case
that,
like
you,
would
for
the
old
shape
of
the
introspection
query.
You
would
need
input
like
your
input.
Output
type
object
to
generate
a
differently
named
input
and
a
differently
named
output,
or
something
like
that
like
or
it's
Uncle.
Basically,
this
is
that
proposal.
Part
of
that
proposal
needs
to
be.
J
How
do
we
make
it
possible
for
this
to
work
with
old
clients
like
what
is
what
are
the
Hoops,
that
we
have
to
jump
through
to
make
to
make
output
objects
as
input
objects,
work
incrementally,
and
are
there
Alternatives?
What
are
those
Alternatives?
J
What
like
is
there
something
else
we
can
introduce
that
maybe
entire
classes
of
fields
are
lighted
from
the
schema
or,
like
these
arguments
are
lighted
from
the
schema,
if
you're
using
an
old
introspection,
query
or
there's
like
lots
of
possible
ways
to
move
it
forward,
but
that's
like
how
part
of
how
we
need
to
frame
the
discussion
is:
is
it
possible
for
the
for
old
introspection
queries
to
continue
to
work?
How
do
you
make
that
possible.
E
It's
also
like
the
the
good
discussion
is
the
import
Union
discussion
where
we
explored
in
the
beginning
a
lot
of
things
also
things
that
would
break
the
graph
curves
back
but
more
in
the
way.
Okay,
we
we
look
how
far
we
can
push
the
boundaries
and,
and
then
you
figure
out
a
way
or
a
solution
that
doesn't
break.
You
schema,
that's
so
when,
when
Benji
is
now
formulating,
the
a
couple
of
solutions
is
it
struck.
Do
we
introduce
a
new
type
to
re
reuse,
the
input,
it's
more
exploration,
work
still.
H
I
understand,
but
what
it
looks
like,
for
example,
with
this
kind
of
what
Matt
talked
about,
for
example,
automatically
generate
input
and
output
types,
similar
name,
that's
sort
of
says
kind
of
ugly
solution,
and
if
we
go
this
way
in,
let's
say
10
years,
we
will
have
some
really
strange
things
in
graphql
and
the
only
explanation
is:
oh,
that's
historical,
that's
historical
that
we
had
to
do
this
duplication
and
all
that
crap
and
it
doesn't
seem
like
a
good
way
forward.
I.
J
Mean
we
do
have,
we
do
have
a
lot
of
historical
artifacts,
like
even
when
we
were
discussing
like
arguments
that
allow
non-no
that'll
that
require
non-nullable
inputs
that
allow
you
to
pass
a
Nolan
at
execution
time,
like
that's
an
historical
artifact
of
choices
we
made
that
were
probably
wrong
in
that
we're
like
trying
to
undo,
but
we
can't
fully
undo.
We
can
only
like.
H
J
That
wouldn't
be
a
breaking
change
like
it
might
be
the
case
that
we
should
be
piling
in
a
bunch
of
like
these
are
good
features
where
if
graphql
was
starting
from
scratch,
we
would
want
to
include
them
so
that
we,
we
would
want
to
include
it
like
this,
because
if
we
ever
do
make
a
like
true
breaking
change
to
the
spec,
there
might
be
a
day
when
we
have
so
much
good
new
features
that
we
would
want
to
version
the
spec
that
might
happen
like.
That
is
a
possible
future
world.
J
We
try
our
best
to
prevent
that,
but
that's
a
future
world
and
we
should
be
like
we
shouldn't-
discourage
the
discussion
of
features
merely
because
they
can't
be
introduced
but
is
like
we
would
need
to
reach
a
value.
Add
that
would
be
rather
huge
and
probably
input
as
output
by
itself.
I
would
be
surprised
if
that,
if
we
were
willing
to
Fork
basically
Fork
the
speck
or
bump
the
major
version
just
for
that
feature,
it
probably
would
be
a
whole
class
of
features
that
we
would
want
for
that.
H
I
would
agree
again
the
focus
here.
What
is
breaking
change
and
again
I?
My
argument
is
that
we
are
all
emphasizing
the
seriousness
of
breaking
tools
with
new
features,
all
tools
versus
new
features
that
impedes
the
progress
I'm,
not
arguing
about
existing
up
code,
queries
or
schemas,
but
the
tools.
That's
what
questions
me.
C
J
So
this
like
just
as
context
on
why
we
have
this
philosophy,
is
because
graphql
was
already
so
such
a
large,
widely
used
thing
within
meta.
We
did
actually
cause
a
breaking
change
when
we
switched
to
open
source
syntax.
We
had
a
prior
version
of
the
syntax
and
we
still
have
problems
that
flow
from
that
upgrade
and
we
don't
want
the
community
that
doesn't
have
like
the
creators
of
graphql
able
to
work
through
those
issues
facing
the
same
problems.
Is
that
or
have
we
over
corrected?
J
B
J
B
Thank
you,
everyone
I
think
we
should
probably
call
it
there.
We
are
a
few
minutes
over,
but
looking
forward
to
seeing
you
all
at
the
next
working
group
and
thank
you
for
the
discussion.