►
From YouTube: GraphQL Working Group - 2022-11-03
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/
B
C
H
I'm
working
to
figure
out
the
calendar,
probably
the
problem
is
that
I
don't
have
access
to
it,
but
Elisa
does
and
so
I've
been
like
going
back
and
forth
with
her
I,
don't
actually
understand
like
where
the
source
of
Truth
is
for
it.
H
E
C
E
Actually,
time
change
differences
for
folks
outside
of
North
America
right
now,
that's
been
fun
to
navigate
as
well,
so.
F
I
H
C
E
H
F
But
even
then
I
saw
a
couple
of
these
implementation
for
timeobjects.net
and
it's
like
because
there
are
changes
like
somebody
abundance.
Maybe
oh.
E
H
H
Let's
see
we're
not
actually
expecting
a
huge
crowd
today,
if
the
agenda
file
is
accurate
yeah,
when
you
hear
one
tooth,
seven,
eight,
nine,
ten,
eleven
and
the
nominee
do
we
have
here.
H
C
H
E
H
Kicking
things
off,
of
course,
as
we
all
join,
we
agreed
to
the
spec
membership
agreement,
participation,
guidelines,
country
guide,
code
of
conduct,
all
written
documents
from
me
and
others.
As
per
usually
we
like
to
do
a
quick
round
the
room
of
names
to
faces,
we
will
go
in
the
order
listed
in
the
agenda
file.
Anyone
who's
not
in
there,
yet
just
chime
in
last
I'm
at
the
top
of
that
list.
As
per
usual.
So
hello,
everybody
good
to
be
joining
you
all
today.
My
name
is
Lee.
H
A
C
I
B
L
H
Hello,
everybody.
Thank
you
all
for
chiming
in
we
have
a
nice
tight
agenda
today.
H
Actually,
before
we
get
into
that,
I
should
make
sure
that
we
are
in
a
healthy
state.
With
regards
to
the
notes,
I
see
at
least
two
people
in
the
notes:
I'm
assuming
one
of
those
is
Benji,
since
it's
literally
up
on
the
screen.
H
H
I
just
say
three
people
in
there
now
I'll
take
that
as
oh
for
our
vehicle.
All
right,
we
got
some
people
going
there.
These
notes
end
up
being
incredibly
helpful,
so
thank
you.
Everybody
Benji
in
particular
for
making
sure
that
these
come
together.
Well,.
H
Quick
look
over
of
the
agenda
I
think,
since
we
have
a
tighter
agenda
today,
it's
worth
maybe
spending
a
decent
amount
of
time
digging
through
our
action
items,
making
sure
that
we
kind
of
prune
the
backlog
a
well-deserved
moment
to
bring
the
express
graphql
project
back
up
to
date,
interesting
discussion
on
a
deprecation
of
objects
and
then,
as
per
usual
I'm
sure
what
will
be
a
very
excellent
discussion
on
progress
on
different
stream.
E
E
F
That's
so
far,
I
would
say
it's
good
because
it's
smaller
slots,
which
I
actually
find
noise
I'm,
not
sure
about
the
Australian
spot.
Yet
so,
let's
see
how
we
go
through
that
I
hope
there
are
more
people
joining
in
there
and
as
people
learn
in
Australia
that
it's
a
thing
now,
but
let's
see,
but
you
Europe
and
and
and
then
the
primary
one
is
good,
because
we
essentially
splitted
the
meeting.
H
Yeah
yeah
we
had
a.
We
had
a
healthy
audience
for
that.
First
Asia
Pacific
one,
unsurprisingly,
mostly
folks
from
Australia
but
I'm,
hoping
that
we
can
make
a
little
bit
more
noise
and
see
that
pick
up,
but
I
think
we
had
maybe
six
or
seven
people
in
attendance,
yeah
I'm,
not
meeting.
C
F
A
K
A
We
can
use
the
official
graphical
figure.
F
H
Yeah,
let's
get
that
on
the
graphql
Twitter,
maybe
I'll
tweet,
something
about
that
later
today.
Just
to
remind
folks
that
we
have
the
one
coming
up
relatively
soon
and
just
probably
good
to
highlight
that
the
first
one
went
well
I'm,
realizing
that
one
of
the
things
that
I
should
probably
have
is
a
fixed
item
on
this
primary
one
is
sort
of
a
recap
of
those
other
ones,
since
they
are
narrow
audience
so
I'll
make
sure
that
I
get
that
set
up
for
the
next
one.
H
But
since
we're
talking
about
me
and
Cadence,
I
might
as
well
use
that
as
an
opportunity
to
do
that.
Actually,
the
first
thing
I
should
check
in
along.
There
was
last
month's
primary
meeting.
I
wasn't
able
to
attend.
Benji
ran
the
meeting
any
highlights
from
that
that
go
smoothly.
G
There
are
there
wasn't
many
people
in
attendance,
but
yeah
it
was.
It
was
fine
I
think
we
actually
shut
it
down
a
bit
a
bit
bit
early
compared
to
usual,
but
yeah.
There
was
some
some
interesting
topics,
there
I'm
afraid
I
haven't
filed
any
of
the
action
items
and,
to
be
honest,
I've
only
recently
got
access
to
zoom
again,
so
I
haven't
uploaded
the
videos
yet
either,
but
that
will
be
something
that
hopefully
I'll
get
done
in
the
next
week
or
so.
Along
with
this
meeting.
H
Glad
to
hear
it
well
I'm
glad
that
it
went
the
APAC
secondary
slot.
Had
we
had
six
folks
on
the
agenda.
I
think
that's!
The
number
of
folks
we
actually
had
in
attendance
Andy
was
very
excited
to
be
able
to
join
again
for
the
first
time
in
a
while,
and
he
brought
some
of
his
his
career
with
him.
That's
been
working
on
graphql
Java.
Unsurprisingly,
there's
there's
a
healthy
amount
of
Australian
folks
who
are
working
on
that.
H
We
also
had
I
think
Michael.
You
happened
to
be
in
Australia
exactly.
F
Was
speaking
at
the
conference
also
about
graphql,
but
apart
from
that
I
attended
from
that
conference,
so
it
was
a
good
good
start
for
the
first
meeting.
I
think.
H
C
H
H
That's
fine,
but
the
the
main
the
topic
to
shore
of
that
meeting
was
custom
scalers
and
in
particular,
picking
back
up
the
graphical
scalers
repository
and
website,
so
that
people
have
a
place
to
put
source
of
Truth
that
has
like
a
moderate
bar
for
for
Access
and
Donna,
and
Andy
had
done
a
pretty
decent
job
assembling
like
a
minimum,
viable
template
for
how
you
would
assemble
one
of
those
which
looked
great
so
we'll
see.
H
C
H
We
have
a
surprisingly
well
attended
secondary
meeting
last
month.
I
wonder
if
this
was
there's
just
like
enough
people
with
conflicts
for
the
first
meeting
last
month
that
led
to
the
Overflow,
but
we
had
is
this
like
at
least
11
people
in
the
secondary
meeting,
with
a
really
healthy
agenda,
incremental
delivery,
fragment
modularity,
which
I
don't
know
if
we
made
the
As
Much
progress
as
we
hoped,
but
that
was
a
super
interesting
discussion.
H
I
feel
like
we're.
The
next
one
was
struck,
which
feels
like
we're
still
in
this,
like
broadening
phase
of
understanding
the
problem
domain,
but
Mark
had
a
really
awesome
discussion
about
sdui
and
then
Alex
came
back
with
a
client-controlled
nullability
update
for
the
first
time
in
a
while
and
I
think
we
Stephen,
we
had
your
deprecation
of
objects
pending,
but
we
we
ran
out
of
time.
So
we'll
have
ample
time
to
talk
about
today.
H
The
other
thing
that
I
just
put
on
the
agenda
just
now
is
the
next
phase
of
the
Garfield
Community
Grant
is
launching
we're
gonna
we've
been
sort
of
like
trickling
in
submissions
just
as
anyone.
The
form
is
just
kind
of
always
open,
but
we're
gonna
officially
decide
on
granting
a
handful
of
these
close
to
the
end
of
this
month,
so
that
we
can
get
the
process
in
flight
for
them
to
be
funded,
hopefully
in
December
at
the
beginning
of
next
year.
H
At
the
latest,
there
is
an
initial
tweet
out
I'm
planning
on
making
some
noise
on
the
Discord
about
this
I
want
to
make
sure
everybody
here
knows
about
it,
especially
because
I
imagine
some
folks
here
may
want
to
apply,
but
certainly
also,
if
there's
other
channels
that
you
want
to
advertise.
This
I
think
one
thing
that
we
did
not
do
last
time.
That
could
be
quite
interesting
to
consider
this
time
is
if
there
are
projects
that
we
want
to
sort
of
like
Google
summer
of
code
style.
H
If
you
want
to
propose
a
project
we
could
consider
putting
together,
like
a
repository,
is
a
big
word
literally
just
like
a
section
on
the
the
graphical
Foundation
website.
It's
just
here
are
things
that
we
hope
people
apply
to
to
do.
H
I
think
documentation
in
particular,
is
something
that
needs
a
lot
of
love.
That
would
be
a
great
use
of
community
grants.
H
Any
thoughts
on
that
any
other
channels.
We
should
be
broadcasting
this.
G
H
You
do
have
that
maintainers
GitHub
group,
that
sort
of
partially
useful
that
might
be
a
reasonable
place
to
do
that
or
how.
H
I'm
trying
to
think
of
where
the
right
place
on
GitHub
would
be
to
put
this
like
via
GitHub
discussion.
Probably.
F
But
maybe
also
like
often
on
Twitter,
if
you,
if
you
read
if
we
retweeted,
if
you
do
something
as
the
Twitter
announcement,
sometimes
because
sometimes
you
oversee
the
GitHub
stuff.
H
Yeah,
that's
true.
It
would
be
an
interesting
project
to
collect
as
much
contact
information
around
graphql,
core
prime
or
just
like
main
project
maintainers
as
possible
names
and
githubs
and
twitters,
and
all
that
just
so
that
when
we
do
want
to
do
sort
of
like
a
big
broadcast,
we
know
how
to
reach
people.
F
H
If
anyone
has
additional
ideas,
I'm
going
to
open
a
GitHub
discussion,
let
me
see
if
I
can
do
that
right
now.
Actually,
just
so.
C
E
Tool
at
Apollo
for
doing
something
very
similar,
a
devrel
tool
called
orbit.
I'll
drop
the
link
there.
If
anybody
wants
to
check
to
take
a
look
at
it,
but
it's
really
great
at
connecting
to
things
like
any
kind
of
source
like
GitHub
is
one
of
them
and
you
can
really
easily
tag
people
that
are
pulled
in
from
different
repos
to
be
lined
up
for
communication
in
the
future.
So
you
could
have
a
mail
out.
E
H
H
Oh
yeah
yeah.
Sorry,
we
jumped
right
ahead
talking
about
new
agenda
items.
Thank
you
for
the
reminder.
Let's
look
at
those
first
as
suspected
I,
don't
think
we
have
any
tagged
as
ready
for
review,
but
it
may
be
worthwhile
just
to
do
a
calling.
We
have
some
that
have
been
open
for
a
really
long
time
and
I'm
wondering
if
we
can
just
like
close
them
as
stagnant.
H
The
best
way
should
I
share
my
screen,
so
we
we're
all
looking
at
the
same
thing.
Yeah
that'd
be
great
for
sure.
Okay,
let's
do
that
one
sec.
H
H
Okay,
any
anyone
opposed
to
me
just
starting
to
close
out
issues
that
are
old
or
any
ideas
and
how
we'd
want
to
collect
archived
issues.
G
Maybe
we
can
just
tag
them
with
like
incomplete
or
no
longer
relevant
or
won't
fix.
B
H
H
D
H
H
That
one
we're
gonna
leave
open
because
that
one
actually
is
an
open
thread.
H
H
Oh
okay,
okay,
I,
remember
the
source
of
this
Yvonne
I'm,
not
sure.
If
you
remember
this,
there
was
this
discussion
about
I
think
that
Sasha
may
have
brought
this
up
when
we're
doing
field
selection,
merging
that
we
threw
errors
around
merging
covariant
Fields.
Instead,
we
required
them
to
be
invariant
or
I
mean
the
same,
and
there
was
an
action
to
open
at
least
open
an
issue,
if
not
a
PR,
to
explore
actually
doing
this.
G
D
Ahead
yeah,
before
we
close
it,
it's
actually
elevated
to
to
another
issue
like
this
particular
rule,
causing
a
lot
of
problems,
including
performance
problems,
and
it's
like
one
of
the
most
complicated
throws.
D
We
have
at
least
like
validation,
rule
Wise,
It's,
the
most
complex
Rule,
and
it's
like
from
time
to
time.
We
have
like
some
problem
with
it
with
recursion
in
it
and
misperformance,
and
it's
some
performance
issue
even
like.
D
Email
emails
about
it,
I
think
really
was
included
on
in
emails.
I
Thread
about
this
particular
rule
about
magic
management,
fragments,
Merchant,
Fields
selection,
so
simplifying
it.
It's
like
solving
big
set
of
issues.
So
one
thing
to
be
self-conscious
about,
we
think
I
think
still
it's
important,
but
if
anybody
else
want
to
want
to
take
it
on,
especially
like
communicating
with
the
clients
and
doing
like
particular
research,
I
still
can
help
white
with
graphql
JS
implementation,
especially
since
it's
gotten
out
stuff
and
removing
stuff.
D
F
D
Not
exactly
it's
about
like
we
have
requirements,
yeah
yeah,
it's
connection
between
tabs
yeah.
If
you
know
again,
it's
yeah,
so
it's
like
just
join.
It's
a
can.
Do
their
work
with
different
types
in
response,
so.
F
Yeah
I
I,
remember
Lee,
said
that
originally
they
had
issues
with
the
Java
generator
or
something
like
this
and
that's
why
they
introduced.
Actually
the
rule.
D
G
Do
you
think
I
should
leave
it
there
Lee
and
we
can
come
back
to
at
the
end
of
the
meeting
Maybe,
which
one
just
the
other
issues.
Yeah.
H
Okay,
fair
yeah,
let's,
let's
get
back
to
because
we've
got
yeah
I,
think
we'll
probably
use
the
hour
for
the
last
three.
If
we
got
more
time,
we'll
go
back
to
review,
but
let's,
for
the
sake
of
time,
keep
moving
Benji
I'll
hand
the
floor
to
you
to
talk
about
Express
Scrap
deal.
G
Okay,
I,
don't
really
have
much
to
say
on
this
topic,
Elisa
reached
out
to
me
and
said
that
the
graphical
Foundation
has
been
receiving
a
few
queries
about
the
express
graphql
project.
There's
an
issue
thread
on
there.
G
People
are
concerned
that
it
doesn't
support
Krakow
16
and
there
doesn't
seem
to
have
been
a
release
on
it
for
the
last
two
years
and
basically
Elisa
says
we
need
to
make
a
decision
on
it,
whether
we
are
still
maintaining
that
project,
whether
that
is
still
like
the
the
reference
implementation
of
our
HTTP
serving
of
graphql
or
whether
this
is
a
project
that
we
should
archive.
F
You
know
I
wouldn't
archive
it.
We
should
because
it
was
for
a
long
time
the
reference,
implementation
and
I
think,
especially
with
graphical
HTTP,
with
the
HTTP
spec
on
the
on
the
horizon.
This
could
be
implemented
there
myself.
I
K
E
I've
Ivan
has
some
time
to
work
in
the
project
to
get
it
into
a
better
shape,
but
I
think
he'll
talk
about
that.
D
Yeah
a
little
bit
context,
so
what
happened
is
you
would
get
like
subscription?
First
and
after
that,
I
I
felt
some
work
necessary
and
when
it's
files
fell
through
the
crack
of
all
other
things
happening
in
in,
like
my
personal
life
and
outside
the
project
yeah,
so
we
discussed
for
graphic
address.
We
discussed
contingency
one.
So
what
to
do
and
how
to
how
I
can
everything
not
depend
on
a
single
person?
And
we
have
like
solution?
D
We
have
like
a
reviewers
team
for
I
know
it's
like
five
people
from
different
organizations.
It's
like
yes,
who
already
contribute
to
JavaScript
codes,
so
they
can
review
and
much
stuff.
So
I
had
that,
like
a
group
to
have
admin
access,
so
it's
like
now,
it's
not
only
me
and
like
some
Facebook
employee,
previous
Facebook
employees.
Now
it's
like
the
same
white
people
from
kgs
have
like
watching
the
rules.
D
Also
I
I
noticed
one
thing:
important
thing
to
distinguish
between
code
ownership
and
people
who
participate
in
in
working
groups.
Some
of
them
like
happy
to
contribute
like
content,
but
is
not
familiar
with
JavaScript
or
don't
have
like
a
time
to
do.
D
Code
contribution
and
bad
reviews,
so
if
anybody
from
what
group
wants
to
it,
it's
like
super,
especially
like
a
review,
if
it
if
it
contradicts
parts
or
not
actually
like
part
of
the
maintenance
burden
of
this
project,
was
people
constantly
pushing
for
non-standard
things
like
return,
different
error
codes
on
different
staff,
doing
stuff
in
non-standard
and
graphically
was
TPS
pack
is
excellent
for
for
like
answering
that
question,
it's
not
like
personal
decision
of
anybody.
It's
like
a
document
saying
it
should
be
here
like
that.
So
and
another
thing
I
noticed
today.
D
So
after
after
seeing
it
an
agenda,
what
I
I
will
do
like
at
least
like
walking
and
stop
machine
and
do
release
so
what
I
noticed
the
reason
why
I
can
I
press
it
was
like
people
contributing
and
today
I,
actually
more
straight
I.
Think
five
years
from
from
one
person
who
did
like
a
good
job
of
cleaning
like
typescript
types
tests,
comments
like
General
cleanup
code
base
is
not
huge.
D
It's
like
I
think
like
up
to
1
000
wines
of
like
server
itself
and
a
couple
of
thousand
lines
for
a
test,
so
I
think
like
Beyond,
giving
more
people
like
right
access,
as
as
fallback
scenario
for
more
people,
have
an
option
too
much
I
think
contacting
like
a
couple
of
people
who
contribute
previously
multiple
serial
contributors,
people
who
already
know
especially
like
this
guy
today
I
forget
his
he's,
like
you,
can
look
at
the
GitHub
history
for
today
and
see
like
Pair
by
Paramus
by
him.
D
So
I
will
write
him
when
I
was
asking
if
he
wants
to
to
participate,
I
think
as
far
since
contributed
bunch
of
stuff
so
beyond,
given
more
people
right
access
actually
encouraging
to
to
people
who
previously
contribute
and
and
also
on
graphql
or
CTP
group.
Asking
white
people
participate
in
that
also
to
review
and
contribute
the
service
issue.
D
I,
don't
yeah
and
Beyond,
like
five
people
too
much
pair
with
her
work.
More
chance
of
good
players
are
getting
much
yeah.
A
I
have
maybe
another
point
of
view
on
this,
so
I
mean
we
can
you
know
I'm
happy.
You
I
just
saw
also
today
that
you
merge
like
a
couple
of
PRS,
but
the
truth
is
in
the
last
two
years.
Nobody
touched
the
library
and
also
the
library
basically
advocates
for
Express,
which
is
you
know
in
many
ways
in
the
current
JavaScript
ecosystem.
A
Is
you
know
slowly
not
necessarily
becomes
the
default
now
there's
a
question
here
of
like
is
the
reference
implantation
actually
needs
to
decide
for
you
what
HTTP,
node
HTTP
framework
can
use,
and
what
do
we
actually
want
from
a
reference
implementation?
Now
you
all
mentioned
the
new
graphql
over
HTTP
working
group.
A
Now
part
of
that
outcome
of
this
work
group
is
that
Dennis
here
created
a
library
that
basically
tests
automatically
each
framework
if
they
conform
to
the
HTTP
standard,
so
you
can
run
that
Suite
of
tests
and
see
if
your
frame
or
if
the
framework
actually
like,
follows
the
spec
or
not.
Now,
if
we
look
at
the
fact
that
we
have
now,
let's
say
we
have
Apollo
server,
we
have
graphql
yoga,
we
have
mercurius.
We
have
a
lot
of
like
good
servers
that
are
being
up
to
date.
A
Maybe
it
will
work,
maybe
it
would
not,
but
at
the
end
of
the
day,
because
it's
you
know
the
official
way
of
doing
it,
people
might
tend
to
go
to
use
this
framework,
which
I
personally
leave
his
adventures
and
I,
wouldn't
recommend
anyone
to
use
this
framework
compared
to
the
other
solutions
that
are
out
there,
not
because
it's
bad,
but
just
because
you
know
the
current
shape
of
it,
and
maybe
we
can
pick
it
up.
But
you
know
maintaining
a
server
framework
for
the
long
run
is
I.
A
Think
harder
than
just
like
finding
a
couple
of
you
know:
volunteers,
I'm,
asking
myself
are
we
doing
more
harm
by
you
know
having
it
out
there
being
the
artificial
way.
A
The
spec
compared
to
others
that
are
already
there
I,
will
and
also
another
context
today
that
the
last
person
that
actually
maintained
that
library
was
Daniel
and
Daniel
himself
like
stopped
working
on
it
and
actually
because
he
didn't
actually
was
happy
with
the
overall
philosophy
and
architecture
of
David,
went
on
to
build
graphql,
helix,
so
I
think
as
basically
his
his
own
Vision.
A
To
what
let's
say
the
reference
implementation
should
be
so
I
believe
that,
like
by
having
all
of
these
pieces,
thanks
to
the
fact
that
we
have
the
graphical
over
HTTP
group-
and
we
have
this
week
of
tests,
we
actually
get
what
we
need
from
a
reference
implementation
and
by
telling
people
that
this
is
the
official
implementation
expressed
off.
The
library.
A
I
think
we're
actually
making
more
harm
than
good
I
think
currently,
people
that
are
going
and
using
it
probably
they're
having
bad
experience
compared
to
if
they
would
use
Apollo
server,
graphql
yoga,
I'm
very
curious,
like
libraries
needed
a
lot
of
community
and
a
lot
of
documentation
and
a
lot
of
support.
We
don't
find
in
volunteers
like
it's
just
there
without
any
effort.
F
The
thing
I
think
is
that
it's
good
that
we
have
a
testing
Library,
which
is
good,
but
it's
also
I,
always
find
it
valuable.
If
you
have
like
a
reference
implementation
where
you
can
see
how
the
spec
is
applied
and
if
I
look
at
servers
like
Apollo,
they
pack
a
lot
more
than
the
spec,
like
also
Helix
a
lot
more
than
the
spec.
So
it's
more
difficult
to
see
if
you
implement
your
own
server,
what
is
really
needed?
Also
in
it's
the
same
as
graphql.js.
F
B
So
I
personally
think
that,
having
like
a
reference,
the
implementation
is
good
that
actually
should
stick
to
this
pack.
Having
me
lightweight
implementation,
that
means
like
asking
for
volunteers
from
Community:
that's
to
could
be
hit
or
miss
so
open
source
projects,
sometimes
they're
very
active
other
times.
They're,
not
people
lose
interest,
they
move
to
other
things
right.
So,
in
my
opinion,
would
be
great,
if
maybe
like,
the
foundation
could
put
like
some
fund
to
actually
pay
someone
to
maintain
it
and
keep
it
up
to
date
and
basically.
B
L
Yeah,
on
top
of
that
I'd
just
like
to
add
a
few
things
about
graphql,
HTTP
and
also
adding
on
what
Michael
said.
I
also
share
the
idea
that
a
reference
implementation
should
not
just
be
something
that
implements
a
specification.
It
should
also
be
something
that
you
can
read
code
wise
and
then
basically
have
a
picture
of
how
you
should
implement
it
yourself
anywhere
else,
not
in
the
specific
programming
language
you're,
looking
at
so
yeah,
not
to
brag,
but
the
graphql
HTTP
does
exactly
that.
So
the
code
is
so
minimal
and
it's
completely
server
agnostic.
L
So
talking
about
the
volunteering
part,
I
already
did
it
and
in
a
sense
where
we
already
have
part
of
it,
and
we
already
have
a
working
thing
that
you
can
plug
in
your
own
server
being
expressed
or
something
else
and
basically
can
be
maintained
from
that
point
on.
I
also
agree
about
the
point
that
the
name
Express
graphql
brings
this
Association
to
the
Express
framework,
even
though
it
doesn't
depend
on
it.
C
H
I
think
we
have
the
right
input,
so
some
things
here
are
clear:
one
is
there's
a
bunch
of
people
using
Express
graphql.
Today,
that's
like
the
main
thesis
of
that
issue
was
like
hey,
there's
all
these
dependencies.
Can
we
make
sure
that
these
don't
break
so
that
doesn't
necessarily
mean
enough
to
support
it
forever
either
we
have
to
support
it
to
some
degree
in
the
short
term.
Thank
you,
Yvonne
for
merging
some
pull
requests
and
a
minimum.
H
We
need
to
have
sort
of
like
a
healthy,
Exit
Plan
for
it
like
what
does
it
look
like
to
migrate
from
this
to
something
else,
or
do
we
just
shim
Express
graphql
on
top
of
graphql
HTTP,
or
something
like
that?
There
needs
to
be
some
kind
of
plan.
There's
something
there
strongly
agree
with.
What
you're
saying
Dennis
about
sort
of
the
goals
of
a
reference
implementation
should
also
be
used.
H
I
would
add
that,
in
addition
to
your
criteria
and
I,
think
graphql
hdb
is
ultimately
someone
just
needs
to
own
this
and
own
the
space,
and
my
sense
is
the
best
case
scenario,
for
that
is
the
person
who
owns
this
and
owns
the
space.
Also
is
one
of
the
people:
who's
Deep,
In,
The
Weeds
of
the
graphql
HTTP
work
Dennis.
L
Yeah
cool
I'm,
more
than
willing,
and
also
like
Express
wise,
which
is
what
you
said
about
shims
and
whatever
not
so
graphql
HTTP
itself
can
also
bundle
like
optionally
parts
that
includes
it
inside
existing
Frameworks
like
festify
and
Express,
and
also
does
that
in
this
framework,
idiomatic
way
of
how
they
do
this
actually
I
do
this
with
a
separate
Library,
graphql
WS,
where
you
can
plug
it
in
into
different
servers
and
the
core
product.
L
The
core
library
is
just
like
a
way
of
coercing
messages
and
giving
you
responses,
so
it
I
don't
think
that
the
movement
from
Express
graphql,
especially
having
this
in
mind,
won't
be
of
much
much
friction.
Yeah.
You
can
just
like
switch
it
up.
We
can
also
create
a
migration
plan
or
things
like
well
yeah,
I.
Don't
think
it
would
be
like
that
big
of
a
deal
honestly.
E
You,
let's
go
yep
I,
know
we're
over
the
five
minutes
here
on
this
topic,
but
it's
just
two
quick
questions.
One.
Does
that
mean
that
graphql
HTTP
needs
to
become
a
foundation
owned
project,
or
what
is
our
stance
on
that?
Would
the
foundation
have
a
reference
implementation
for
something
if
it's
not
Foundation
owned.
H
H
Is
it
graphical,
http
I
would
prefer
to
delegate
that
decision
and
Dennis
if
you're,
the
one
who
has
the
most
context
to
make
a
call,
along
with
a
handful
of
other
folks,
who've,
been
working
on
this
great,
but
I
think
it
does
make
a
lot
of
sense
that
the
reference
implementation
would
live
within
that
graphql
org,
which
hopefully
should
not
change
in
any
way
your
ability
to
manage
it.
It's
just
a
matter
of
sort
of
where
it
lives.
L
L
H
Tactical
changes
like
it
would
become
like
technically
governed
by
the
our
technical
steering
documentation.
You
can
look
at
that.
H
It'll
sit
at
the
top
of
the
agenda
file
anyway,
and
so
in
that
sense,
it's
like
the
the
true
ownership
piece
is
there,
but
in
terms
of
the
like
how
you
want
to
operate
it
I'm
100
with
Michael,
really
what
we're
talking
about
is
the
difference
between
zero
maintainers
and
one
maintainer,
not
like
one
versus
n,
and
so
if
that
means
that
you
wanna
I,
think
it
is
a
very
good
that
you
would
have
sort
of
a
vision
and
a
code
review
process
and
everything
those
those
all
sound
like
very
healthy
Elements.
A
I
wonder
like:
what's
the
so
I
I
would
say
two
things.
First
of
all,
it
looks
like
we
have
here
something
that
acts
as
a
test
suite
and
a
reference
implementation,
I
guess
by
now
going
and
updating
Express,
graphql
I
think
we
might
actually
send
the
wrong
message
to
the
community,
but
it's
still
maintaining
whether
I
believe
it
will
probably
like
many
other
stuff,
won't
be
in
a
couple
of
months.
A
So
I
would
suggest
to
actually
send
a
very
clear
message
on
Express
graphql
Library
itself,
that
is
it
not
maintained
and
is
not
aimed
to
be
maintained,
because
I
believe
that
a
lot
of
people
are
using
it
right
now
and
are
suffering.
A
So
that's
one
thing
I
think
we
should
also
decide
on
here
about
moving
to
the
foundation
I.
This
is
a
different
thing
and
I
don't
want
to
take
the
discussion
here
but
I
wonder:
what's
the
fear
of
people
quoting
it
in
under
the
foundation
because
it
looks
like
the
project
leaves
very
well
I
mean
in
the
I'll
say
from
our
like.
This
is
Dennis's
project
but
I'll
just
say
a
philosophy,
a
small
philosophy
that
we
have
in
the
guild
that
might
be
related
here,
and
this
is
my
personal
thought.
A
A
level
Foundation
projects
are
moving
slow
because
there
is
no
for
all
kinds
of
reasons
and
good
reasons,
and
here
we
have
a
project
that
moved
very
quickly
and
I
believe
answered
with
everything
that
was
needed
and
it
looks
like
no
one
has
currently
at
least,
if
negative
feedback
on
so
what
I,
what
I
would
suggest
is.
Maybe
we
can
always
that
that
project
is
MIT,
so
what
I
would
suggest
is
once
let's
say
we
have
some
members
here
in
the
in
the
foundation
would
say:
okay,
you
know.
A
Let's
say
then
this
is
the
project
is
under
Dennis
and
now
Dennis
has
done
something
that
we
disagree
with.
We
can
always
look
at
0.4
and
move
it
to
the
foundation,
but
I
believe
what
we
that
what
we
are
losing
when
we're
taking
this
project.
That
Venice
has
built
and
put
a
lot
of
time
and
effort
in
and
keeps
putting
a
lot
of
time
and
effort
in
by
moving
into
defamation
is
basically
losing
one
thing,
giving
him
a
little
bit
of
the
credit
and
the
stuff
that
he
deserves.
A
So
I
believe
that
in
order
that
so,
but
there
are
also
some
benefits
of
moving
into
the
formation,
one
is
like
I
guess
telling
people
that
this
is
the
official
one,
but
we
also
have
other
solutions
for
that
and
the
other
thing
is
like
what
happens
if
Dennis
goes
wrong.
You
know
like
because
there's
two
things
the
things
that
we,
the
foundation
doesn't
disagree
with
I.
Think
at
that
point.
When
that
will
happen,
we
can
always
put
it
back
to
the
foundation
as
it's
MIT
and
we
can
do
it
there.
A
So
that's
just
my
suggestion
and
the
reason
I'm
suggesting
it
I
think
that
I
worry
about
projects
continuing
to
be
maintained
for
the
long
term
and
many
times
like
the
force,
or
it
is
the
person
that
actually
does
the
work.
So
I'm
sure
Dennis
is
not
is
happy
to
lend
it
to
the
foundation,
but
I'm.
Just
I
mean
I
know
he
wouldn't
ask
for
something
like
that
to
keep
it
under
his
name.
So.
H
H
First
of
all,
let's
keep
the
credit
like
add
something
to
the
top
of
the
readme
file.
That
says
main
maintainer.
This
is
Dennis
so
that
it's
super
clear
and
then
you
know
all
really
the
the
being
part
of
the
foundation.
It
gives
you
credibility.
It
gives
you
and
the
community,
especially
a
safety
net
like
there's,
then
clear,
sort
of
Rules
of
Engagement
for
how
to
engage
with
the
product
or
with
the
project
which,
hopefully
just
you
agree
with
all
of
them.
H
If
you
don't,
then
we
should
talk
about
it,
but
hopefully
that
ends
up
being
just
sort
of
pure
value
and
I
think.
The
main
reason
why
projects
moves
slow
is
that
they
they
don't
have
impassioned
primary
maintainers,
and
that
is
actually
a
quite
good
thing
for
us
to
hold
on
to
like
just
because
the
project
is
part
of
the
foundation.
Core
does
not
necessarily
mean
that
it
can
survive
without
a
core
maintainer.
If
that's
the
primary
reason
why
Express
graphqls
landed
itself
in
the
position,
it
is
now
which
is
we've
had.
F
And
I
think
it's
actually
actually
giving
you
more
credentials.
That's
my
thought
like
this
is
really
like.
If
it's
private,
it's,
if
it's
under
just
Dennis,
it's
we
might
point
there,
but
it
never
feels
like
this
is
the
way
you
should
implement
it.
This
is
a
reference
implementation.
It's
I
think
it
gives
you
more
credentials
and
I
think
like
with
graphical
JS
and
Yvonne
is
doing
that
a
lot
and
I
don't
feel
that
you're
taking
credit
away
I
mean
most
people
that
look
at
graphql.js
know
that
Iran
is
doing
a
ton
of
work.
F
H
And
for
the
sake
of
time,
I
think
we
should,
if
there's
extra
discussion
here,
we'll
move
it
to
a
discussions
thread,
but
it
sounds
like
we
have
a
really
great
course
of
action
here,
which
is
basically
Dennis,
giving
you
more
reign
of
authority
over
an
additional
project
and
and
I
agree
with
Yuri
that
the
right
thing
to
do
there
is.
If
the
decision
is
the
graphical
HTTP
is
the
source
of
Truth.
H
J
All
right,
so
there
is
a
a
PR
to
the
spec
that
is
linked
there.
You
know
some
folks
have
commented
in
there.
I
wanted
to
to.
First.
Just
kind
of
you
know
give
the
the
use
case
that
you
know
what
like
what.
What
are
we
trying
to
solve
here
and
see?
J
There
we
go
so
we
have
a
common
schema
example
where
we
have
some
animals
and
we
have
an
interface
that
is
an
animal
and
we
have
a
dog
that
is
a
canonical
animal,
and
then
we
also
have
a
baiji,
which
is
a
Chinese
river
dolphin,
and
so
then
you
know
the
problem
is
that
you
know
by
G,
has
not
been
spotted
in
the
wild
in
20
years
it's
sought
to
be
extinct,
and
so
our
server
doesn't
isn't
going
to
be
handling
this
type
anymore,
and
and
so
what
we
would
like
to
indicate
to
clients
that
in
their
queries
they
shouldn't
be
spreading
on
the
baiji
type,
because
as
long
as
as
long
as
clients
are
spreading
on
this,
you
know,
even
if
the
server
is
not
returning
it.
J
J
That
we
know
is,
is
not
going
to
be
returned
anymore,
and
so
so
now
now
moving
on
to
you
know
solution
we
could
Mark
the
byg
type
as
deprecated,
and-
and
so
you
know,
basically
what
this
means
from
the
spec
perspective
is
that
you
know
we
take
the
deprecated
directive
and
we
add
that
this
can
also
exist
on
an
object,
and
so
that's
that's
basically
it
you
know.
What
does
this
mean
when
you
put
it
on
an
object?
You
know
this.
J
The
idea
is
this
indicates
to
clients
that
they
they
shouldn't,
be
spreading
on
this
and
and
then
this
could
also
drive.
Then
you
know
client
tooling,
to
you
know
to
let
them
know
they
don't
need
to
be
spreading
on
this
code
generation
does
not
need
to
be.
J
J
Do
that,
like
that's
confusing
to
to
deprecate
a
type
but
then
have
undeprecated
fields
that
are
you
know
referring
to
it
now,
if
we
you
know,
we
could
make
that
stronger
language
it'd
be
pretty
easy
to.
You
know
to
validate
that.
J
But
that's
you
know
one
point
of
discussion
and
then
another
point
is
that
in
the
spec
PR
you
know
so
there's
other
Alternatives
as
far
as
ways
we
could
address
this
use
case.
That
would
be,
you
know
slightly
different,
so
I'll
leave
it
at
that.
That's.
H
Yeah,
this
is
interesting,
I,
I,
guess
like
there,
the
reason
for
deprecation
in
the
first
place-
I
just
it
may
be
pointing
at
something:
that's
that's
a
silly
thing
to
poke
at,
but
just
to
make
sure
that
it's
clear.
The
original
reason
for
introducing
the
deprecated
directive
was
simply
removing.
That
thing
would
be
a
client-side
breaking
change
like
if
you
have
a
field
and
you're
like
that
field.
I
don't
want
people
to
use
it
anymore,
but
it's
already
listed
a
bunch
of
queries.
H
If
you
deleted
the
feel
on
the
server
you
just
you
failed
the
queries
for
all
those
existing
clients
which
which
you
can't
do
so
deprecation,
allows
you
to
stop
using
those
new
queries
and
flag.
It
is
this
a
similar
case
where
simply
removing
the
object
from
a
union
or
removing
the
object
from
or
removing
an
interface
from
that
object
that
you
would
deprecating
like,
essentially
getting
it
untying
it
from
the
rest
of
the
schema
directly
without
using
deprecation.
Does
that
create
a
similar
breaking
change.
J
Yeah
exactly
I
mean
it
does,
just
because
of
you
know,
validation.
So
if
we
receive
a
query
and
the
client
is
spreading
on,
you
know
type
that
isn't
part
of
the
Union
didn't
part
of
the
unit
race,
we're
gonna,
you
know,
servers
are
gonna,
reject
that
that
query.
I
Yeah
I
I
yeah
on
top
of
this
I,
do
think
the
making
it
a
must
that
a
non-deprecated
field
cannot
reference
this
type
rather
than
a
should,
would
make
this
a
lot
stronger
and
adding
that
as
an
actual
validation
rule
like
just
another
pass
over
the
schema.
I
Every
type
that
is
deprecated
must
not
be
referenced
by
a
non-deprecated
field
because,
right,
if
you're
going
to
go
through
this
process,
you're
like
you
want
to
be
able
to
have
clients
that
a
hundred
percent
like
know
exactly
where
all
their
bad
usages
are
and
not
having
that
I
think
messes.
That
process
up.
H
Yeah,
especially
since
right
now,
there's
this
I
mean
deprecation
is
relatively
narrow
at
the
moment,
but
there's
this
idea
that
if
you
take
your
schema
and
then
literally
remove
everything
that
is
deprecated,
you
end
up
with
a
valid
sub
schema,
and
so,
if
you
had
a
non-deprecated
field
that
referenced
the
deprecated
object,
if
you
remove
that
object,
you
now
have
a
field
that
doesn't
reference
a
return
type
anymore,
and
that
is
broken.
H
So
I
think
like,
if
that's
a
rule
that
we
want
to
hold
too,
which
I
think
we
should,
because
that's
how
that
is,
how
introspection
Works
currently,
which
is
you,
have
to
opt
in
to
receive
the
deprecated
things,
which
means,
if
you
don't
opt
into
those,
you
need
to
make
sure
that
you
get
a
valid
schema
back.
I
Do
we
have
I
I,
don't
have
it
off
the
top
of
my
head?
Do
we
have
the
rule
that
if
a
field
is
deprecated
on
a
type
that
it
must
also
be
deprecated
on
any
interface,
it.
I
I
Like
literally,
the
same
code
is
executed,
but
so
when
you
deprecate
that
it
just
applies
everywhere,.
I
C
J
To
another
consideration
for
kind
of
stronger,
you
know
validation
around
this
at
runtime
should
a
server
be
allowed
to
return
a
deprecated
object
as
part
of
a
union
or
interface,
or
should
that
be
like
a
runtime
error.
H
Yeah,
that's
really
interesting
because
so
far
deprecation
is
about
what
the
client
can
ask
for,
which
means
we
have
not
needed
a
mechanism
like
that.
This
would
be
the
first
time
that,
should
a
client
try
to
make
sure
that
they're
only
using
non-deprecated
values
if
a
server
was
to
respond
with
that.
I
So
I
don't
think
you
can
I,
don't
think
it's
possible
to
say
the
server
cannot
respond
back
with
this
deprecated
type,
because
you
can
have
a
field
that
Returns
the
deprecated
type.
You.
C
J
I
Foreign
thing
to
note
is
that
we
make
no
promises
that
you
won't
get
unexpected
types
in
a
union
or
interface,
so
right,
basically,
clients
need
to
be
future
compatible
compatible
with
future
servers.
I
So
in
some
sense
this
just
makes
it
the
same
as
any
other
future
type,
so
I'd
be
pretty
I'd,
be
pretty
comfortable
with
you
might
get
it,
but
your
client,
like
we've,
we're
trying
to
get
rid
of
it
over
time.
So
your
client
should
like
be
robust
to
getting
this
new,
or
this
like
no
longer
known
to
the
client
value
that
fulfills
the
interface
or
fulfills
the
union,
and
but
like
we're
going
to
be
working
overtime
to
reduce
how
often
that
happens
until
it's
zero.
H
I
think
that's
exactly
right.
Yeah,
there's,
there's
not
a
observable
difference
between
if
you're
a
client
that
is
has
intentionally
fed
itself
of
anything
that
is
deprecated
is
only
looking
at
the
subset
of
the
schema
that
is
not
deprecated,
then
getting
a
value
of
some
type
for
a
particular
interface
that
it
isn't
aware
of.
H
J
So
so,
where
we
put
this
as
far
as
RFC
or
phase
at
this
point.
H
I
think
this
is
phase
one,
because
this
is
there's
clearly
some
big
open
questions
to
answer.
However,
the
problem
is
defined
is
a
very
real
one
which
is
like
this
is.
This
is
a
real
way
in
which
people
have
tried
to
do
schema
evolution
that
is
not
possible
to
do
without
creating
breakages.
J
And
then
so
next
steps
to
get
to
phase
two
for
this.
For
this
RFC
we,
you
know,
we
mentioned
some
specific
things,
change
the
wording
to
must.
As
far
as
return
from
dedicated
Fields
yeah
there's
specific
things.
H
H
It
seems
reasonable
that
if
they
I
don't
know,
there's
some
quirkiness
around
how
you
want
to
interpret
the
the
Implement
implementation
of
an
interface
and
inclusion
in
Union
relative
to
a
type
that
is
deprecated,
so
that
probably
needs
some
noodling
and
making
sure
that
it's
something
that
we
all
agree
is
the
right
one.
H
The
spec
should
be
fully
formed,
so
anything
that
you
need
in
terms
of
shoulds
or
musts
and
validation
rules,
and
everything
needs
to
be
there
and
then
making
sure
that
you've
got
a
reference
implementation.
At
least
a
PR.
That's
fully
formed
doesn't
have
to
be
merged
yet,
but
just
you
basically
proven
that
you
can
it's
very
reasonable
to
implement
this,
and
you
haven't
like
uncovered
something
new
in
the
process
of
trying
to
build
it,
that
that
would
be
stage
two.
H
K
Sorry
about
that
yeah,
so
in
the
primary
October
meeting
we
talked
a
little
bit
about
deferring
stream
and
subscriptions
it
was.
It
was
raised.
K
A
couple
times
that
subscriptions
would
combine
with
deferring
stream
is
definitely
not
like
the
the
strongest
use
case
where,
as
opposed
to
queries,
is
definitely
something
that
people
want
a
lot
more
and
combining
different
stream
with
subscriptions
brings
up
the
problem,
not
necessarily
a
problem,
but
we
we
have
a
stream
of
responses
and
we're
adding
multiplying
it
by
another
stream
of
responses
and
there's
I
think
there's
different
ways
that
that
could
be
handled.
K
So
the
question
that
I
want
to
raise
is:
should
we
basically
not
include
this
in
the
in
the
defer
stream
proposal?
We
have
now
and
move
it
to
another
proposal
in
the
interest
of
moving
the
main
one
along
faster.
K
So
we
talked
about
a
few
different
options
for
that
in
the
last
meeting.
Didn't
really
get
a
consensus
on
the
way
to
move
forward,
but
one
thing
we
could
do
is
add
a
validation
rule
that
will
reject
any
query.
That's
a
subscription
that
has
different
stream
in
it.
I
think
the
downside
here
is
that
if
you
have
a
fragment
that
you're
using
with
a
query-
and
you
want
to
include
it
in
a
subscription-
you
can't
anymore
yeah-
maybe
that
could
be.
K
Maybe
you
can
work
around
that
or
you
could
raise
a
field
error
if
that
happens
now,
this
will
you're
going
to
get
an
error
during
the
execution
phase,
instead
of
validation,
because
validation
doesn't
have
access
to
variables.
K
K
If
argument
on
the
you
could
disable
it
with
a
variable
using
the
if
argument
on
defer
or
stream
yeah
and
basically
like
the
the
main
thing
that
brought
this
up
was
the
question
of,
should
we
be
multiplexing
these
payloads,
whereas
my
implementation
that
I
have
now
is
basically
waiting
to
drain
all
of
the
responses
from
one
subscription
event
until
you
get
the
the
next
event,
if
I
could
cause
a
backlog
if
your
resolvers
are
take
longer
than
it
takes
you
to
get
new
events,
that
is
a
problem
we
have
now.
K
It
doesn't
necessarily
mean
that
we
shouldn't
try
to
solve
it
but
yeah,
but
the
the
last
two
options
are
we
move
forward
with
what
we
have
now?
That
means,
if,
when
we
do
try
to
solve
multiplexing,
it's
kind
of
something
you
have
to
opt
into,
or
we
do
try
to
solve
this
multiplexing
concern
and
hold
out
the
rest
of
deferent
stream
until
that
it
problem
is
solved.
H
Maybe
just
high
level
question
is
how
much
how
much
open
threads
and
potential
for
churn
is
there
and
continuing
down
the
path
with
multiplexing
I
think
we
I
agree
that
that
that
is
the
good
long-term
state.
But
if,
if
you
think
that
that
is
on
its
own
a
very
significant
Proposal
with
a
lot
of
iteration
required,
then
then
I
think
you're
right
to
consider
punting.
It.
K
K
It
would
probably
need
some
new
information
added
to
the
response
shape,
which
would
have
to
go
into
the
spec
of
how
the
different
responses
are
correlated
or
it
could
even
just
be
left
up
to
the
transport
entirely
but
I,
but
like
that's
those
are
questions.
The
type
of
questions
that
we
have
to
start
digging
into.
H
Yeah,
so
it's
entirely
possible
that
it's
introduced
in
a
way
where
someone's
subscription
implementation,
even
though
the
spec
describes
it,
they
can't
like
there
could
be
a
mode
in
which
a
particular
implementation
can
do
streaming
via
queries,
and
mutations
cannot
actually
do
streaming
via
subscriptions.
Even
though
we
happen
to
have
specified
Behavior,
and
in
that
scenario
they
would
still
need
some
described.
Behavior.
H
Okay,
I
feel
pretty
strongly
that
we
should
not
make
stream
and
defer
All
or
Nothing
Like
I
think
it
is
reasonable
to
suggest
even
between
queries
and
mutations
like
it
may
be
the
case
that
your
your
particular
implementation
has
constraints
on
the
how
payloads
are
treated
for
a
mutation
that
differ
from
a
query,
can't
think
of
exactly
why.
H
But
it's
entirely
possible
that
someone
comes
across
that
as
a
scenario,
and
so
if,
if
an
implementer
is
forced
between
enabling
streaming
for
queries,
mutations
and
subscriptions
or
none,
then
that's
a
rough
position
to
put
an
implementer
in,
because
if
they
can
turn
it
on
for
queries
and
that
unlocks
value
and
they
cannot
turn
it
on
for
the
other
two
or
one
or
the
other
two.
H
Then
that
seems
like
a
an
important
thing
for
us
to
get
right
and
which
is
a
subtly
different
thing
from
what
you're
saying,
which
is
like
I
think
we
should
eventually
get
something
that
looks
like
your
option
three,
but
even
if
we
did
have
that
I
think
we
probably
still
want
to
have
well-defined
behavior
in
the
scenario
where
you
turn
it
on
for
queries.
You
turn
it
off
for
subscriptions.
I
Yeah
I
I
have
to
say
I'm
a
huge
huge
fan
of
using
validation
rules
to
get
incremental
wins
when
the,
when
the
behavior
of
what
you
really
want
to
achieve
is
not
yet
figured
out,
for
instance,
we
could
easily
in
the
spec
we
could
have
a
directive.
That's
like
defer
stream
enabled
that
goes
on.
Your
query
goes
on.
Your
subscription
goes
on
your
mutation
or
disabled
right
and
until
the
spec
like
on
the
server,
you
could
declare
hey
I.
I
F
I
I
think
the
same
I
feel
the
same
way,
because
evaluation
rule
also
gives
you
like
syntax
errors
like
in
graphical
or
wherever
you
type
it.
You
already
get
feedback
before
you
send
it
to
the
server
I'm,
not
a
fan
of
a
field
error
in
that
way,
because
then
you
have
to
try
out
if
it
works
or
not,
and
yeah
I
am
support
that.
H
I
think
the
tricky
part
with
the
validation
rule
is
that
there
is
this
like
additional,
at
least
presently
unknown
piece
of
information
that
we
would.
We
would
need
to
add
to
introspection
in
order
to
do
it
with
validation,
which
is,
does
does
the
server
support
streaming
for
a
query
and
for
a
subscription
Etc,
because
a
validation
rule
would
need
to
know
that
to
know
if
it
was
valid
or
not
valid.
I
Yeah
I
I.
Think,
though,
that's
that's
a
reasonable
thing
for
us
to
include.
We
could
do
it
with
like
if
we
added
directive
on
the
like
root,
query
mutation
subscription
kinds.
That
would
be
one
opportunity.
Another
would
be
just
like
right.
If
we
do
it
in
introspection,
the
the
advantage
of
it
is.
We
have
a
whole
bunch
of
old
servers
right
now
that
do
not
support
it,
and
it
would
be
useful
for
clients
to
know
hey
the
server
I'm
hitting
like
sure
I
could
like.
I
K
K
What
I
am
concerned
about
with
the
validation
rule
is
this
case
of
sharing
fragments
like
I
do
does
happen
a
lot
for
us
with
with
relay.
We
have
like
these
large
fragments
that
correspond
to
a
component
that
has
many
many
sub
fragments,
and
it
would
basically
prevent
you
from
using
defer
in
your
query.
If
now,
you
can
also
spread
that
fragment
into
your
mutation,
but.
F
It
said
in
relay
I
mean
the
fragment
is
bound
to
a
component
right
and
typically,
that's
that's
how
we
do
it.
We
have
like
a
much
smaller
footprint
for
a
subscription.
I
mean
you're
you're,
not
having
the
same
fragment
that
you
often
use
in
your
query,
because
that's
if
you
think
about
like
high
frequent
payloads,
then
you're
sending
all
this
data
that
doesn't
change.
So
you
most
often
have
a
much
smaller
footprint
that
you
ask
on
the
subscription
yeah.
I
We
would
get
into
problem
the
problems
that
Rob
is
explaining.
We,
we
definitely
have
a
lot
of
fragments
that
are
both
deferred
and
shared
between
subscriptions
and
mutations,
and
that's
that's.
That
is
a
very
common
thing
for
a
client
like
relay
a
relatively
straightforward
answer
is
relay:
has
a
compiler
strip
them
out
right
if
you're
in
a
subscription?
The
query
that
you
are
sending
to
the
server
amount
yeah.
E
F
Yeah,
because
there's
so
much
good
stuff
already
there
that
we
could
pack
in
the
next
spec,
and
that
would
enable
so
many
people
to
do
amazing
stuff.
That
I
also.
E
Would
yeah
and
we
have
some-
we
have
some
real
usage
data.
We
have
some
real
usage
data
right
now
too,
from
people
using
it
and
I
know
the
guild
has
had
people
using
it
I'm
sure
across
their
projects
as
well
and
the
edge
cases
not
necessarily
edge
cases,
but
the
number
of
times
people
have
brought
up
any
issues
with
subscriptions
have
been
zero
because
they're,
just
not
thinking
about
that.
H
H
Would
someone
come
to
the
realization
that
they
actually
like
they
themselves
need
to
come
to
some
answer
for
this
question
because
they
can't
turn
it
on
for
subscriptions
and
if
they
did,
what
would
they
do,
and
in
that
case
we
should
just
offer
specified
Behavior
anyway,
and
if
doing
that,
then
allows
us
to
parallelize
a
little
bit
where
we
could
actually
ship
the
first
version
of
this
that
works
for
non
subscriptions
and
then
ideally
fast,
follow
or
you
know.
H
Hopefully,
when
exploring
the
multiplexing
stuff,
it
ends
up
being
a
little
more
a
little
easier
than
we
hoped
it
would
and
then
it
ends
up
going
smooth.
But
I
see
this
more
as
like
making
sure
that
we
have
well-defined
behavior
for
the
scenario
where,
even
when
we
do
have
an
answer
to
multiplexing
in
the
behavior
for
subscriptions,
you
could
still
opt
out
of
that
element
independently
and
have
good
behavior
I'm,
actually
coming
closer
to
this
option.
H
Two,
which
is
an
execution
phase
error
which
does
not
it
doesn't
rule
out
the
ability
for
a
tool
like
basically
like
you
know,
we've
been
talking
about
the
Apollo
client
relay
having
these
compilers,
which
give
us
the
ability
to
add
in
extra
bits
and
pieces.
You
can
add
in
extra
validation
or
like
lint
style
rules.
So
you
could
also
say,
like
hey.
You
know:
I
noticed
that
you
were
following
this.
H
You
know
you're
expecting
a
stream
to
happen
from
the
consequences
of
subscription
like
that
won't
work
for
this
particular
reason,
and
if
you
were
going
to
strip
them
out
anyway,
then
I
don't
know
if
that's
all
that
different,
but
I
certainly
agree
that
the
validation
like
untangling,
how
to
figure
out
how
to
get
around
that
validation
rule
would
be
very
non-obvious
and
knowing
when
to
apply
it
and
when
not
to
apply
it
outside
of
the
context
of
the
server
domain
is
also
non-obvious.
H
So
it
would
be
hard
for
it
to
like
graphical
to
know
to
flag
that
in
advance
without
more
information
than
we
currently
share
and
option.
Two
is
on
on
the
front
of
like
best
possible
devex
slightly
worse,
because
you're
getting
a
runtime
error
rather
than
a
developer
time
error.
But
it
does
seem
like
this
simple
or
Unblocker,
and
then
leverages
this.
F
Another
thing
what
I
mean
the
server
can
optimize
and
ignore
the
first,
so
we
we
were
okay
with
that.
Why
not
the
server
just
ignores
it
for
subscription,
then,
and
then
execute
it
like
normal,
like
essentially
the
server
scripts
it
out
of
subscriptions
could
also
be
and
approach.
K
Yeah
I
I
forgot
to
listen
here.
We
did
talk
about
that
in
in
the
prior
meeting.
Okay,
I
think
at
that
point
it's
questionable
then
it's
like.
Is
it
a
breaking
change?
If
you
have
this
subscription
with
a
deferrer
stream,
that
was
always
ignored
all
the
time,
but
now
it
does
actually.
K
H
H
The
we
still
need
to
have
some
definition
of
in
this
scenario
where
you
don't
like
it's,
it
should
always
be
safe
to
have
some
kind
of
phase
of
not
not
respecting
it.
I
think,
but
certainly
like
the
forward
forward
compatibility
story.
There
is,
is
less
good
than
the
first
two
options
which
is
ignoring
it
in
the
subscription
until
one
day,
all
of
a
sudden,
you
start
getting
multiplexing
down,
and-
and
none
of
your
existing
clients
know
how
to
handle
that
kind
of
payload
would
be
not
good.
F
Because
what
what
we
are
at
the
moment,
looking
at
for
hot
chocolate,
is
like
it's
very
easy,
with
two
streams
and
one
different
to
produce
like
I,
was
very
easy
to
to
produce
over
3000
patches
from
a
simple
query
and
we're
also
looking
into
from
the
security
side
at
the
moment.
How
can
you
prevent
people
really
look
using
that
in
a
nefarious
way
against
yourself,
a
different
stream,
and
that's
also
like
there's
some
calculation,
where
you
then
ignore
the
first?
F
Essentially,
some
parts
will
no
longer
be
deferred
because
they
actually
would
harm
the
server,
and
these
are
also
aspects
where
you
where
the
client
has
to
deal
with
than
different
patches.
So
so
the
client
should
shouldn't
be
fixated
on
patches.
Actually,
that's
mine
reason,
so
it
should
deal
with
different
patch
sizes
that
it
gets
or
different
kinds
of
patches.
F
So
it's
not
necessarily
that
the
client
can
expect
that
it
gets
a
certain
shape
of
patches.
So
it
could
also
be
okay.
If
we
skip
the
things
and
then
suddenly,
they
came
because
the
decline
specified
I
want
this
deferred
and
then
the
server
just
determined.
Okay,
that's
actually
not
in
the
best
interest
of
us,
both
to
give
you
that
differ,
so
I
give
it
to
you
in
a
different
shot.
F
H
Okay,
I
know
we're
at
time.
Rob
sounds
like
you
have
at
least
directionally
correct
feedback
here,
which
is
yes.
This
seems
like
a
problem
we're
solving
and
if
this
allows
you
to
punt
on
multiplexing
short
term,
then
if
that's
valuable,
then
that's
valuable,
I
think
maybe
you
can
explore
a
little
bit
about
like
what's
the
best
way
through
how
to
apply
the
disabling.
K
H
I
E
E
And
one
last
little
thing
to
throw
in
there
if
we
do
not
allow
subscriptions
and
we're
very
public
about
that
when
this
gets
into
the
specification,
we
can
footnote
that
very
publicly
with
hey.
If
this
is
important
to
you
and
subscriptions
come
and
get
involved
and
join
the
working
group
meetings
and
help
us
out
so
there's
a
really
good
Community
starting
there.
H
Sure
all
right
folks,
thanks
for
the
great
discussion
looking
forward
to
seeing
you
all
relatively
soon
great
thanks.