►
From YouTube: GraphQL Working Group - August 6, 2020
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
B
B
I'm
gonna
put
this
on
mute
for
a
minute.
While
I
get
things
ready
I'll,
be.
B
A
A
A
A
D
E
A
C
Yeah,
unfortunately,
the
last
graphql
over
http
meeting
was
kinda.
We
skipped
it
because
we
couldn't
figure
out
a
good
time
and
yeah,
so
we
got
one
this
month
again.
Hopefully
we
will
get
it
together
by.
A
C
A
F
F
G
G
G
H
B
Let's
see,
can
you
hear
me
now?
Yes,
there
you
go.
Thank
you
for
mentioning
that
I
was
just
over
here
talking,
assuming
that
you
could
hear
me,
I'm
going
through
the
last
couple
requests
right
now,
so,
if
you're
not
on
the
agenda
or
if
you
see
anything
missing,
feel
free
to
send
that
up
as
a
quick
pr,
I'm
just
going
to
try
to
get
through
the
last
couple
of
them.
Now
before
we
kick
off
the.
B
B
B
The
agenda
is
up
to
date.
Now,
let
me
know
if
you
see
anything
that
looks
out
of
place.
B
Okay,
let's
get
things
going
as
usual.
First,
a
quick
reminder
that
by
joining,
we
all
agree
to
the
spec
membership
agreement,
participation,
guidelines
and
code
of
conduct
links
in
the
agenda.
If
you
forget
what
the
contents
of
those
things
are
and
let's
go
down
and
do
just
quick,
intro,
quick
name
to
face,
we
will
go
in
the
order
that
it's
listed
in
the
agenda
and
if
you
get
to
the
bottom-
and
you
haven't
mentioned
yourself,
then
please
do
so
followed
by
sending
a
pull
request
to
add
yourself
to
the
agenda.
E
G
J
Hi
everyone,
I'm
dutan,
I'm
from
the
guild
working
mostly
on
graphical
code
gen
here
today
to
talk
about
graphql,
typescript
and
how
we
can
make
it
better.
H
Hey,
I'm
stephen,
I'm
at
netflix
working
on
our
graphql
infrastructure.
D
Hey
folks,
I'm
vince
I
work
at
new
relic
and
I
maintain
the
absinthe
elixir,
graphql
library.
O
Did
we
miss
anybody,
anybody
else,
I'm
ricky.
I
work
on
graphical
the
graphical.
B
Cases,
I
think
that
was
everybody
all
right
send
prs
if
you
for
the
last
couple
of
y'all
who
aren't
on
the
agenda,
welcome
everybody
great
to
see
all
your
faces,
lots
of
familiar
faces
for
me
and
a
small
handful
of
new
ones.
B
We've
got
a
pretty
packed
agenda.
I
see
one
volunteer
for
notetaking
benji,
as
per
usual
who's
already
outlined
out
our
whole
notes.
Does
anybody
want
to
volunteer
to
help
out
with
benji.
B
Yeah
I'll
help
out
as
well
awesome.
Thank
you
steven,
there's
a
link
in
the
agenda
for
anyone
who
wants
to
follow
along
with
the
notes
and
help
out.
B
Let's
take
a
quick
look
at
open
action
items.
I
don't
know
that
any
were
filed
from
the
last
meeting.
We
should
have
a
meta
action
item
to
file
those
I
think,
there's
we
might
need
to
still
translate
those
notes.
The
only
open
ones
are
relative
to
custom
scaler
editorial
pass.
It's
still
open
on
me.
B
I'm
kind
of
waiting
on
some
spec,
some
other
things,
I'm
we're
working
on
making
sure
that
the
legal
paperwork
for
all
the
specs
in
place,
because
I
want
to
do
the
final
editorial
passes
on
those
right
before
we're
ready
to
cut.
So
that's
the
reason
why
I'm
waiting
on
that
one
introspection
shortcuts.
That
was
from
a
couple
of
meetings
ago.
I
think
that
one's
still
open
and
pending
update
the
input
union
rfc.
B
I
don't
know
that
we
ever
folded
in
our
notes
to
those
docs,
so
I
think
that's
on
either
benji
vince
or
myself
to
make
good
on
that
and
similar
there's
multiple
issues
relative
to
that
one.
So
not
a
lot
of
progress
on
existing
open
issues.
That's
okay!
I
know
everybody's
been
pretty
busy
as
I
have
as
well,
but
we
have
a
pretty
packed
agenda.
B
Let's
review
it
briefly,
just
to
make
sure
everything
we
want
to
talk
about
is
the
right
set,
we're
not
missing
anything,
and
this
is
roughly
the
right
order.
We're
gonna
go
through
custom.
Scaler
update,
deferring
stream
update
tag,
type
rfc
field
coordinates
rfc
graphic
over
websocket,
refresh,
adding
generics
to
a
couple
of
nodes
and
typescripts
and
typescript
migration
plan
progress.
B
Does
that
sound
like
the
right
agenda
and
a
rough
right
order?
Any
suggestions
for
additions
or
changes.
B
I
can
do
that,
we
will
do
tag
types
last
and
we
will
start
with
custom
scalar
updates.
So
with
that
andy
I
will
hand
it
to
you.
E
Okay,
hi
everybody.
I
just
want
to
give
a
quick
update,
what
happens
to
farm
where
we
are
and
basically
encourage
everybody
to
engage
if
anybody's
interested,
we
had
a
specific,
smaller
gathering
around
custom
scalers
like
a
couple
of
weeks
already
go,
maybe
one
month,
probably
more
and
and
we
came
up
with
a
rough
vision,
what
we
want
to
do
and,
as
a
result,
we
have
actually
a
new
repository
inside
the
craft
girl
in
in
github,
which
is
called.
E
I
forgot
about
scale
craft
with
scalars
crafted
minor
scales,
yes,
and
so
we
have
a
couple
of
issues
open
two
per
requests,
where
we
kind
of
outline
our
vision,
how
a
custom
scalar
hosting
could
look
like
and
yeah.
I
would
encourage
everybody
to
have
a
look
and
maybe
contribute
to
the
discussion
or
even
more,
if
they're
interested.
B
Nice-
I'm
pretty
excited
about
this.
I
think
it
there's
some
groundwork
required
for
us
to
make
this
tool
useful,
but
thank
you
andy
for
kicking
off
the
effort.
E
No
voice,
I
want
to
one
specific
shoulder
like
I
started
a
pull
request
based
on
gatsby,
and
I
know
there
are
like
also
in
this
call
people
who
know
it
better
much
better
than
I
do,
and
this
idea
was
like
to
use
gatsby
to
to
kind
of
generate
a
specific
scalar
urls
and
have
some
some
governments
around
the
custom.
Scalar
specs,
and
we
don't
know
if
this
is
really
the
right
technology
solution.
So
if
somebody
with
more
knowledge
around
it
would
like
to
have
a
look
at
it.
B
All
right,
well,
there's
a
a
call,
so
if
you're
interested
in
helping
andy
out
with
that,
please
check
out
that
repo
join
in.
I
think
something
pretty
great
could
happen
there.
B
P
P
Lots
of
questions,
but
I'm
gonna
read
up
on
this
repo
first,
but
I
know
that
I'd
like
to
make
sure
to
get
that
implemented
soon
in
graphical
one
and
two
as
well.
So
amazing.
M
So
I
just
have
a
bunch
of
pull
requests
listed
out.
There
aren't
really
any
updates
from
the
last
meeting.
The
first
pull
request
is
just
a
small
one
to
update
the
rfc
from
what
we
discussed
last
time
of
changing
is
final
to
has
next,
so
that's
just
a
small
update.
M
M
The
one
roadblock
with
that
is
that
there's
a
breaking
change
in
the
types
where
the
top
level
graphql
function
can
now
also
return
an
async
interval.
So
we
talked
about
putting
it
into
a
branch
until
the
16
version
was
caught.
The
alphas.
M
M
So
if
that's
okay,
I
think
that
would
be
good
to
get
merged
in
before
anything
else
and
then
that'll
make
the
other
pr
a
little
bit
smaller.
B
I
just
merged
your
first
one,
because
that
one
was
straightforward.
M
Yeah
and
then
otherwise,
we
have
the
our
draft
spec
edit,
looking
to
get
some
feedback
on
that
and
the
I
wrote
up
in
rfc
for
graphql
over
http
of
exactly
how
that
format
is
going
to
be
sent
over
the
wire.
M
So
any
feedback
on
that
too
would
be
good,
and
then
I
think
after
the
other
graphql
js
stuff
is
merged.
Then
we
could
look
at
merging
the
express
graphql
pr.
B
One
suggestion
that
might
allow
us
to
get
out
of
the
deadlock
of
waiting
for
breaking
changes
is
either
introducing
a
flag
on
that
function
or
introducing
a
new
function.
That's
clearly
listed
as
experimental,
just
like
called
experimental
graphql
instead
of
graphql.
B
A
Cool
yeah
sounds
good,
so
my
actually,
I
wanted
to
discuss
idea
how
to
do
that.
So
my
plan
was
to
have
a
branch
and
to
have
a
separate
package
release
either
like
separate,
taco,
separate
package,
because
what
way
we
can
experiment
with
like
one
one
of
the
issue
from
my
side
is
that
execute
function
became
too
polymorphic
with
its
return
value.
So
it
can
return
data
response,
it
can
return
promise
of
response
or
it
can
return
a
sim
kit
rate.
Also,
it's
like
three
different
types
of
return.
A
A
B
I
hope
we
can
land
on
something
that
allows
us
to
maintain
one
one
line
of
history:
the
separate
packages
it
seems
like
it
could
work.
That's
I
see
that
as
probably
the
you
know,
roughly
equivalent
to
having
a
separate
api
but
you're.
You
make
a
good
point
that
as
we're
adding
in
these
additional
capabilities,
the
graphql
function,
the
execute
function
are
becoming
a
lot
more
polymorphic
and
had
we
designed
graphql.js
from
day
one,
we
might
not
have
decided
that
that
polymorphism
was
the
right
thing.
B
Perhaps
you
would
have
decided
that
everything
was
an
async,
iterable
and
just
regular
queries
yielded
one
value
and
then
finalized
immediately
or
something
like
that.
So
it
might
also
be
an
opportunity
to
introduce,
execute
sync
or
execute
async
or
execute
stream
or,
like
separately
named
functions
that
don't
necessarily
only
operate
on.
A
subset
of
queries
like
execute
sync
is
a
subset,
but
execute
async
or
execute
stream
might
be
like
the
total
set,
but
the
response
type
doesn't
need
to
be
polymorphic.
B
I
don't
know
if
that's
the
right
answer,
but
I
think
you
should
consider
exploring
some
directions
like
that,
and
that
could
be
interesting
because
then
you
could
allow,
rather
than
depending
on
one
version
of
the
package
versus
another
version
of
the
package,
there
could
just
be
a
single
version,
but
developers
could
decide
which
subset
they
want
to
support
via
like
which
functions
they
hook
up.
B
But
I
don't
know
if
that's
exactly
the
right
thing,
but
I
just
encourage
you
all
to
kind
of
think
about
what
kind
of
proposals
would
allow
us
to
maintain
a
development
model
that
focuses
on
one
branch
or
one
package
to
ease
maintenance
and
give
developers
some
choice
in
deciding
what
they
want.
Long
term
might
help
us
break
out
of
the
eventually.
There
probably
will
be
some
breaking
changes,
but
there's,
if
there's
a
path
that
allows
us
to
start
to
play
with
that.
That
does
that's
additive
only
that
could
be
pretty
pretty
nice.
B
A
Sorry
go
ahead:
how
about
we
create
experimental,
folder
inside
the
package?
So
when
you
import
stuff
you
import
krake
here,
slash
experimental
squash,
execute
or
execute
stream,
something
so
like.
I'm
I'm
partly
worried.
If
we
mark
something
as
experimental
people,
usually
don't
read
documentation
or
don't
read,
we
actually
have
a
problem
with
documentary,
but
they
don't
read
source
code
only.
They
don't
check
like
doxygen
jazz
dope
comments.
A
B
A
E
Experimenter,
I
want
to
kind
of
emphasize
this
also
like
that's
a
non
big
non-spec
feature,
and
I
don't
know
the
details
and
I
think
even
another
figure
out
but
like
graphical
js,
has
kind
of
a
lighthouse
responsibility.
I
don't
know
if
this
right
word
for
the
ecosystem,
so
people
will
automatically
assume
what
a
graphical
js
provides.
M
E
Kind
of
craft
where
what
graphql
should
provide
and
other
implementations
like
graphql
java
will
have
to
deal
with,
whereas
you
defer
implementation
and
we
have
to
go
back
and
no
it's
not
specified.
We
can't
do
this,
yet
we
don't
so
it's
like.
I
would
highly
encourage
to
to
make
it
clearly
visible
that
this
is
like
a
non-spec
feature
at
the
moment.
A
Yes,
so
why
I'm
actually
it's
an
important
question
because,
as
part
of
a
summer
of
code,
there
is
a
student
working
on
a
new
parcel
for
graphic
js
to
support
a
graphical
use
case
mode
once
use
cases
and
realistically
we
cannot
release
polished
one,
but
at
the
same
time
we
want
to
release
something
by
the
end
of
summer.
So
it's
not
only
stream
and
d4.
We
need
the
place
where
we
can
put
experimental
stuff.
I
agree
with
you,
so
it's
like
reference
implementation.
So,
basically,
if,
if
a
mercenary,
we
promote
it
across
other
implementations.
A
B
B
The
folder
structure
sounds
totally
reasonable
to
me.
My
only
recommendation
would
be.
We
might
like
different
in
this
particular
approach
that
sounds
totally
fine
having
to
import
the
version
of
execute
or
the
version
of
the
graphql
top
level
function
or
whatever
we
decide
to
name
it
from
graphql
experimental.
B
I
think
that
would
be
very
clear
to
people
that
they're
pulling
in
something
that's
likely
not
part
of
the
core
spec,
in
other
cases
like
for
a
flag
on
an
existing
function
like
that
probably
can't
come
from
a
folder,
so
you
just
call
that
flag
experimental,
something
which
we've
that
pattern
already
exists
to
a
degree
in
the
graphical
js
code
base.
G
I
I
have
a
slight
issue
with
this
in
that
for
libraries.
G
We
can
just
sniff
to
see
if
it's
there
so
there's
just
a
slight
javascript,
slash
es
modules,
integration
issue
there
that
I
think,
would
lean
in
the
favor
of
using
names
of
the
function
rather
than
a
specific
path.
That
said,
I'm
happy
either
way.
H
For
for
graphqlgs
and
even
other
implementations,
would
we
want
common
naming
that
distinguishes
a
feature
that
is
in
draft
of
the
graph
ul
spec,
because
even
in
other
implementations,
like
graphql
java,
we
have
interfaces
implementing
interfaces
which
is
you
know
it's
it's
you
know
it's
in.
You
know
the
you
know
it's
in
master,
but
it's
you
know
it's
not
in
the
release,
spec,
and
so
there
might
be.
E
E
And
it's
it's
it's.
I
don't
consider
it
a
traffic
at
all.
It's
a
feature
we
support,
we
implement
it.
We
consider
considered
stable
the
bar
set
by
lee
over
the
years
for
for,
for
things
going
on
is
very
high.
I
have
not
seen
anything
and
please
correct
me
from
wrongly
or
anybody
else
that
that
we
kind
of
reverted
once
merged.
B
Yeah,
I'm
gonna
agree
with
that.
We
we
set
a
super
high
bar
for
things
merging
into
master.
We
basically
consider
if
it's
merged
into
master,
then
it's
extremely
unlikely
to
change
before
an
official
spec
cut.
But
what
andy
said
is
mostly
true.
The
spec
cut
is
meant
as
like
a
legal
process
more
than
like
a
technical
process,
so
we
should
always
be
able
to
treat
whatever's
on
master
as
like
the
continual
point,
and
if
you
we
still
want
to
kind
of
cut
those
once
a
year,
so
we
can
kind
of
point
to
them.
B
But
it's
a
very
you
know
we're
I've
been
modeling.
The
graphql
release
process
off
how
the
javascript
community
has
been,
or
the
ecma
process
has
been
working
out
in
the
last
couple
of
years,
they've
been
doing
something
pretty
similar
where
they
cut
eat
annually,
but
in
practice
really
what
they're
doing
is
each
particular
proposal
makes
its
way
to
draft
stage
or
final
stage
at
a
different
different
times
of
the
year
and
in
practice
each
browser
is
just
picking
them
up
as
they
go
with
their
own
release
processes.
B
B
Those
are
the
ones
that
are
more
on
the
fence.
I
think
typescript
takes
a
pretty
interesting
approach
where
they
they
actually
choose.
That
phase
is
the
one
where
they
release
things.
So
if
something
is
in
the
phase
right
before
it's
officially
merged
into
an
upcoming
release,
then
that's
the
line
where
they
start
to
include
it.
I'm
I'm
okay,
with
this
being
kind
of
up
to
each
library
as
to
what
they
want
to
do.
B
But
my
sense
is
that
process
for
typescript
has
worked
out
reasonably
well
as
a
balance
between
people
wanting
new
features
as
soon
as
they're
discussed
and
people
wanting
stability
over
the
long
run,
because
the
process
can
be
kind
of
reasonably
long
and
you
want
to
balance
between
those
two
and
then
you
know,
I
don't
know
if
we
need
necessarily
like
a
fine
grain
set
of
terminology
that
we
use
is
something
being
experimental
versus
draft
versus
final.
We
can
just
use
experimental
as
just
like
a
catch-all.
That's
like
here's.
B
The
thing
that
we're
testing
that
we
don't
have
confidence
enough
yet
to
say
you
should
use
this.
It's
unlikely
to
change
and
in
the
rare
cases
there
actually
aren't
many
that
I
can
think
of
in
the
past.
But
in
the
rare
case
that
we
would
have
something
that's
in
draft
status
that
changes
in
a
breaking
way,
rather
than
changing
in
probably
like
a
spit
polish
kind
of
way.
Then
we
would
use
this
meeting
in
order
to
figure
out
like
how
to
mitigate
that.
B
B
Okay,
pulling
back
to
the
agenda,
it
sounds
like
next
steps
here
is
actually
just
to
manage
through
some
some
of
these
pull
requests
and
make
sure
that
we
have
a
reasonable
strategy
for
how
to
incorporate
these
things
and
merge
them
in
a
way
that
will
allow
people
to
immediately
start
testing
them
and
making
it
clear
that
they're
they're,
not
official.
Yet.
L
A
quick
clarifying
question,
so
are
we
moving
away
from
experimental
flags
and
then
opting
for
the
experimental
directory
instead,
or
is
this
a
world
where
we
sort
of
support
both,
depending
on
the
use
case,.
B
That's
my
pitch
is
that
we
should
support
both.
I
don't
I
don't
particularly
mind
whatever
the
partic.
Whatever
the
mechanism
is
as
long
as
the
actual
developer
has
to
type
the
word
experimental
or
something
like
it
when
they
go
use
the
thing
that
way
they
don't
have
to
to
to
avon's
point.
They
don't
have
to
discover
it
in
the
documentation
to
realize
that
it's
experimental,
then
we're
good
and
whether
that's
the
name
of
a
function
or
a
flag
being
passed
in
or
a
slash
path
in
the
import.
N
Mark
yeah
thanks
so
okay,
so
the
elevator
pitch
here
is:
we
want
to
be
able
to
say
that
the
you
know,
email
field
on
the
user
type
can
be
written
as
user
dot
email.
N
So
it's
kind
of
intuitive,
hopefully
uncontroversial,
a
bunch
of
tooling
and
libraries
do
this
already,
and
so
that's
kind
of
one
half
of
the
rfc
is
just
kind
of
you
know
officially
ordaining
this
as
part
of
the
spec,
so
there's
no
confusion
over
the
naming
and
then
the
other
rfc
in
that
pull
request
is
being
able
to
take
a
document,
a
query
and
say
that
you
know
lowercase
user
name
corresponds
to
the
name
attributes
on
the
on
the
user
type,
so
kind
of
translating
that,
given
a
schema
and
a
document
being
able
to
map
things
in
that
query
back
to
field
coordinates
on
a
schema.
N
Hopefully
that
made
some
sort
of
sense.
So
I'm
here
today,
because
I've
never
really
kind
of
done
anything
spec
related
before
I
don't.
I
don't
know
what
I
don't
know,
and
so
I
wanted
to
kind
of
get
your
take
on
what
next
steps
might
be,
and
I
also
don't
know
if
this
is
something
where
there's
like
runtime,
like
code
changes
that
need
to
be
made
in
any
of
the
packages.
N
I
wrote
a
library
that
implements
that
second
rfc,
which
goes
from
a
example.
Query
to
a
set
of
field,
coordinates
given
a
corresponding
schema
as
well.
So
it's
unclear
to
me
if
that's
if
that
just
lives
as
like,
you
know
third-party
tooling,
or
if
that's
like
a
function
on
graphql,
js
or
something,
but
I
think
other
than
that
there's
there's
no
sort
of
like
runtime
execution
implications
here.
This
is
just
a
nice
way
of
standardizing
what
different
packages
and
ecosystem
called
the
same
thing,
but
they
do
it
slightly
differently.
N
Yeah,
so
I
I
have
a
link,
let
me,
let
me
put
it
in
the
dock.
It
might
sort
of
explain
it
a
bit
better.
B
N
N
Send
to
everyone
cool,
okay,
okay,
so
it's
a
function
that
takes
in
two
parameters
it
takes
in
a
you
know:
sdl
like
a
big
big,
big
old
blob
of
schema,
and
it
takes
in
a
query
and
given
a
query,
you
can
go
from.
N
You
know
that
query
to
a
set
of
field
coordinates,
and
so
you
know
the
there's
some
subtle
implementation
details
here-
that
that
we
might
want
to
standardize,
because
how
do
you
resolve
you
know
these
leaf
nodes
to
the
to
the
type
in
in
the
schema?
It's
slightly
non-obvious
and
perhaps
controversial
enough.
I
didn't
want
to
combine
these
two
things.
B
N
Yeah
exactly
yeah
and
type
your
pairs
was
like
the
original
name.
I
had,
I
remember
seeing
that
on
some
library
somewhere,
but
I
can't
remember
where,
and
then
someone
suggested
field
coordinates
because
that's
what
they
do
in
graph,
your
java
experiment
correctly
and
a
bunch
of
people
have
already
kind
of
taken
a
look
at
the
issue
that
I
opened
and
gave
me
some
feedback.
So
thanks
to
everyone
who
did
that.
K
K
I've
seen
not
I've
seen
cole
and
I
think
that'll
be
a
discussion
and
then
the
second
thing
is
like
what
does
it
look
like
in
the
spec
and
my
initial
instinct
is,
I
feel
like
once
we
decided
on
the
the
delimiter,
a
non-normative
note,
just
being
like
hey
by
the
way,
if
you're
trying
to
refer
to
I
mean
I
can't
even
say,
if
you're
trying
to
refer
to
user.name,
do
it
with
user.name
feels
like
it
would
be
like
fairly
non-controversial
assuming
the
delimiter
wasn't,
and
I
don't
even
know
you
know
if
it
ends
up
being
useful
in
graphql
js
I
mean
there's
a
ton
of
tooling
in
graphql
js,
that's
just
sort
of
like
utility
functions
that
were
useful
and
not
in
the
spec.
K
Gonna
have
using
it
move
it
in
or
whether
it's
a
third
party
thing,
but
I
feel
like
the
non-normative
note
honestly,
I'm
like
thinking
you
know
it's
the
type
of
thing
that
I
could
imagine
as
we
were
putting
the
first
version
like
hey,
we
always
call
this
username.
Should
we
just
like
mention
that
we
call
it
there
and
we
just
want
to
throw
the
non-normal
node
in.
So
I'm
really
supportive
of
something
like
this.
B
I
would
suggest
keeping
the
actual
utility
mode
separate
just
because
I
can
imagine
a
whole
list
of
questions
that
might
come
out
of
the
woodwork
like
what
happens.
If
you
query
an
interface
type,
does
it
give
you
all
the
potential
things
that
could
be
in
the
interface
or
does
it
give
you
the
interface
itself
and
it's
depending
on
the
actual
thing
you
want
out
of
this?
B
You
would
want
that
to
be
different,
and
it's
probably
also
honestly
just
going
to
iterate
a
lot
faster
if
it's
a
standalone
package,
so
I
I
think
that
particular
step
and
there's
probably
also
more
things
you
want
to
do
like.
Maybe
you
also
want
to
do
the
opposite.
Where
given
field
coordinates
in
a
schema,
you
want
to
extract
the
particular
instance
out
of
there
or
something
like
that.
B
It's
probably
a
whole
host
of
things
that
we
want
to
be
able
to
offer
people
tools
for
that
may
or
may
not
pan
out
to
be
actually
wildly
useful.
B
But
but
it
does
seem
like
a
useful
convention
that
then
we
could
build
these
tools
on
top
of
so
that
that
to
me
feels
like
a
vote
of
confidence.
B
Other
questions
that
I
have
beyond
bike
shedding
about
punctuation
is:
if
we
can
refer
to
a
field
on
a
type,
then
presumably
we'd
want
to
be
able
to
refer
to
any
other
thing
in
a
schema
and
we'll
could
this
proposal
be
expensive
enough
to
cover
all
of
those?
So
I'm
thinking
like
is
the
syntax
for
a
field
on
an
input
object
the
same
as
a
field
on
an
output
object,
considering
that
those
are
like
kind
of
similar
but
kind
of
different.
B
We
should
have
an
answer
to
that
and
or
arguments
on
a
field
on
a
type
like
there's.
That's
another
thing
that
kind
of
shows
up
in
graphical
documentation
that
we
might
want
to
have
a
convention
for,
but
I
I
agree
with
dan
that
this
feels
like
we
could.
B
We
could
stick
this
relatively
high
up
in
the
graphql
spec
as
a
non-normative
note
that
says
when
referring
to
fields
or
when
referring
to
arguments
or
here's,
the
here's,
the
standard
convention
for
doing
so
and
to
the
degree
that
we
can
then
use
that
convention
throughout
the
spec
that
that'll
just
kind
of
cement.
The
pattern
yeah.
K
B
P
I
have
an
idea
of
what
this
could
lead
to
what
if
there
was
like
a
graphql
like
type
literal
notation,
so
that
you
could,
when
specifying
a
field
for
a
type
or
a
field
on
a
type,
you
could
refer
to
a
type
dot
field,
so
you
could
be
like
whatever
user
dot.
Email
is
make
that
the
the
type
used
for
this
field,
whether
it's
a
type
or
a
scalar
it'd,
be
like
a
eventually
down
the
line.
P
N
Totally,
I
think,
to
go
back
to
this
question
earlier
about
how
sort
of
extensible
is
this,
and
can
we
reference
other?
You
know
things
in
the
schema
like
arguments.
There
is
some
discussion
in
the
original
issue
that
I
raised
mark
mark,
andre,
suggested
sort
of
something
similar
to
when
you
you
know
trying
to
use
like
document
query
selectors
and
you
can
specify
sort
of
things
in
square
brackets.
N
So
I
I
I
think
this
yeah,
I
hadn't,
really
considered
that
for
the
first
draft,
how
we
reference
other
things,
other
note
types,
but
I
I
would
like
to
think
that
this
this
could
be
extensible
to
that.
But
I
don't
quite
have
a
clear
picture
about
what
that
looks
like
yet,
but
maybe
that's
something
we
can
to
iterate
on
in
the
in
the
rfc.
P
Might
be
worth
bringing
with
doton
mentioned
that
they're
using
something
similar
in
graphql
mesh
and
in
some
some
packages
of
graphql
tools.
So
maybe
you
all
could
collaborate
on
like
a
standard
for
that
since
they're,
using
a
similar
pattern.
J
Yeah,
actually
we're
using
the
simplest
form
of
of
that,
so
the
first
part
we're
just
using
dot,
and
the
first
part
is
the
type
and
we're
just
taking
the
type
map
and
look
for
the
type
by
name
and
then
use
the
fields
to
find
the
actual
field.
But
that's
right
I
mean
there
are
like
tons
of
other
use
cases
that
might
not
be
supported.
I
think
it
all
depends.
What
are
the
utilities
are
meant
for?
J
I
mean
if
it's
just
finding
a
type
or
field
quickly
or
having
a
standard
for
finding
something
by
name.
So
this
could
be
fine,
but
if
it's
for
more
than
that,
yeah
like
lisa,
if
there
are
like
arguments
and
tons
of
other
use
cases
that
could
make
it
much
more
complicated
but
yeah
we're
using
just
the
simple
way
of
this
kind
of
scoring.
N
Yeah,
I
think
it's
also
worth
clarifying
that
I
you
know
I
did
some
sleeping
on
the
internet
to
try
and
find
what
tooling
wants
this
sort
of
today
and
it's
mostly
kind
of
in
the
space
of
monitoring,
alerting
stuff.
I
know
that's
kind
of
what
we
use
it
for
yep
and
so
generally
that's
kind
of
you,
you,
I'm
gonna.
I'm
gonna
end
up
regressing,
saying
this,
but,
like
generally,
you
kind
of
only
care
about
hey
this
query.
N
You
know
this
field
has
been
accessed
a
hundred
thousand
times,
and
so
we
kind
of
mostly
care
about
sort
of
referencing
fields,
so
kind
of
yeah
go
going
with
that.
With
that
simplest
thing,
first
of
just
being
able
to
reference
a
field
node.
Does
that
seem
like
a
reasonable
thing
to
do?
First,
or
would
you
want
to
see
a
sort
of
comprehensive?
N
We
can
reference
any
you
know
type.
You
know
out
the
gates.
J
Yeah
we
we
also
support
wildcards,
so
you
can
ask
for
query.wildcard
to
get
all
fields,
so
it
could
be.
It
has
the
potential
to
be
complicated.
K
We
have
the
exact
same
thing
where
we
effectively
bump
a
counter
for
user.name,
and
then
you
can
ask
encounter
overuser.name
in
order
to
see
whether
a
given
type
and
field
has
been
used.
My
initial
instinct
is,
I
mean
just
looking
at
the
amount
of
tooling
out
there
that
says
user
dot
name.
This
has
already
kind
of
become
a
de
facto
standard,
and
so
I
see
a
little
downside
to
taking
the
thing
that
is
already
a
de
facto
standard
and
making
it
a
digital
standard,
especially
if
it's
non-normative
doesn't
affect
parsing,
doesn't
affect
execution.
K
It's
a
non-breaking
change,
it's
just.
You
know
if
it
means
that
the
tooling
over
the
next
six
months
we
end
up
with
everyone,
converged
on
a
single
delimiter
instead
of
three
different
delimiters.
That
feels
like
a
pure
win.
I
think
it
could
eventually
expand
to
include
additional
things,
and
I
think
that
probably
would
be
useful
as
well,
especially
if
we
began
to
see
those
emerge
as
de
facto
standards
or
people
started
needing
you
know.
If
I
need
to
refer
to,
you
know
user.name
prefix,
which
is
the
argument.
Do
I
use
colon?
K
Do
I
use
bracket
like
if
we
start
to
see
discussion
there
then
like
having
the
non-normative
note
just
make
a
standard
thing,
but
I
don't
know
I
I
think
if
you
would,
if
you
would
ask
me
six
months
ago,
by
the
way,
did
we
ever
specify
like
user.name
as
a
way
to
refer
to
a
type
in
field
in
the
spec
I
would
have
been
like
I
don't
know
we
might
have
like
it's
so
common.
B
B
Non-Narrative
note
is:
it
means
that
if
you
use
a
colon
instead
of
a
dot,
it
doesn't
all
of
a
sudden
make
you
from
a
legal
point
of
view,
not
graphql,
which
is
like
sounds
pedantic,
but
like
kind
of
important
to
provide
the
flexibility,
because
we
to
your
point
like
there
isn't
actually
like
runtime
code.
That
depends
on
this
existing
beyond
some
tools
that
people
might
build
and
those
are
kind
of
like
you
can
use
them.
If
you
want
to
use
them.
But
you
don't
have
to.
B
I
will
pitch
at
least
going
a
little
bit
beyond
just
the
ability
to
to
reference
fields
and
also
be
able
to
reference
arguments
on
fields,
especially
since
I'm
just
like
following
along
some
of
the
links,
and
you
linked
to
marc
andre's
tweet
from
like
six
months
ago,
talking
about
literally
exactly
this
thing,
which
is
a
a
great
sign
that
this
is
the
right
thing
to
standardize.
B
But
he
in
the
in
the
like
graphql
ruby
example.
It's
talking
about
both
arguments
and
fields.
So
it
seems
like
there's
already
a
pretty
clear
use
case
for
being
able
to
identify
both
of
those
two
things
and
the
fields.
One
is
easy,
like
sure
we
could
like
on
the
punctuation
a
little
bit,
but
it
sounds
like
you're
already
getting
a
sense
that
there's
a
majority
or
at
least
a
plurality
opinion
that
dot
is
the
right
thing,
but
like
what's
the
right
thing
for
arguments,
is
it
a
colon
between
them?
Is
it
parentheses
with
colon?
B
After
the
thing
like
there's
a
handful
of
proposals,
we
could
kind
of
pitch
that
I
think
we
should
it's
worthwhile
to
dial
that
in
to
the
degree
that
are
others
beyond
that,
I
don't
know
like
we
could
just
kind
of
say
you
know
this,
this
reasonably
covered
that
actually
might
reason
to
cover
all
of
them.
I
think
if
you,
if
you
cover
types
fields
and
arguments
we'll
want.
B
You
get
also
like
the
type
of
type.name
you
get
yup
you
get
that
for
free
unions.
Do
you.
B
K
B
Yeah,
I
think
that
might
be
enough
coverage
that
you
could
reasonably
claim.
This
covers
quote
everything,
but
it
also,
I
think
another
part
of
this
discussion-
that's
worth
kind
of
hammering
down
is
purpose,
so
you're
hearing
like
hey
is
this
about.
Is
this
about
taking
a
query
and
decomposing
it
into
field
pairs?
Is
that
what
this
is
for?
Is
this
about
wild
card
sub
selection,
in
which
case,
what's
the
syntax
for
wild
cards?
Or
is
it
not
about
those
things?
In
which
case
you
say
like
firm
line
in
the
sand?
B
Like
that's
not
part
of
this
discussion
at
all,
I
think
for
the
rsc
to
move
forward.
That's
another
thing
that
you
should
stake
a
hard
claim
on
be
crisp
about
exactly
what
problem
you're
solving
my
read
on
this
is
crisply.
The
problem
is,
there
are
components
of
your
schema
that
you
want
to
be
able
to
have
a
unique
identifier
for
that's
human
readable
and
that
should
be
able
to
a
given
a
schema,
and
given
one
of
these
unique
identifiers,
you
should
be
able
to
like
find
that
thing
and
b.
B
Someone
should
be
able
to
read
it
both
in
tooling
and
in
like
error
reports
or
something
like
that
and
and
make
sense
of
it.
In
fact,
dan.
Maybe
that's
the
the
case
where
we've
done
this
before
I
think
error
reports
in.
K
P
N
Playground
yeah,
so
I
I
think
what
he
said
about
the
problem
statement
is
it's
certainly
like
very,
very
true
and
and
and
that's
kind
of,
like
the
problem
statements
of
like
that,
the
first
rfc
that
I
put
out
and
then
the
second
document
is
the
problem
statement.
There
is:
how
do
you
go
from
a
query
to
a
list
of
those
fields,
so
you
can
increment
a
sort
of
metrics
counter
somewhere
and
there's
sort
of
existing
tool
link
that
does
this
as
well,
like,
I
think,
apollo,
studio
kind
of
does
this.
N
B
Maybe
another
way
to
assemble
that,
instead
of
thinking
about
them
as
like
different
unique
problem
statements
is
instead
to
frame
it
as
a
use
case.
So
you
can
crisp
up
your
your
problem
statement
as
you
want
to
be
able
to
uniquely
identify
some
component
of
your
schema
where
a
component
can
be
a
type,
a
field
on
that
type
or
an
argument
on
that
field
and
and
then
like
why?
Okay,
why
is
that
useful?
B
Then
you
might
want
to
translate
a
query
to
those
unique
identifiers
or
documentation
where
you
might
want
to
refer
to
a
particular
component
of
the
schema
and
make
it
hyperlinkable
and
go
to
the
appropriate
place
again.
You
need
a
unique
identifier,
so
I
think
those
are
just
two,
but
you
could
probably
come
up
with
a
handful
of
these
that
are
that
are
all
those
and
then
you
don't
need
to
worry
about
like
do.
B
I
need
to
go
through
a
spec
process
or
have
a
problem
statement
or
whatever
for
the
actual
details
of
how
to
implement
those
now
you've
like
packaged
it
all
up.
As
like
one
thing
of
unique
identifiers
for
components
of
schemas
and
and
then
all
the
acts.
The
actual
implementations
of
those
bits
and
pieces
can
just
be
packages
that
you
go
build
to
the
degree
that
you're
interested
in
building
them.
N
E
I
want
to
add,
I
want
to
add
an
aspect
quickly
like
it's
not
only
about
the
ability
to
name
like
identify,
something
specifically
for
me.
There's
equally
value
in
actually
giving
this
thing
a
name
itself
so
like
calling
it
field
coordinates
it's
a
really
valuable
thing
in
forming
like
a
consistent
mindset
around
constructs
in
the
ecosystem.
E
B
I
agree,
and
especially
if,
if
you're
going
to
scope
arguments
in
which
again,
I
recommend
that
you
would
because
there's
I
see
a
clear
use
case
for
them
that
aligns
to
the
others,
then
is
field
coordinate
still
the
right
name.
So
we
could
maybe
like
shut
on
the
naming
a
bit.
N
Okay,
I
will
incorporate
as
best
I
can,
to
feedback
in
an
rfc
and
start
annoying.
You
all
some
more
through
vrs
and
we'll
see
where
we
go
from
there.
B
Thanks
nice,
I
I
moved
your
the
issue
that
you
created
on
graphql
spec
from
straw
man
to
proposal
just
to
kind
of
capture
the
fact
that
this
is
something
that
we're
interested
in
moving
forward.
Sweet
thanks.
I
Dennis
hello,
everyone,
so
I
hope
you
are
hear
me
well
and
yeah.
The
point
of
me
being
here
is
actually
discussing
a
few
things
about
the
existing
implementation
and
the
existing
protocol,
which
is
at
apollo
side
and
it's
kind
of
mind-boggling
for
me
to
be
honest,
that
it's
so
unmaintained
and
it's
like
really
stale
and
the
question
that
I
want
to
ask
like.
The
first
question
I
want
to
ask
is
how
many
of
custom
implementations
are
you
guys
aware
of
I
mean
do
you
are
sockets?
I
Yeah
so
it's
kind
of
weird
for
me
to
look
at
that
project
and
see
so
many
pr's,
and
so
many
issues
and
just
like
nobody's
working
on
it.
So
I
first
had
this
thing
where
I
wanted
to
implement
subscriptions
some
time
ago,
and
then
I
used
the
like
library
that
everybody
uses
like
the
thing
that
I
feel
that
everybody
uses
and
it's
just
kind
of
broken,
to
be
honest,
like
to
not
censor
the
words
that
I'm
using
but
yeah.
The
question
actually
is
yeah.
I
So
I
I
tend
this
this
project,
which
you
can
find
a
link
to
in
my
agenda
item.
So
you
can
find
the
existing
aggregate
of
all
important
and
pressing
issues
with
the
existing
subscriptions
transport
over
websocket
thing
and
a
pr
draft
pr
which
is
like
a
refresh
of
the
protocol,
handling
some
security
implications,
which
are
quite
serious
for
me.
I
So
I
read
about
an
issue
which
is
like
you
can
circumvent
the
actual
onconnect
callback,
so
not
even
issue
or
connect
initialization
request,
and
you
can
still
start
subscriptions
or
start
operations
on
top
of
that
which
is
kind
of
like
wow.
How
is
this
not
fixed
and
how
do
people
not
care
about
it
so
yeah?
I
really
want
to
have
this
approach
to
this,
where
I
want
to
tackle
the
security
implications
first
and
then
go
after
that.
So
the
first
thing
that
I'm
working
on
currently
is
just
the
subscription.
I
So
the
things
that
I
realized
the
other
day
is
that
this
protocol,
which
apollo
has
written
down,
is
not
just
about
subscriptions.
It's
also
about
all
the
other
operations
you
can
make
like
the
mutations
and
the
queries,
and
the
only
thing
that
happens
is
that
the
stream
so
to
say,
completes
once
the
query
gets
resolved
and
for
me
personally
and
the
thing
that
I
want
to
ask
you
all
is:
how
often
is
this
actually
used?
How
often
do
you
use
a
real-time
stateless,
socket
to
communicate
operations
which
are
just
like
request
response,
so.
G
I
think
that
queries
and
mutations
are
reasonably
common
over
websocket
connections,
partly
from
before
http
2,
where
there
was
quite
a
lot
of
overhead
with
doing
those
requests,
particularly
we
have
like
query
batching
from
a
few
years
back,
but
that
solved
really
well
by
just
doing
it
over
a
websocket
connection.
Now
we've
got
http
2
sure
that
solves
it
in
another
way,
but
that
very,
very
low
network
overhead
of
websockets
does
make
it
attractive.
F
I
Yeah,
so
for
me
I
see
the
overhead
of
maintaining
the
actual
socket
connection,
because
you
have
to
worry
that
you
are
still
connected
that
you're
not
kicked
out
because
of
various
reasons
like
losing
a
network
or
something
like
that
so
like
having
this
overhead
of
maintaining
actual
sockets
to
just
do
queries
and
to
do
mutations
like
just
the
two
operations
without
the
sub.
Without
the
subscriptions
part,
I
don't
know,
I
don't
know
how
to
balance
that
out.
F
B
Facebook,
their
their
setup
works
that
way
they
they
maintain
stateless
requests
over
http
while
they
have
their
real-time
data
coming
in.
I
don't
know
if
they
still
use
mqtt
or
if
they're
fully
switched
web
sockets,
but
they've
got
they've
got
a
real-time
connection.
That's
only
used
for
subscriptions
live
data.
F
They
they
had
mqtt
over
web
sockets,
so
it's
about
best
of
both
worlds
but
but
another
another
thing
I
mean
this
is
just
kind
of
surrounding
context,
not
necessarily
answering
your
question,
but
the
other
reason
why
you,
you
don't
necessarily
want
to
merge.
The
two
onto
a
single
transport
is
because
they
have
different
scaling
characteristics
right
and
they
so
scaling
a
real-time
gateway,
looks
very
different
from
scaling.
F
A
stateless
request
response
api
tier
because
the
stateless
request,
api
tier
scales
horizontally,
but
the
real-time
gateway
needs
some
sort
of
some
sort
of
map
of
you
know
here
all
the
the
browsers
or
your
mobile
instances
that
are
connected
via
whatever
web
sockets.
F
And
then
you
have
to
have
some
fan
out
solutions,
so
just
architecturally
looks
different,
which
is
one
of
the
reasons
why
facebook
didn't
merge
the
two
and
run
everything
over
one
connection,
and
I
think
what
I
would
want
to
see
is
some
some
strong
case
to
be
made
like,
I
think,
and
maybe
I'm
being
maybe
I'm
overreaching
here,
but
I
think
people
who
start
off
that
you
know
they
they
look
at
like.
F
Oh
okay,
why
do
I
have
to
do
a
regular
http
for
request
response
and
then
websockets
or
sse
or
whatever,
for
you
know,
live
queries
and
subscriptions?
Why
can't
I
just
put
everything
on
a
single
channel?
Isn't
that
cleaner?
Isn't
that
more
efficient?
F
And
what
I
would
want
to
see
is
some
real
evidence
that
that
is
causing
a
bottleneck
somewhere,
that
that
is
something
that
is
so
what,
for
example,
one
there
are
real
problems
with
that
right.
There
are
real
problems
where
it's
very
common
to
do
things
like
I'm
gonna,
send
a
mutation
and
I'm
gonna
subscribe
to
the
result,
because
the
result
is
a
stream
and
what
happens
when
you
do
that
across
two
different
transports.
F
Is
that
you
have
a
race
condition
and
if
you
can
have
some
sort
of
like
like
atomic
ordering
of
of
receive
an
ack
across
a
single
transport,
then
you
avoid
that
kind
of
thing
which
I
think
is
a
powerful
scenario.
But
but
that's
the
kind
of
argument
I
would
want
to
see
in
order
to
say,
hey
look.
The
really
strong
recommendation
is
consolidate.
Everything
onto
a
single
transport.
H
Now
the
the
graphical
spec
has
traditionally
remained
kind
of
agnostic
of
transport
level
concerns
especially
around
subscriptions,
and
I
think
a
lot
of
that
is
because
these
scaling
concerns
are
not
one
size
fits
all
for
for
some
for
a
lot.
You
know
a
lot
of
use
cases,
you're,
never
gonna
need
to
scale,
and
so
you
know
you
can
do
things
that
are
maybe
simpler
to
implement.
H
So
the
question
is
kind
of.
As
you
know,
the
scope
of
this
working
group
there
is
the
over
http
separate
working
group
is:
would
this
fall
under
that?
Would
that
be?
You
know
a
good
thing
to
take
on,
or
is
this
even
kind
of
distinct
from
that?
If
we're
talking
specifically
about
web
sockets
so
with.
G
Regard
to
the
http
spec
working
group,
I
think
that
that's
why
we're
effectively
here
asking
this
question:
why
dennis
is
here
to
gather
more
information
to
give
the
http
spec
working
group
more
context?
I
think
this
is
def.
G
This
won't
be
in
like
the
version
one
of
the
http
spec,
because
that's
generally
only
to
cover
the
existing
like
query
and
mutation
use
cases,
but
I
think
it's
very
we're
keen
to
add
it
afterwards
and
the
the
staleness
and
the
security
issues
in
the
existing
websocket
implementations
need
to
be
addressed
in
a
very
clean
way,
which
is
why
we'd
like
to
know
more
about
how
people
are
implementing
this,
so
that
we
can
make
sure
that
we
don't
write
up
in
a
spec
any
of
these
mistakes,
for
example,.
F
Yeah,
I
think
the
security
issues
are
is,
are
a
really
good
point.
What
is
so?
I
think,
for
example,
we
could
make
a
case
that
this
is
a.
This
is
a
core
infrastructure
project
that
we
should
bring
under
the
umbrella
ownership
of
the
the
foundation.
It
seems
to
me
like
without
this.
This
is
so
I
I
do
think
this.
F
This
particular
repo
that
you
linked
to
dennis
is
is
the
de
facto
solution
right,
because
it's
kind
of
the
one
that
is
in
all
the
documentation
examples,
especially
around
the
apollo
stack
and
so
given
that
I
think
what
we'll
see
is
just
generally
organic
adoption
using
this
library
and
to
the
extent
that
this
library
includes
a
critical
security
problem,
we
should
definitely
address
that
either
by
working
with
the
maintainer.
Do
you
know
the
maintainer.
J
Well,
there
is
no
main
generator
moment
me
and
rory
was
part
of
the
initial
implementation
about
two
years
ago.
I
think
when
he
added
the,
I
think,
terrible
since
then,
apollo
was
working
on
that
it's
not
highly
highly
maintained
at
the
moment
it
does
work,
and
personally
I
wouldn't
define
it
as
like
production
ready,
especially
because
of
the
security
concerns
and
the
way
that
some
use
cases
are
not
handled
correctly,
mostly
around
security
authentication
over
web
sockets.
J
It
might
be
a
bit
tricky
in
some
cases
and
I
think,
in
terms
of
documentation,
this
library
lacks
some
because
people
are
treating
it
as
a
graphql
websocket
transport
instead
of
subscriptions
transport
and,
as
you
said,
abusing
it
and
using
queries
and
mutations
over
over
the
websocket
yeah,
it
leads
to
to
to
to
a
stateless
server
and
yeah
and
including
the
the
security
concerns.
I
think
yeah
people
should
think
again
yeah
it's
kind
of
it's
not
a
matter
of
like
like
that
implementation,
or
something
like
that.
J
F
I
I
I
think
it's
still
things
that
should
be
discussed
at
the
graphql
over
http
thing,
because
we
should
be
looking
at
the
security
implications
first
and
then
discussing
the
other
things
like,
for
example,
what's
happening.
Also
in
the
subscriptions
transport
ws
library,
which
is
currently
used
by
almost
everyone,
is
that
they
are
kind
of
manipulating
errors
or
they're
swallowing
them.
I
So
I
was
already
doing
a
lot
of
work
just
to
get
the
basics
working,
and
I
understand
that
the
security
implications
are
kind
of
difficult
to
solve,
especially
because
you
cannot
set
custom
headers
when
you
want
to
initialize
and
upgrade
an
http
to
a
websocket
communication
protocol.
I
And
you
can,
and
you
can
use
the
url
sure
you
can
send
say
jwt
token
through
the
url,
but
we
still
have
to
be
aware
that,
even
if
you
are
communicating
through
a
secure
network
using
ssl
or
tls,
the
urls
are
still
exposed
and
people
can
see
them.
So
my
initial
approach
to
this
was
to
still
use
the
initial
message,
like
the
connection
initialize
and
pass
through
the
connection
parameters
to
that,
but
kick
the
client
off
as
soon
as
something
feels
wrong
or
even
if
the
timeout
is
happening.
I
So
if
you
connect
to
a
server
say
and
the
client
is
just
staying
there
consuming
resources
doing
no
connection
initializations,
it
just
would
be
kicked
off
after
a
specific
timeout
and
the
this
actually
is
a
good
segue
to
another
question
that
I
have,
and
I
would
like
it
to
be
answered
in
terms
of
how
how
how,
if
you
know
how
many
people
are
actually
conforming
to
the
current
existing
protocol
that
has
been
written
and
how
actually,
how
much
wiggle
room
do.
I
I
have
to
kind
of
manipulate
the
protocol,
because
I
would
like
to
rewrite
it
from
scratch.
It
wouldn't
just
be
a
refresh.
I
would
like
to
like
approach
this
really
seriously
through
rfcs
and
communications
and
discussions
and
whatever
and
just
like,
solve
this
properly
and
then
allow
implementations
to
live
on
top
of
the
protocol
and
the
protocol
being
the
starting
point
of
it.
B
I
think
you
should
do
that.
The
the
spec
itself
says
very
little
about
the
protocol,
so
the
spec
itself
just
talks
about
the
abstraction
mechanics
of
how
a
graphql
server
and
a
graphql
client
would
communicate
with
the
stream.
So
as
long
as
you're
you're,
not
going
so
far
outside
the
bounds
that
it's
outside
of
spec
compliance.
Actually,
even
then,
if
you
find
that
actually
the
right
thing
to
do
is
is
counter
or
slightly
askew,
from
what
the
spec
suggests.
I
J
Was
written
when
we
wrote
the
library
the
only
link
to
that
protocol
is
between
the
client
for
subscriptions
and
the
server
for
the
subscriptions
which
are
in
the
same
library,
so
the
the
subscriptions
client
and
the
subscriptions
server.
They
are
the
only
two
parts
that
are
aware
of
this
protocol.
So
I
think,
from
my
point
of
view,
you
can
feel
free
to
break
it
and
rewrite
it
from
scratch
and
do
whatever
you
want
with
it,
because
it
could
be
improved.
J
A
lot
and,
as
you
said,
error
handling
is
not
that
good.
At
the.
I
Moment
so
the
fact
is
that
it
can
be
improved
a
lot,
but
I
have
a
feeling
that
servers
follow
this
protocol
and
might
even
make
custom
implica
implementations
of
them,
but
the
client
is
kind
of
broken.
So
what
what
felt
natural
for
me
is
when
I
started
working
on
this
library.
The
first
thing
that
I
did
is,
I
implemented
the
client
side
of
it,
leaving
the
service
to
comply
and
conform
to
the
protocol.
That's
already
existing.
I
So
how
big
of
a
breaking
change
would
this
be?
Where
I
don't
know
people
would
get
kicked
off,
because
in
the
current
protocol
specifications
you
can
still
have
the
socket
long
living,
even
though
you
get
errors
or
the
connection
cannot
be
established
and
it
it
would
be
a
pretty
radical
change
in
what
I
kinda
envisioned
in
my
head.
J
I
think
it
comes
in
both
sides.
I
mean,
if
you're,
using
subscriptions
this
specific
library
for
subscriptions
on
the
server
you
you're
using
the
same
one
for
the
client
yeah
so
yeah.
So
I
I
think
it
won't
be
a
breaking
change.
J
I
mean
it
does
a
breaking
change,
but
all
people
that
are
using
it
for
front-end
will
use
the
same
library
for
the
back-end
because
it
comes
together
with
the
same
typings
library
and
everything
else
related
to
it.
So
I
think,
in
terms
of
the
protocol,
this
is
something
that
could
be
changed.
B
Yeah
for
sure,
for
sure
I
think
you
should
feel
free
to
run
with
it.
I
I
noticed
your
your
example
on
the
front
page
of
that
repo
showing
how
to
link
it
up
with
relay
it's
exactly.
Why
relay
was
assembled
that
way
to
make
it
easy
to
stick
whatever
kind
of
protocol
level
piece
that
you
want
on.
On
top
of
that
network
transport
is
to
be
able
to
support
lots
of
different
modes.
I
know
facebook
internally
does
not
implement
the
apollo
websocket
spec,
it's.
B
It
looks
completely
different
because
they
have
a
completely
different
service
and
it
doesn't.
It
probably
won't
look
anything
like
what
you're
doing
next
either
and
that
like
seam
between
the
clients,
graphql
clients
and
then
the
actual
protocol
implementations
is
intentional
to
provide
the
flexibility
to
explore
new
stuff.
B
One
thing
that
you
might
consider,
though-
and
this
would
just
be
pure
value-
add
not
necessarily
a
constraint
or
a
limitation
is,
if
you
want
to
pitch
this
as
a
improvement
or
something
that
you
should
use.
Instead
of
this
existing
subscriptions
protocol,
spec,
then
perhaps
there's
a
migration
path
right
because
like
if
you
have
to
have
both
the
server
and
the
client
on
board,
to
make
this
work
then
like
which
do
you
change?
B
B
So
I've
just
told
you
that
there's
security
problems
and
there's
other
kinds
of
problems
and
here's
the
thing
that
solves
that
here's,
how
you
would
adopt
it
if
you're
already
using
that
other
thing,
I
think
I
think
that'll
actually
be
useful
in
terms
of
helping
people
get
to
the
place
that
you
want
them
to
be.
But
if,
if
you
find
that
that's
kind
of
at
an
impasse-
and
it's
pretty
tough
to
do
that,
then
that
might
be
okay,
even
just
saying.
Here's
a
here's
like
a
counter
example
that
solves
these
problems.
It's
still
probably
worthwhile.
I
So
what
I
have
in
mind
is
kind
of
keeping
the
server
api
almost
the
same,
so
I
would
still
suggest-
and
I
would
still
write
a
migration
script
where
you
would
transfer
your
existing
library
from
the
subscriptions
thingy
to
the
library
that
I'm
writing,
but
I
wouldn't
have
a
middle
solution.
So
it
wouldn't
be
something
okay.
F
Dennis
I
think
I
think,
you're
on
really
onto
something.
This
definitely
needs
work.
I
mean
if
there
are
security
issues
with
with
respect
to
upgrading,
then
that's
probably
the
p0
to
tackle
but
yeah.
I
think
starting
okay
without
tackling
the
issue
of
how
you
do
this
incrementally
just
for
a
moment.
I
recommend
thinking
about
this
as
three
separate
layers.
F
The
one
is
the
transport
layer
and
the
second
is
the
protocol
layer
and
the
third
is
the
graphql
payload
itself,
and
so,
let's
really
quickly
think
of
some
examples
of
variations,
because
if
you
have
to
do
this,
for,
like
you
know,
protocol
on
top
of
comet
you're
gonna
get
this
combinatorial
explosion,
it's
best
to
just
specify
this
protocol.
That
says:
look
some
whatever
whatever
it
is,
whatever
transport
layer,
whatever
bi-directional
stable
transport
layer,
can
do
this
or
fake
the
appearance
of
a
bi-directional
transport
layer.
F
Here's
the
protocol
that
goes
across
it
right,
and
this
is
the
thing
that
you're
right.
This
is
the
thing:
that's
not
in
the
spec
that'll
say
things
like
connection
open
connection,
closed
connection,
suspended,
payload
or
payload
received.
You
know
send
subscription
that
kind
of
thing
right,
but,
but
I
just
I
suggest
separating
that
from
the
protocol
itself
right.
So
in
other
words,
you
could
have
something
that
you
could
have
a
scenario
where
your
websocket
connection
to
the
gateway
is
totally
fine
and
healthy.
You
can
ping
and
you
can.
F
You
can
receive
acts
all
day,
but
when
you
send
a
subscription,
maybe
there's
something
behind
that
tier
where
the
subscription
server
itself
is
under
heavy
load
and
it's
dropping
payloads,
and
you
want
to
be
able
to
communicate
that
fact
and
say
something
like
this.
Particular
stream
is
in
a
suspended
state
right.
So
those
are
those
are
things
that
I
think
should
be
going
to
the
payload
and
those
are
the
things
that
we
intentionally
left
out
of
the
spec.
F
But
you
also
don't
want
to
couple
that
to
a
particular
transport,
because
you
know
transports
are
going
to
come
and
go
and
people
are
going
to
have
infrastructure
constraints
about
what
transports
they
can
support.
F
So
I
think
the
maybe
the
first
step
forward
is
to
kind
of
take
a
look
at
what
you
can
do
to
extract
the
protocol
and
write
a
spec
around
the
protocol
or
maybe
mini
spec.
I
don't.
I
don't
think
this
should
be
a
heavyweight
process,
but
just
to
say
something
like
look.
There's
some
notion
of
a
request,
followed
by
a
response
stream
and
examples
of
these.
F
We
know
of
are
subscriptions
and
live
queries,
and
you
know
if
you
kind
of
tilt
your
head
a
little
bit
to
further
stream
right,
but
then
you
have
so
you
have
this
protocol
that
can
express
this
and
I
can
tell
the
client
look.
What
you
should
do
is
what
you
you
should
now
expect
a
stream
of
results
to
follow.
It
should
be
able
to
tell
the
client
something
like
you
should
expect
that,
but
we're
but
we're
pausing
your
stream,
for
whatever
reason,
maybe
bandwidth
constraints,
maybe
whatever
right.
F
F
But
you
can
specify
that
and
and
use
that
as
a
common.
So
imagine
that
you
know
you
can
you
can
wrap
that
in
maybe
something
like
async
or
durable,
but
you
you
have
the
ability
to
reconstitute
that
protocol
into
some
sort
of
language
specific.
You
know.
Maybe
it's
an
rx
stream.
Maybe
it's
an
async
interval.
Maybe
it's
it's.
You
know.
Maybe
it's
callbacks
who
knows
right,
but
am
I
making
any
sense?
Yeah
yep,
okay,.
I
I
would
also
write
migrations
where
you
would
transfer
from
the
existing
subscriptions
thing
that
has
that
has
not
been
maintained
by
apollo
to
this
library
itself
and
yeah
kicking
it
out
from
there
so
feel
free
to.
There
is
an
rfc
about
the
new
protocol
that
I've
been
thinking
about.
It's
pretty
strict
and
it
takes
the
security
implementations
implications.
Sorry
as
a
fresco
citizen
and
yeah.
Thanks
for
your.
B
G
Absolutely
glad
that
you're
digging
into
this
one
one
last
explicit
question
on
this:
for
people
that
are
not
using
the
subscriptions
transport
ws
from
apollo,
for
example,
in
other
languages
or
other
such
things.
What
are
you
using
for
websocket
connections?
Maybe
you
could
share
that
with
dennis.
H
At
netflix,
I'm
supporting
two
things:
server
sun
events
is
kind
of
the
the
large
scale
thing
that
works
well
with
our
layer.
Seven
proxy,
that's
you
know
that's
one
of
the
main
reasons,
and
so
there
is
an
open
source,
client
library
for
that
in
javascript,
where
we
actually,
we
forked
that
internally
and
so.
H
H
The
the
open
source
module
you
can,
google
it
pretty
easily,
I
think
but
yeah
I
could
find
that,
but
yeah
we
ended
up
forking.
That
actually
is
the
version
we're
using.
We
could
probably
open
source
that,
if
there's
interest
and
then
for
websockets,
we
you
know
on
the
server
side-
it's
not
written
in
javascript,
so
it
doesn't
use
this
library.
H
But
on
the
client
side,
we
are
matching
this
protocol
and
the
reason
is
purely
to
be
able
to
use
graphical
off
the
shelf,
because
it's
really
nice
to
be
able
to
leverage
that
for
developer
use
case,
and
for
that
use
case
it
doesn't
need
to
scale
really,
and
so
you
know
and
security
concerns
aren't
as
much
it's
inside
of
a
vpn
also,
and
so
there
is
some
value
in
just
having
this
kind
of
canonical
implementation
that
fits
with
the
tooling
like
graphical.
P
B
Okay,
good
to
know,
I
know
facebook's
still,
and
this
is
a
quirky
implementation
detail,
but
there's
still
mqtt
over
websockets.
I
believe
that's
still
the
case
and
that's
in
part
for
historical
reasons,
because
their
original
real-time
service
was
all
built
in
terms
of
mqtt
and
then
when
it
became
clear
that
websockets
was
the
preferred
low-level
protocol
for
communicating
with
the
browser.
So
I
think
it
does
straight
mqtt
to
mobile
devices,
but
it
does
mqtt
over
websockets
to
browsers,
I'm
pretty
sure,
that's
still
correct.
F
H
B
There's
they
they
do
both,
and
it
depends
on
the
particular
kind
of
thing
that
they're
subscribing
to
because
they're,
backed
by
different
services
and
in
some
cases,
long
polling
is
the
more
efficient
way
to
do
it
and,
in
some
cases,
actual
real
time
push.
So
I
believe,
chat
messaging,
that
entire
back
end
is
end
to
end
async
pushy,
but
there's
other
things
that
are
like
subscribing
to
changes
on
objects
where
a
polling
model
is
actually
more
efficient.
B
Q
F
As
an
example
of
the
necessity
for
creating
an
abstract
protocol
on
top
of
different
transports,
I
mean
I
think,
steven
brought
up
a
really
good
point
right,
like
sse,
is
a
different
transport
versus
web
sockets,
but
it
would
be
kind
of
a
pain
to
deal
with
a
slight
variation
in
protocol,
just
because
you
have
that
that
one
difference
and
even
in
the
facebook
case
live
queries,
goes
over
r
sockets,
for
example.
So
you
know
these
are.
These
are
largely
like
at
the
developer
level
at
the
api
level.
K
B
Okay,
well,
in
the
sake
of
time,
we
should
keep
moving,
but
then
just
let
us
know
if
you
have
any
other
open
questions
that
need
answered.
You
can
always
do
that
async
over
slack
as
well.
All
right.
Let's
talk
about
typescript
dotan,.
J
I
think
the
best
way
to
to
show
what
I
mean
is
it
will
do
a
screen
share
yep.
Can
you
see
it?
Yes,
this
code
screen
yeah,
okay,
so
basically
the
concept
that
we
were
we
had
is
to
take
the
basic
document
node
and
add
two
generics
to
it.
J
This
is
how
it
looks
like
so
document
node
with
two
generics
means
that
these
are
bundled
into
the
type
itself
and
burned
into
the
instance
that
we're
using
this
is
just
first
query
and
I'm
using
a
patched
version
of
graphql
to
have
this
supported.
So
the
idea
is
that,
just
by
passing
this
object,
this
typed
document,
node
typescript,
is
able
to
type
the
result
type
and
the
variables
type.
J
J
Just
like
that,
behind
the
scenes,
I'm
using
a
graphical
coding
to
generate
the
signature
of
the
result
type
in
the
variables
type,
but
the
idea
is
that
this
could
be
typed
manually
or
by
any
other
solution.
It
could
be
even
integrated
into
ides
to
have
this
supported
inline.
J
This
was
this
is
already
available
with,
if
you're
using
bubble
for
bubble
with
cojon.
So
this
comes
in
line,
so
the
idea
is,
you
can
have
this
typed
variables
are
also
typed,
because
everything
is
inferred
from
the
original
object,
so
I
don't
need
to
do
anything
else
to
to
get
this
kind
of
type
validation
in
terms
of
implementation.
J
It
basically
means
that
we're
taking
the
default
methods
that
are
accessing
the
the
document
node
object
and
we
type
them
all
all
over
all
across
the
way
until
the
result
type
and
then
typescript
is
being
able
to
infer
that
and
have
it
automatically
typed.
Nothing
here
is
breaking
in
terms
of
like
the
changes
and
how
it
affects,
because
we
can
have
a
default
object,
so
everything
else
should
work.
J
The
same
way,
so
there
is
no
spec
issue
for
that,
because
this
is
fairly
specific
to
typescript
and
graphql
gs,
but
I
wanted
to
hear
your
thoughts
on
that.
This
is
not
final.
I
mean
there
are
like
a
few
more
things
to
to
think
on.
For
example,
graphql
coding
is
able
to
tell
if
variables
are
needed
at
all
or
they
could
be
optional,
so
this
and
maybe
maybe
could
be
moved
into
the
infrared
type.
But
but
this
is
a
breaking
change.
P
That's
it
I.
I
was
experimenting
with
this
the
other
day
and
I
and
I
thought
it
was
amazing.
One
thing
I
was
wondering
about
when
implementing
it.
I
couldn't
seem
to
figure
out
how
to
get
it,
working
with
queries
that
were
not
defined
in
graphql
files.
J
There
is
a
library
that
uses
graphql
coding
to
provide
inline
typings
on
the
fly,
and
then
this
works
with
the
bubble
plugin
for
vs
code,
so
it
works
pretty
nice,
okay,
yeah
so,
and
graphql
coding
can
extract
the
operations
for
you,
but
then
it
won't
work.
It's
a
bit
tricky
the
ideal
way
to
to
use.
It
is.
J
If
you
have
your
operations
written
in
a
dot
graphql
file,
then
graphql
coding
can
pick
it
up,
recompile
it
and
create
this
type
document
node
for
you
yeah,
but
this
could
work,
as
I
said,
with
manual
typing.
If
someone
wants
to
do
it
and
apollo
client.
P
Yeah
one
thing
I
wanted
to
make
sure
of,
though,
so
I've
been
spending
a
lot
of
time
on
embedded
graphql
support
in
different
languages
like
typescript
and
javascript
for
vs
code
graphco
about
to
launch
a
bunch
about
to
release
a
bunch
of
new
features
for
embedded,
typescript
support,
and
so
as
long
as
we
have
some
kind
of
like
a
a
some
kind
of
tag,
template
or
some
kind
of
pattern
like
that,
then
it
makes
it
very
easy
to
highlight
graphql
in
line
and
to
add
language
features,
and
you
know,
completion
and
stuff
like
that.
P
So
as
long
I'm
just
worried
that
this
tool
will
lead
to
people
just
not
using,
but
I
guess
I
can't
foresee
how
like
I
guess,
you
would
have
to
change
your
your,
how
your
applications
are
organized
to
use
that
graphql
files
more
at
least
how
it
stands
now,
but
wherever
it
goes,
it'd
be
cool,
even
if
it's
just
like
a
pass-through
tag,
template
function
or
something
like
that.
You
know
it
just.
J
Yeah
think
about,
if
you're,
for
example,
your
operation
corporations
are
inlined
and
in
like
your
component
file
and
easier
for
you,
so
you
eventually
do
some
kind
of
manipulation.
It's
either
using
parse
or
graphical
tag
or
whatever
to
compile
it.
P
P
J
Yeah
yeah
so
I'll
share
some
links
in
a
minute,
but
I
mean
there
is
a
way
to
do
that
only
with
bubble
at
the
moment,
but
I
think
this
could
be
you're
right.
Maybe
this
could
be
path
through
and
then
you
can
have
the
types
built
in
based
on
the
operations
that
you
already
have
right.
C
J
Oh,
I
see
okay,
it's
defaulted
here,
and
this
is
like
how
the
so
we
published
a
library
that
extends
the
basic
document
code
and
gives
those
patches
for
patchings
libraries.
So
this
is
how
it
looks
like
so
it's
defaulted
all
all
across
the
way,
so
it
shouldn't
be
any
breaking
changes
for
anyone.
C
B
This
looks
great,
I
mean
as
long
as
there's
no
breaking
change
a
which
you've
covered
and
b
the
developer
experience
of
actually
using
these
types
is
at
worst
the
same
then
there's
no
downside
right
like
this
is
not
saying
that
you
have
to
use
these
in
order
to
supply
types.
This
is
just
yet
another
way
to
incorporate
generated
types
in
with
the
core
componentry
of
how
graphql
executes.
So
it's
providing
additional
information
to
the
execute
function.
That
seems
like
a
pure
win
to
me.
B
The
only
potential
downside
is
additional
complexity,
but
even
then
this
diff
is
not
particularly
large,
so
I
think
even
then
the
cost
is
quite
small.
So,
from
my
point
of
view,
this
looks
great.
I
think
it's
just
a
matter
of
of
you
and
yvonne
making
sure
you
get
through
the
code
review
process
and
get
it
in
place.
I
know
there's
also
some
progress
that
I
know
you're
involved
with
and
doing
the
typescript
migration
overall.
B
So
there's
some
complication
there,
but
you
and
yvonne
are
much
more
informed
about
how
to
handle
that
than
I
am.
A
A
A
A
So
my
issue
I
want
to
discuss
here
and-
and
it's
I
think
it's
important
to
discuss
actually
in
this
group-
is
how
typescript
specific
should
graphql
jsb,
because
it's
not
only
this
issue.
A
We
go
especially
static
types
of
language,
you
can,
you
cannot
port
it,
and
so
this
issue
and
people
often
constantly
open
similar
issues
and
adding
stuff,
for
example,
like
inferring
resolver
type
types
from
resolvers
into
into
schema
itself.
It
was
like
suggestion
by
by
mike
to
to
create
something
like
graphql
nexus,
like
type
inference
for,
and
I'm
said,
I'm
also
worried
about
becoming
too
typescript
specific,
especially
like
my
biggest
question
for
this
functionality
why
it
cannot
be
separate
function
called
typed,
execute.
A
So
we
like,
for
example,
radiant
arguments
to
note
so
to
document
nodes,
so
document
not
becoming
not
just
a
node
but
not
loose
some
type
information,
so
I'm
like,
I
feel
like
if
we
merge
with
one
why
people
would
suggest
as
a
typescript
specific
functionality.
A
So
I'm
I'm
like
so
especially
especially
like
my
point
was
always
that
types
should
reflect
runtime
behavior
and
since
we
cannot
guarantee
that
we
return
this
value
by
graphql
js
itself.
So
graphql
js
cannot
ensure
that
return
value
will
be
matching
it's
ensured
by
cod
gem,
not
but
by
graphql
js.
So
it's
basically
like
glorified
type
conversion.
B
I'm
going
to
suggest
first
of
all,
we
should
absolutely
set
up
a
a
graphical,
js
specific
call.
I
think,
that'll
be
really
worthwhile
because
there's
a
lot
of
detailed
stuff
to
dig
into.
Let's
do
that.
B
B
B
So
in
this
particular
case
it
seems
like
nothing
is
lost
and
only
like
there's
the
the
behavior
of
the
typescript
type
remains
equivalent
if
you
do
not
provide
additional
information,
but
you
can-
and
there
are
packages
that
want
to
consume
those
types
and
add
that
information
and
use
the
execute
function
in
a
way
that
provides
additional
type
detail.
That
seems
like
a
pure
win
with
a
little
downside.
Now
I
would
I
agree
with
you
that
I
would.
B
Those
in
different
ways
is
a
worthwhile
thing,
so
I
I
would
suggest
the
lens
that
we
use
is
enable
changes
to
typescript
that
provide
capability
like
hooks,
but
not
in
cases
that
narrow
those
capabilities
by
hard
coding.
The
like
one
particular
way
to
do
things,
and
hopefully
that
helps
us
navigate
this.
But
if
there's
particular
cases
where
we
want
to
like
noodle
out
how
those
two
guidances
come
together,
then
we
can.
We
can
do
that
on
a
on
a
graphql,
js
call.
J
Yeah
just
a
side
note,
the
major
benefit
of
this
feature
is
not
graphql
gs.
It's
all
the
client,
libraries
that
are
consuming
document
node
from
graphql
gs
because
they
will
get
free,
typings
and
type
inference
for
hooks
components,
high
order
components,
it
doesn't
matter
how
they're
occurring
the
data.
So
that's
the
the
major
benefit.
It's
there,
nice.
B
J
Steps
yeah,
so
I
I
just
wanted
to
talk
about
a
bit
about
the
next
steps
and
what
should
we
do
next
in
terms
of
typescript
migration
in
graphql?
Yes,
I'll,
try
to
keep
it
short
so
so
far
we
are
following
the
the
plan
that
even
wrote
it's
going
great
and
we
are
having
some
nice
progress
in
graphql
gs
and
express
graphic
and
some
others.
J
So
this
is
nice
progress,
but
I
think
we
can
maybe
rethink
this
or
maybe
rethink
the
next
steps,
and
maybe
this
should
be.
We
can
break
it
down
to
smaller
tasks
and
then
the
communi
community
can
take
part
of
on
this
migration.
J
Personally,
I
have
I
had
some
time
and
I
started
to
put
some
effort
to
migrate
tests,
linting
and
some
some
stuff
related
to
it,
and
I'm
willing
to
put
some
more
effort
just
wanted
to
bring
this
up
to
here.
What
are
your
thoughts
and
if
and
if
this
is
something
that
is
important
for
others
as
it's
important
for
us,
because
if
so,
we
are
on
board
on
doing
this.
Migration.
A
And
everybody
was
involved
like
apollo,
and
so
I
feel
like
korea
for
issue
here,
I'm
basically
a
bottleneck
for
a
lot
of
free
stuff,
and
it's
not
only
like
help
from
communities
actually
reviewing.
As
andy
said.
Initially,
we
have
like
very
high
bar
for
for
code
quality
for
standards,
and
so
basically
it
means
I
review
every
code
line
and
it's
like
a
lot
of
effort,
especially
like
for
mass
conversion.
A
So
on
a
technical
side
like
I
trying
to
figure
out
a
ways
how
to
separate
syntax
changing
from
meaningful
changes,
because,
like
synthetic
changes,
you
don't
need
to
review
everyone
for
for
me
for
changes
you
need
to.
But
core
issue
here
is
like
a
bus
factor,
especially
I'm
like
I'm
experiencing
it.
This
month
I
had
a
knee
surgery,
so
I
was,
I
was
in
hospital
and
stuff,
so
I
wasn't
communicating
or
imagine
stuff
and
let's
block
a
bunch
of
people,
including
extreme
and
defer
effort
and
other
efforts.
A
A
A
A
Help
with
some
aspects,
especially
for
for
things
like
typescript,
it's
not
the
architectural.
B
Together
for
improving
the
bus
factor,
here's
my
concrete
suggestions,
let's
first
of
all,
set
up
that
graphql.js
specific
call,
I
think
it'll
be
useful
to
have
a
time,
probably
monthly,
where
you
know
more.
Progress
will
happen
between
those
calls,
but
it's
just
like
an
opportunity
for
all
of
us
to
get
together,
synchronously
and
talk
about
these
kinds
of
things.
B
We
can
keep
them
also
kind
of
focused
on
these,
like
not
specific
code
that
we're
trying
to
get
in,
but
like
strategy
and
another
thing
we
should
start
to
do
and
maybe
ivan
you
and
I
can
work
on
this-
is
list
out
contributors
to
graphql,
js
and
decide
here's
the
ones
that
we
want
to
consider
owners
like
right
now
in
the
past,
it's
been
you
and
me,
and
now
it's
more
just
you
alone.
What
other
people
do
we
want
to
consider
like
trusted
reviewers
with
merge
capabilities.
B
Other
ones
we
want
to
start
to
like
move
along
on
that
path,
so
people
who
we
can
give
review
capabilities,
but
not
necessarily
merge
capabilities,
and
we
can
start
to
build
a
plan
for
how
to
move
more
people
along
that
path.
B
You
never
want
to
get
to
the
point
where
you
have
like
a
zillion
reviewers,
because
you'll
you'll,
just
like
you'll,
lose
that
shared
vision,
but
as
long
as
you
keep
it
a
tight
core
set
of
people
like
a
couple
and
they're
in
constant
communication,
then
I
think
that
that
process
tends
to
work
very
well
for
open
source
projects.
So
I
think
we
can
get
ourselves
there
and
reduce
the
bus
factor.
A
Yeah,
so
I'm
actually
like
doing
it
right
now
with
two
people,
so
I
think
nice,
it's
enough
for
it's
like
it's
half
my
time
so
like
I
have
less
time
to
write
code
on
my
own
and
that's
normal.
It's
always
happened
like
that,
but
I
don't
feel
like
I
have
capacity
to
on
board
more
more
mountaineers,
especially
since
in
autumn
we
should
get
like
summer
of
document
season,
of
documentation,
technical
writer
and
work
with
him.
So
I
actually
think,
like
we
have
an
initial
batch
and
at
the
center
I
don't
feel
like.
E
A
Two
to
three
right
so,
especially
since
I
discussed
with
daniel
an
idea
is,
after
after
on
board
him
for
him
to
choose
a
person
to
work
with
and
on
board.
So
I
basically
want
to
do
chain
and
I
discuss
with
him
and
he
he
knows
that
it's
it's
a
plan
so
like
after
and
board
daniel
daniel
choose
somebody
who
he
feel
comfortable
to
work
with
or
help
with
peers.
B
Plan
yeah
protocol
definitely
yeah.
Let's,
let's
set
up
the
call
first
and
the
rest
yvonne
you
and
I
can
figure
out
offline.
I
want
to
make
sure
we
have
plenty
of
time
to
dig
into
the
attack
type
rfc.
So
let's
move
on
and
talk
about
that
next
benji,
it's
all
you.
G
Yeah,
hey
sorry,
I
just
went
to
grab
a
glass
of
water,
so
no.
G
Hello
cool,
so,
as
we
discussed
last
last
working
group,
we
made
progress
on
the
in
input
unions
and
decided
that
possibly
the
tagged
type
was
one
of
the
leading
ideas
there.
So
I've
speak
I've
taken
some
time
to
write
up
a
draft
rfc
for
that
which
is
linked
from
the
agenda.
G
Broadly,
the
tag
type
is
very
interesting.
It's
the
first
type,
that's
not
a
wrapper
type,
such
as
the
list
type
or
non-null,
where
it
can
be
valid
for
both
input
and
output,
and
it's
actually
defined
based
on
what
its
fields
are.
So
if
its
fields
are
all
input
types
then
it
will
be
valid
for
input
if
its
fields
are
all
output
types
and
then
it
will
be
valid
for
output.
G
So
if
it
were
a
scalar
only
type
where
all
of
the
fields
or
what
we're
calling
members
were
all
scalars,
then
it
would
be
valid
for
both
input
and
output,
which
is
quite
interesting.
G
I've
outlined
yeah
the
changes
that
I
think
would
be
necessary
to
the
spec,
based
on
this
broadly
inspired
by
the
union
type.
Basically,
so
I've
gone
through,
seeing
where
the
union
type
is
used
and
referenced.
That
and
also
input
objects,
we've
discussed
before
effectively
what
the
tagged
type
is,
but,
as
a
summary,
the
tag
type
would
be
a
new
type
introduced
to
graphql.
G
G
They'll
have
an
associated
type
with
them,
just
like
the
other
fields
would
have
they
currently
don't
accept
arguments
I
don't
think
they
ever
will
they
currently
don't
accept
directives,
but
that
may
or
may
not
change.
I
can
imagine
that
the
skip
and
include
directives
might
be
useful
for
them.
Potentially,
the
idea
is,
you
would
request
so
for
querying.
You
would
request
a
selection
set
like
you
normally
would
and
you
would
get
back
at
most.
No,
you
would
get
back
exactly
one
of
those
fields.
G
G
G
G
Things
such
as,
should
it
actually
be
a
separate
type,
or
should
it
be
one
of
the
existing
types
with
like
the
one
field
directive,
which
is
what
was
originally
proposed
well
over
a
year
ago
and
there's
good
reasons
for
it
to
be
a
separate
type,
namely,
it
enables
us
to
evolve
the
the
type
in
a
in
a
separate
way.
It
also
doesn't
really
have
as
much
in
common
with
the
other
fields,
as
you
might
at
first
think.
So.
Things
like
you
know
not
having
arguments
and
other
such
things
make
it.
G
One
interesting
open
question
on
it
at
the
moment,
for
me,
is
how
it
behaves
with
regard
to
nullability
and
the
non-null
constraint,
specifically
how
I
originally
imagined
it
would
be
that
there
would
be
one
field
and
that
field
would
be
non-nullable
so
you'd
end
up
either
with
a
null
result
for
the
entire
tag
to
type
or
you'd
end
up
with
something
with
a
field
and
that
field
having
a
non-null
value.
G
However,
that's
been
we've
discussed
this
and
I
think
it's
not
necessarily
the
best
plan
at
the
moment,
because
if
we
don't,
if
we
don't
require
that,
then
we
enable
to
use
more
of
the
shared
logic
between
the
other
types.
So
we
can
throw
an
error
and
have
that
caught
at
the
relevant
boundary
rather
than
raising
up
that
extra
level
through
the
tact
type.
G
An
interesting
divergence
from
graphql
currently
is
at
the
moment
in
graphql.
When
you
query
any
selection
set,
you
can
add
a
double
underscore
type
name
to
it,
and
that
will
still
be
true,
but
previously
any
time
that
a
double
underscore
type
name
was
returned.
It
would
always
refer
to
an
object
type.
So
if
you
queried
it
on
a
union
or
an
interface,
it
would
still
give
you
the
underlying
concrete
objects
type
and
now
it
would
also
give
you
the
tagged
type
name.
G
If
you
were
to
query
it
in
that
part
of
the
selection
set,
it's
been
added
there
just
to
make
sure
that
we
maintain
compatibility
with
all
the
clients,
because
they
may
not
know
whether
it's
a
tag
type
or
not,
so
allowing
them
to
query
it.
There
works
well,
and
I
think
it's
generally
beneficial
another
option.
There
would
be
to
potentially
return
like
what
the
expected
type
of
that
thing
would
be,
but
that
opens
a
number
of
problems,
particularly
with
regard
to
saying.
G
Well,
if
this
says
it's
a
cat,
but
actually
the
child
field
under
it
is
a
cat,
then
we're
we're
being
confusing
there,
because
we're
expecting
certain
fields
to
be
present
which
are
not
so
using
the
tag
type
name.
There
definitely
makes
more
sense
one
interesting
thing,
because
it
can
be
valid
for
input
and
output,
but
it
might
not
be
so
if
it
had
only
input
fields,
you
couldn't
use
it
on
an
output,
for
example,
I
think
we
could
look
at
adding
to
introspection
into
the
double
underscore
type
type.
G
A
shortcut
field
for
is
input
type
and
is
output
type
based
on
the
spec
algorithm
of.
Is
it
an
input
type?
Is
it
an
output
type
and
that
would
be
helpful
to
clients?
I
think
at
the
moment
to
determine
whether
a
tagged
union
is
an
input
type
or
an
output
type.
You
have
to
not
only
look
at
its
fields,
but
you
have
to
look
at
their
fields
and
their
fields
all
the
way
down
the
tree.
G
G
Another
interesting
question
on
it
is:
should
we
allow
field
aliases?
So
if
you
say
that
this
tagged
type
can
only
have
one
field
set
and
say,
you've
got
cat
and
dog,
should
you
be
able
to
alias
cat
to
feline,
for
example?
Is
that
an
okay
thing
to
do?
Can
you
refer
to
the
same
field?
G
More
than
once,
feline
colon
cat
and
also
cat
colon
cat
is
that,
okay
to
do,
and
so
far
the
rfc
that
I've
raised
doesn't
put
any
restrictions
on
that
you
can
do
it
the
same
as
you
would
with
any
other
selection
set,
and
I
think,
that's
probably
the
correct
direction,
but
it
is
an
interesting
question
that
probably
warrants
discussion,
so
that
was
rather
a
lot
of
information.
Does
anyone
have
some
questions
that
they'd
like
to
ask.
G
Yes,
I
think
you
should
I've
not
put
any
restrictions
with
regard
to
fragment,
spreads
on
tag
types,
and
I
think
that's
a
perfectly
valid
thing
to
do.
It
allows
you
to
if
you,
if
you
you,
can
then
keep
in
one
location
what
all
the
possibilities
of
a
type
type
are
and
then
every
time
you
refer
to
it,
just
splat
out
that
that
fragment,
which
I
think
is
beneficial.
E
Can
can
you
quickly
explain,
I
I
see
this
rfc
for
the
first
time.
I
followed
the
input
discussion
a
little
bit,
but
so
the
fundamental
idea
is
that
that
you
can
always
only
return
or
provide
exactly
one
of
the
fields
in
a
text
type.
Is
this
a
gist?
Is
this
correct.
E
And
one
one
of
the
immediate
concerns
or
like
immediate
confusion
from
my
side,
is
like
the
the
breaking
change
of
the
type
name
thing
like
type
name.
Returning
objects
is
actually
really
really
fundamental
aspect
of
graphql
and
a
lot
of
semantics
implicitly
rely
on
this.
So
like
breaking
this,
I'm
wondering
like
yeah
that
that's
a
big
change
like
this
has
an
impact
on
a
quite
of
different
aspects.
I
think
not
saying
that's
the
wrong
thing
to
do,
but
it
is
a
big
change.
B
The
there's
there's
a
hard
trade-off
here.
Andy,
I'm
curious
what
your
opinion
is
honestly,
because
there's
two
kind
of
long-standing
assumptions
to
how
graphql
works
that
one
of
which
we'll
have
to
break
one
of
them
is
one
that
you
just
said,
which
is
anytime.
You
ask
for
type
name.
You
always
get
an
object,
type
name
back.
B
The
other
one.
Is
that
anywhere
you
see
a
curly
brace
typeset.
You
can
always
ask
for
under
type
name.
So
if
you
ask
for
dunder
type
name
on
a
tag
type,
then
presumably
you
should
get
the
name
of
that
type,
which
is
not
an
object
type,
or
do
we
make
it
so
that
this
is
one
of
the
places
where
you
are
not
allowed
to
ask
for
gender
type
name.
G
So,
in
my
opinion,
the
the
approach
of
doing
what
I've
done
in
the
rfc
is
the
right
approach
and
the
reason
for
that
being
that
many
pieces
of
tooling
that
issue
queries,
don't
actually
know
what
the
schema
is.
E
E
We
call
it
normalized
queries,
which
is
basically
a
pre-analyzed
crash,
which
kind
of
lets
you
expand.
All
the
all
the
different
aspects
of
a
query
to
this
is
actually
what
comes
down
at
the
when
you
execute
it
in
terms
of
objects,
so
you
can
expand
all
fragments
or
unions
or
interfaces
and
kind
of
pre-analyze
the
whole
query
and
you
can
get
away
with
I.
E
Actually,
these
are
the
five
possible
object,
types
that
could
be
returned
and-
and
this
is
like
I'm
thinking
in
this
direction-
that
the
changes
this
way
of
how
you
can
analyze
a
query
overall,
because
you
introduce
a
real
new
type
and-
and
I'm
not
sure
yet
about
the
implications.
R
E
R
E
G
For
craft
good
yeah,
adding
a
new
type
is
definitely
a
big
change
anyway,
but
I
think
it's
something
that
we
need
to
do
for
for
input
polymorphism
and
the
the
symmetry
I'm
all
for.
E
P
I
was
able
to
implement
it
all
the
way
up
to
graphical
before
the
original
input
union
rfc
from
like
almost
two
years
ago.
I
think
so.
I
I'm
I'm
aware,
at
least
from
my
end
from
the
ide,
tooling,
lsp
vs
code.
Extensions
and
graphical
code
mirror
end
of
things.
What
the
effort
is
and
it's
a
new
keyword
yeah
it's
a
new
type.
That's
all
that's
a
lot
yeah,
it's
not
easy,
but
it's
worth
it.
P
G
Yeah
another
way,
another
interesting
feature
of
it
is,
as
I
say,
we're
currently
calling
these
these
fields.
Members
and
that's
because
we
already
have
fields
which
are
used
for
output
types,
and
we
already
have
input
fields
which
are
used
for
input
types.
G
Input
fields
are
much
more
similar
to
the
tagged
fields
in
that
they
don't
support
arguments,
for
example,
but
again
if
we
wanted
to
evolve
input
fields
in
future,
that
might
cause
issues
if
we
were
to
type
the
members
of
a
tag
type
and
the
input
fields
of
an
input
type
together.
So
again,
we
go
with
a
separate
additional
thing,
which
means
now
the
introspection
schema
introspection.
G
Queries
a
bit
bigger
tooling,
has
narrowed
three
branches
through
there
to
get
the
relevant
fields,
but
I
think
the
the
trade-offs
are
worth
it
in
regard
to
enabling
the
future
expansion
of
graphql.
E
I'm
interested
like
I'm
looking
at
your
pets
example
and
like
if
you
return
a
single
pet
like
not
a
list
of
pets
and-
and
you
query
like
cat
and
dog
sorry
for
this
naive,
honest
thing,
but
this
is
this
very
similar
to
what
you
would
do
with
a
fragment
then
like
you
would
get
back
one
of
these
twos
like
if
you,
if
you
just
have
like
one
pad
and
it's
a
of
type
tact,
that
you
query
cats
and
dog,
but
you
only
get
one
bag.
This
is
how
it
would
work.
G
Yes,
so
imagine
that
you
had
an
output
type
and
a
regular
object
type
and
that
had
two
fields
on
it:
cat
and
dog,
and
you
had
an
internal
constraint.
That
said,
you
may
only
return
one
of
these.
It
would
be
like
the
result
to
that,
except
for
whichever
key
is
not
specified,
it's
not
matched,
whichever
one
would
have
returned
null
is
actually
not
present,
but
other
than
that.
It's
the
same.
So
it's
the
same
structure.
It's
another
nested
object,
but
the.
E
It's
like
you,
you
you
would
actually
yeah,
you
would
remove
the
nike.
You
would
get
if
it's,
if
it's
a,
if
it's
a
union,
for
example.
Yes,
do
I
get
this
right.
G
G
E
It's
just
just
out
of
my
head.
I
I
can
see
the
reasoning
introducing
timeline,
even
if
it
breaks
current
assumption,
because
I
think
you're
right
with
with
the
like
the
clients,
need
to
have
the
ability
to
ask
what
comes
back.
That's
very
important.
I
agree
with
that.
That's.
B
That's
yeah.
There
was
also
another
potential
in
the
earlier
discussions.
We
were
having
around
input
unions.
It's
interesting,
we've
landed
here
because
a
lot
of
the
discussion
is
actually
happening
about
their
behavior
in
the
output
system,
because
the
original
problem
statement
was
to
handle
the
input
system.
That,
in
my
mind,
is
actually
success,
because
it
means
that
we've
found
something.
That's
generally
interesting
for
both
cases
and
solves
problems
in
both.
So
that's
a
great
outcome
but
relevant
to
the
discussion
you're
just
having
andy
is.
We
were
in
earlier
in
discussion.
B
One
of
the
alternate
proposals
was
thinking
about
how
to
provide
rough
shapes
of
inputs,
match
them
to
the
appropriate
type
in
an
input
union,
and
one
of
the
suggestions
for
doing
so
was
to
use
dunder
type
name,
so
you
can
provide
under
type
name
as
part
of
your
input,
object
and
supply
the
string
with
the
name
of
the
type
that
you
expect,
that
input
object,
actual
data
to
be
matched
to
and
that
that
would
also
sort
of
like
break
this
assumption.
That
type
name
refers
explicitly
to
an
object
type.
B
In
that
case,
it
would
refer
to
an
input,
object
type,
it's
used
in
a
different
context,
of
course,
but
I
I
think
it's
interesting
that
in
both
cases
we
landed
on
something
that
started
to
blur
that
assumption.
B
So
perhaps
we
need
to
question
whether
that
assumption
is
a
reasonable
one
and
and
think
more
about
tactically,
if,
if
there's
a
breaking
change
involved
with
with
changing
it,
like.
E
One
big
question
is
like,
like
I
remember
these
proposals,
where
you
would
specify
the
type
name
as
an
input
argument.
How
is
this
solved
in
this
proposal?
Like
I
see
like
you,
can
detect
string
filter
is
used
for
input
and
output,
and
how
and
you
would
you
need
to
be
required
to
specify
exactly
one
of
the
fields,
and
this
is
the
marker.
What
what
should
go
in
is
this
how
it
works.
G
E
G
Yes,
so
it's
been
a
little
while,
since
I
actually
wrote
this
rfc
up,
so
I'm
a
little
bit
fuzzy,
but
I
remember
that
I
did
have
a
hard
time
deciding
exactly
the
coercion
rules
for
it.
So
if
you've
got
the
rfc
open
and
you
were
to
go
to
section
three
and
then
line
1535
which
I'll
share
a
link
to
in
chat
wherever
chat's
gone
there,
it
is.
G
G
Yeah,
this
is
in
input
collision.
Yes,
so
this
is
depending
on
what
the
user
sends
through
to
you.
What
what
errors
should
we
raise?
G
So
we've
made
it
so
that
if
you
say
that
it
is
a
tag
type
and
you
were
to
specify
like
a
null
and
b
one
two
three,
that
would
explicitly
be
an
error
because
you
have
specified
more
than
one
key,
for
example,
and
the
where
that
gets
interesting
is
when
it
then
relates
to
variables
what
if
you
were
to
say
that
your
input
was
where
you
had
variables
that
reference
the
keys
of
the
the
object
rather
than
the
the
sorry,
the
tagged
type
rather
than
the
entire
tag
type
itself
and
how
those
are
handled.
G
That's
where
things
I
think,
get
a
bit
more
interesting.
I
the
way
that
I've
specified
it.
I
think,
should
allow
you
to
do
that
and
to
have
it.
Do
the
right
thing
what
I
feel
that
is
the
right
thing,
but
it's
a
yeah.
I
think
there's
going
to
be
quite
some
interesting
debate
on
that
subject.
B
There's
already
a
relatively
nuanced
distinction
between
optionality
availability,
and
I
wonder
if
that's
that's
the
right
thing
to
latch
on
to
here
to
solve
this,
but
I
agree
that
it's
a
potential
for
confusion
and
frustration.
If
you
supply
multiple
variables,
one
of
them
either
defaults
to
null
or
you
provide
null
or
something
like
that
and
it
flows
through
to
one
of
these
things,
and
then
it
ends
up
after
you've
resolved
the
variables
becoming
exactly
the
case
that
you
should
said
should
explicitly
be
an
error
where
one
of
the
fields
exists,
but
it
is
null.
G
So
so
yeah
at
the
moment,
I've
done
exactly
that,
so
I've
treated
optionality
and
nullability
as
separate.
So
you
can
specify
multiple
keys
as
as
variables
and
then
exactly
one
of
those
variables
must
be
supplied
and
the
others
must
mustn't
be
null,
but
they
must
be
literally
not
present.
G
It
may
be
clearer
if
we
would
and
potentially
more
flexible
and
less
irritating
if
we
were
actually
to
go
ahead
and
require
that
all
of
the
members
of
a
tagged
type
were
non-nullable.
That
would
then
make
the
the
input
and
the
output
of
that
easier
to
do.
Then
you
for
output,
you
could
just
say
if
tagged.a,
then
you
would
know
that
it's
there
without
having
to
necessarily
say
well.
If
the
tagged
thing
has
a
key.
G
What
is
that
key
and
then
look
up
the
property
of
it,
which
you
know
is
a
different
thing,
depending
on
what
language,
you're
programming
with
sure.
G
Because
you
can
query
it
with
a
selection
set,
there
may
always
be
a
selection
set
that
queries
these
fields.
So
you
might
deprecate
one
to
say,
like
you
shouldn't
request
this
anymore
but
effectively,
so
my
opinion
would
be.
If
you
deprecate
a
field,
a
member
of
a
tag
type,
then
you
should
never
effectively
resolve
to
that
tag
type
having
that
value,
but
you
should
still
always
accept
queries
upon
it.
G
When
it
comes
to
inputs,
you
should
still
accept
it
as
an
input
and
you
need
to
to
handle
the
relevant
thing,
but
since
only
one
key
is
present
and
since
all
of
the
members
can
be
non-nullable,
I
don't
think
that
the
null
ability
ties
into
the
deprecated
in
quite
the
same
way
that
it
does
for
object
types.
E
One
one
aspect
that
also,
I
see
here
kind
of
like
where
we
evolve.
If
we
use
this
nicer
term,
it's
like
we
have
it's
the
first
time
that
we're
not
the
first
to
maybe
but
like
you,
it's
it's
okay
to
have
to
specify
fields,
and
these
fields
are
not
present
at
all
in
the
result,
without
an
error,
if
this
is
this
is
correct
right,
you
can
like
it's.
G
G
If
you
were
to
add
a
a
field
to
a
union
but
sorry
a
type
to
a
union,
then
your
code
may
not
handle
the
situation
where
that
extra
type
is
is
added,
and
you
really
need
a
default
case
on
your
switch
statement
or
whatever
it
is
that
you're
coding
with
the
same
would
be
true
of
the
the
tag
type,
and
this
is
actually
an
interesting
thing
I
forgot
to
raise,
which
is
the
only
way
to
know
what
a
tag
tape
would
be
is
to
explicitly
request
all
of
the
members
of
that
tag.
E
G
You're
not
going
to
know
that
it
was
a
fox
and
that
that's
what
you
should
have.
Potentially
we
could
add
another
introspection
field
there
for
like
what
should
it
have
been.
B
But
I
think
I
wonder
if
this
is
just
a
non-problem
right,
because
what
people
are
doing
right
now
is
using
that,
if
they're
using
a
union
type
they're
using
type
name
as
the
key
in
that
switch
and
and
if
it
comes
like,
if
you
said,
I'm
gonna
write
a
query
fragment
for
cat
and
a
query
fragment
for
dog
and
not
one
for
fox,
then,
realistically,
what
my
code
generated
code
look
like
or
manually
code
looks
like
is
switch.
If
it's
the
type
name
is
cat.
Do
this?
B
If
the
type
name
is
dog,
do
that
default?
Do
something
else,
and
it's
like
not
the
fact
that
it's
fox
it
might
as
well
have
been
alien
or
a
bunch
of
random
ascii
characters
like
it.
It
doesn't
matter.
That's
all
the
default
case,
because,
presumably
at
that
moment,
when
the
query
was
written
either
the
author
didn't
know
about
fox
or
it
straight
up
wasn't
part
of
the
the
schema
in
which
case
who
cares?
B
G
Completely
agree,
the
the
only
difference
that
I
would
raise
is
it's
often
useful
in
that
default
handler
to
log
out.
You
know
this
case
was
not
handled,
and
that
may
even
be
something
useful
for
sending
over
to
like
roll
bar
or
century
or
some
other
tracking
system,
and
we
wouldn't
have
the
equivalent,
unlike
we
do
with
unions,
but
I
I
really
again
don't
think
is
a
big
deal,
which
is
why
I've
not
written
it
into
the
rfc,
and
we
could
always
add
it
later.
If
we
need
to.
H
One
one
quick
note
is
that
this
is
very
similar
to
the
feature
one
of
in
protos,
and
so
in
proto
v3,
for
example,
there
is
actually
a
special
method
that
just
gets
like.
Basically
what
you're
describing
through
introspection.
You
know,
just
which
one
of
these
things
is
it
good
to
know
that
exists
good
president.
E
Yeah
like
I
would
entertain
the
idea
that
so
the
question
would
be
like
tax
can
only
return.
One
of
the
possible
options
very
similar
to
union
right
so
so,
like
underscore
underscore
type
name,
could
actually
include
the
information.
G
So
like
like
it
could,
so
you
could
say:
oh
it's
a
you
know,
it's
a
it's,
a
pet
object,
it's
a
pet
tagged,
but
it
is
then
a
cat.
You
could
again.
That
would
be
a
very
different
behavior
for
type
name.
Normally
type
name
would
refer
to
the
name
of
a
type
and
tagged
is
effect,
is
a
type.
You
know
it's
represented
by
dunder
type
in
the
introspection,
so
I
would
expect
to
be
able
to
look
it
up
in
there.
So
that
would
be
a
very
different
behavior.
E
It's
it's
a
well,
I'm
not
sure
it
would
be
so
different,
because
type
name
like
interfaces
are
real
types,
but
they
never
returned
by
type
name
right.
So
it's
like
you,
you
you
just
because
it's
a
real
type
doesn't
have
to
be
returned
by
tightening.
So
it
comes
down
a
little
bit
too.
E
I
know
it
looks
a
little
bit
awkward
and
I
don't
have
a
good
solution
for
this
in
my
mind,
but
type
name
so
far
conveys
like
the
runtime
information.
What
the
result
of
the
query
is
when
it's
executed
and
that
and
tag
has
very
similar
semantics
to
union.
If
you
understand
correctly-
and
there
is
a
real
type
associated
to
tag
which
represents
the
real
query,
result
right.
E
So
there
is
like
I'm
wondering
if
there's
not
a
possibility-
or
maybe
we
should
talk
about
this-
to
enhance
this
and
give
it
back
that
there
is
this
real
type
of.
There
is
only
one
type
of
this
tech
type
returned
and
you
should
be
able
to
query
it
if
this
makes
sense.
G
I
think
that
would
be
an
interesting
sort
of
hack
in
my
mind.
I
think
it
would
be
better
to
represent
that
with
an
additional
property
if
it
was
needed,
because
at
the
moment,
whatever
you
get
back
from
double
underscore
type
name,
you
can
then
look
up
in
the
dunder
types
in
the
types
query.
Sorry
schema
types
record
set
to
find
the
type
with
that
name,
and
even
even
if
that
were
to
support
things
other
than
object
types.
It
would
still
find
a
record
from
that
from
that
list.
G
If
we
were
to
change
it
to
have
dot
or
triangular
brackets
or
whatever
else,
it
would
no
longer
be
able
to
do
that.
So
I
think
that's
more
of
a
breaking
change
that
should
be
represented.
C
Yeah
one
thing
about
that
is:
if
you
have
object
types
as
the
members
of
the
text
type
and
you
were
to
very
under
type
name
on
the
text
type
and
then
the
object
type
as
well,
then
you
would
have
the
same
type
twice
in
the
result,
which
is
not
a
problem
per
se,
but
a
little
bit
weird.
Perhaps.
G
We
certainly
couldn't
return
the
the
object,
type's
name
directly,
because
then
we'd
be
saying
effectively.
This
is
a
cat,
and
so
it
has
name
and
number
of
lives
and
whatnot,
but
actually
it
doesn't
only
has
one
property
cat,
so
it
must
not
have
the
exact
same
type
name,
but
it
could
have
a
derivative.
E
G
Yeah,
they
can
be
interfaces,
tagged,
unions,
input
objects
and
scalars.
G
Can
be
anything
also,
we
have
no
restrictions.
All
the
members
of
tech
type
can
be
anything
the
only
restrictions
are.
You
can't
have
like
an
input
type
as
one
field
and
an
output
type
as
another
field,
because
that
would
make
the
entire
tag
type
unrepresentable,
on
either
input
or
output.
B
But
that's
the
only
reason:
yeah
then
it
it
fails,
it
fails,
is
input
type
and
it
fails,
is
output
type.
If
it's
false,
then
like
technically,
the
type
itself
makes
sense,
but
you
can't
use
it
anywhere.
Yeah,
that's
a
good!
That's
actually
a
good
call
out,
as
we
start
to
think
about
the
like
schema
validation
rules
like
that
would
be
a
good
schema,
validation
rule
to
make
sure
to
cover.
C
Very
that
makes
makes
me
think
that
it's
really
unfortunate
that
we
don't
have
a
generic
object
type
that
has
the
same
also
allows
this
mixture
of
either
input
types
or
output
types
because
in
a
way,
attack
type
kind
of
like
an
object
type,
but.
B
F
B
Times
this
is
I,
I
think
this
has
come
up
a
handful
of
times
in
the
course
of
discussing
input,
unions
and
then,
ultimately,
this
tag
type
is
part
of
what
we're
doing
is
is
charting
out
the
rules
for
how
these
things
could
operate,
and
I
I
know
one
of
the
kind
of
unstated
goals
benji
has
is
retaining
the
option
value
for
such
a
type
in
the
future.
B
So
we
don't
want
to
make
a
design
decision
now
with
tag
types
that
would
restrict
the
ability
to
add
the
type
that
you're
you're
describing
benedict
in
the
future.
G
We're
sort
of
calling
that
type
structs
at
the
moment.
B
G
B
G
I
did
actually
evaluate
with
lee
specifically
the
idea
of
using
structs
for
this,
because
I
felt
like
it
could
be
a
good,
a
good
solution,
and
lee
very
rightly
shot
me
down
in
a
very
in
a
large
number
of
ways
pointing
out
all
of
the
various
employables
that
it
would
surface
so
yeah.
I
am
convinced
that
struct
is
not
the
right
solution
for
this,
but
I
still
think
it
is
a
valuable
thing
to
potentially
have
in
future,
partly
that.
G
To
be
honest,
the
main
the
main
thing
that
we
would
lose
with
strat
would
be
the
flexibility
of
evolving
your
schema
over
time.
If
you
want
the
idea
that
you
can
pull
down
a
struct,
do
something
to
it
and
send
it
back
to
the
server,
you
can
add
new
non-nullable
types
to
like
an
object,
a
non-nullable
field
to
an
object
type
and
that's
fine
to
evolve
the
schema
over
time.
G
But
if
you
were
to
do
that
with
a
struct
and
you
weren't
requesting
those
fields
when
you
pull
it
down
and
when
you
send
it
back
up
again,
it
wouldn't
have
those
required
fields
and
that
you
know
gives
you
quite
a
few
issues.
So
for
me,
that's
the
most
glaring
issue
with
trying
to
use
a
struct
as
a
universal
pull
it
down.
Send
it
back
up
thing.
E
Why
would
I
use
unions
anymore?
If
I
have
texts.
G
That
is
a
great
question,
and
so
I've
got
a
few
answers
to
that.
Unions
and
tags
solve
very
similar
problems
with
regard
to
output,
but
unions
still
have
some
advantages
over
tags,
in
particular,
fragment
spreads,
which
you
can't
do
in
the
same
way
with
text.
So,
for
example,
you
could
say
if
my
union
is
of
type
node
like
where
node
is
an
interface,
you
can
spread
over
it
and
request
all
of
the
fields
that
would
be
valid
on
node
like
id.
G
You
couldn't
do
that
with
a
tag
type,
because
you
can't
spread
that
interface
over
attack
type
you'd
need
to
request
each
of
the
individual
types
within
it,
and
then
the
fields
within
those.
So
there's
things
like
that,
where
it's
less
less
of
a
good
fit.
I
think
sorry,
but
I.
E
G
If
there's
an
overlap
between
the
union
and
the
interface,
you
can
do
a
fragment
spread
over
the
interface.
It
doesn't
have
to
be
a
full
overlap,
so
you
don't
have
to
have
all
of
the
types
within
node,
but
if
one
of
the
things
like
user
is
within
your
union,
if
you've
got
user,
impair
and
user
implements
node,
you
can
do
a
spread.
When
you
query
the
the
union
of
those
two
things
for
node,
and
then
it
says
if
it
is
a
node,
if
it
obeys
the
node
interface,
you
may
request
these
fields.
E
Okay,
yeah,
I'm
just
going
through
my
head.
G
Also,
the
unions
are
shallower,
like
the
tag
type
adds
a
level
of
indirection,
so
some
people
will
prefer
the
the
shallower
approach,
but
broadly
they
are
similar,
and
I
think
that
is
potentially
one
of
the
issues
that
this
introduces.
But
I
don't
think
it's
a
good
enough
reason
not
to
add
it.
In
my
opinion,.
E
G
Only
to
that
tag
type,
so
it
may
become
an
anti-pattern
to
use
the
exact
same
tag
for
both
input
and
output,
and
it
might
be
better
that
your
arguments
accept
the
input
type
and
that
your
return
types
accept
a
separate
but
identical
output,
type
that
I'm
not
sure
what
that
will
turn
into,
and
it
it's
really
again
up
to
schema
designers
to
to
define
that
and
to
see
what
makes
sense
for
them.
But
it
is
an
interesting
thing
where
the
schema
evolvability
may
be
penalized.
H
P
Oh,
I
mean
that
was
just
an
idea
when
you
were
discussing
struct,
I'm
pretty
sure.
I
don't
know
if
this
really
solves
the
problem.
It's
just
the
idea
is
that
what?
If?
What?
If
input,
types
and
object
types
could
share
interfaces
that
would
kind
of
solve
the
problem.
G
So
I
think
the
issue
there
is
that
interfaces
use
the
output
type
definition
of
of
fields,
whereas
input
types,
obviously
don't
support
like
arguments
and
things
like
that
and
also
their
nullability
concerns.
Input
versus
output
are
kind
of
opposites.
So
I
think
that.
B
Subsetting
operator
right,
like
you
interface,
says
this
type
supports
at
least
these
things
and
may
support
more,
which,
from
an
output
type
makes
sense.
It
means
like
it
is
safe
to
query
at
least
these
things
and
it
might
be
safe,
but
we're
not
sure
to
create
more
than
that,
but
from
an
input
point
of
view
that
that
doesn't
give
you
much
right,
because
what
you
really
want
to
do
is
invalidate
the
stuff.
That's
not
legal!
D
So
I
I
think
I
like
I
like
this
in
general.
Quite
a
lot.
I
think
the
space
where
I'm
have
concerns
is
like
the
challenge
of
determining
if
it's
valid
for
input
or
output
and
where
those
can
evolve
a
type-
and
it
makes
me
wonder-
like
I'm
not
sure
about
this,
but
like
should
we
consider
splitting
them
so
that
they're
distinct
types
for
both
input
and
output,
just
to
make
it
a
little
more
clear
and
remove
some
of
the
risk
around
them.
D
B
Does
that
close
off
any
option
value
in
the
future,
or
I
think
it
might
especially
with
this
like?
I
don't
I
don't
know
whether
or
not
we
ever
will
go
down
the
road
for
strucks,
but
I
think
it
would
make
that
more
complex
and
you'd
end
up
needing
to
like
fully
duplicate
your
your
type.
If
you
wanted
to
use
it
in
more
than
one
place,
you'd
have
to
have
an
input
and
output
variant
which,
by
all
accounts,
all
the
details
of
them
would
be
equivalent
except
the
name.
B
That
might
be
frustration
point
so
yeah.
G
What
we
could
potentially
do,
that
would
be
a
solution
to
that
and-
and
that
is
actually
one
of
the
open
questions
that's
listed.
What
we
could
do
instead
is
just
say
that
you
once
you've
used
a
tag
type
in
an
input
position.
You
may
know
you
may
not
use
it
in
an
output
position
and
just
do
it
as
a
schema
validation
rule
which
we
could
always
then
just
delete
later.
If
we
need
to,
but
I
think
using
separate
types
would
add,
more
complexity.
C
I
think
I
think
that
using
a
signal
type
is
very
useful
for
some
cases,
for
instance,
a
case
where
you
would
basically
use
the
tag
type
to
have
a
polymorphic
scalar,
and
in
that
case
it's.
I
think
it
would
be
really
common
to
just
pass
back
the
same
type
as
input
and
output
and
also
in
terms
of
schema
evolution.
There's
little
risk
in
like
adding
a
non
like
a
specific
type
as
specific
for
input
or
output.
To
that.
B
G
I.E
think
that
the
rfc
is
in
a
good
position.
Actually,
I
I'm
not
aware
of
any
issues
in
it.
There
are
things
that
are
debatable
in
it,
but
I
think
it
like
it
could
be
merged,
as
is,
and
it
would
be
valid,
I'm
not
aware
of
anything
that
would
prevent
that
from
happening.
So
I'm
certainly
keen
to
to
gather
more
opinions
on
various
of
the
open
questions,
and
I
would
love
to
have
more
reviews
on
it.
G
Spotting
my
office
mistakes
most
likely
because
it's
a
lot
of
text
when
I,
when
I
opened
the
the
one-off,
the
one
field
rfc
before
that
was
like
it
was
like
three
lines
of
editing
the
spec,
this
one's
more
like
duplicating
huge
chunks
of
it
and
updating
it.
I
one
particular
thing
where
the
wording
in
the
spec
is
more
complicated
is
where
we
effectively
sharing
the
same
algorithms
for
tagged
and
object
or
tagged
and
input
type.
G
So
in
some
places
in
the
spec,
I've
effectively
said
for
the
purposes
of
this
section,
a
tagged
member
is
called
a
field
because
then
we
can
just
use
the
word
field
everywhere,
and
I
think
we
already
do
that
for
input
fields,
though
they
should
technically
be
called
input
fields.
We
just
call
them
fields
and
that's
fine,
but
for
tagged.
G
M
E
Was
the
reason
to
extend
it
actually
to
the
output
types
like
I,
I
saw
a
lot
of
discussions
about
the
emission
problems
around
input
unions
and
I
think
they
were
reasonable
and
there
were
a
lot
of
effort.
I'm
failing
to
see
like
what
new
things
offers
me
to
model
this
for
the
output
types
which
I
could
not
do
before.
Yes,
there
would
be
like
an
indirection
and
but
like
I,
I'm
I'm
failing
to
see
on
on
sorry
on
a
very
quick
look.
G
Yeah,
that's.
That
is
absolutely
an
excellent
question
and
something
that
we've
discussed
quite
a
bit.
Broadly,
it
comes
down
to
a
few
things.
One
is
tag.
Types
are
like
easier
for
beginners
to
actually
query
like
they
don't
need
to
worry
about
fragment
spreads.
They
can
just
type
the
names
of
the
fields
and
have
it
all
auto
complete
in
a
very
easy
way,
but
that's
kind
of
by
the
by
that's,
not
the
important
one.
The
important
one
is
the
symmetry,
the
symmetry
between
input
and
output
types.
G
So
you
could,
with
a
tag
to
represent
something
that
is
symmetric.
You
can
pull
it
down
from
the
output
of
your
schema,
manipulate
it
and
send
it
straight
back
up
again
in
its
same
form,
and
we
have
like
almost
that
with
with
input
and
object
types,
but
obviously
those
don't
support
polymorphism.
G
No,
that's
that's
not
true.
It
is
true
in
that
you
wouldn't
be
able
to
use
the
same
type
for
them,
but
you
could
make
two
different
types:
an
output
type
and
an
input
type
that
have
the
exact
same
shape
and
those
would
be
those
would
be
valid.
So
you
would
have
an
input
type
that
accepted
cat
input
and
dog
input
under
the
names,
cat
and
dog
and
you'd
have
an
output
type
that
output,
a
cat
and
a
dog
under
the
names,
cat
and
dog.
G
So
those
could
be
used,
like
the
actual
underlying
type
name,
doesn't
matter
right,
it's
just
the
fields.
Let's
see
what
you're
saying
cool.
C
G
Yeah,
another
sorry
yeah
another
one
is
yeah,
as
you
say,
the
scalars,
which
is
very,
very
much
been
requested
on
various
other
things,
and
I
think
that
is
quite
useful
and
a
lot
of
the
things
that
we've
discussed
with
regard
to
adding
scalars
to
unions,
for
example,
has
said:
well,
we
can't
tell
the
difference
between
an
internal
flow
necessarily
by
just
sniffing
the
data.
G
So
if
you
were
to
combine
a
union,
if
you
were
to
add
a
scalar
to
a
union,
you'd
only
be
able
to
add
one,
whereas
with
tag
types,
you
can
add
any
number.
Also,
you
can
add
lists
to
a
union,
so
you
could
have
one
of
the
options
would
be,
it
could
be
a
list
of
animals
or
it
could
be
an
animal
or
it
could
be
an
integer
and
all
of
those
things
could
be
in
the
same
union,
which
is
not
possible
with
output
unions.
A
I
want
to
know
a
alternative
option.
Benjamin
actually
discussed
it
like
two
months
ago
and
I
didn't
proceed
to
to
create
anything.
I
did
a
small
research.
Basically
idea
is
to
adopt
one
off
from
protobuf
instead
of
creating
a
new
type.
So
it's
in
the
middle
between
original
idea
of
derivative
and
your
current
proposal
of
creating
separate,
separate
entity
and
type
system.
A
So
like
one
of
just
groups
of
fields-
and
I
did
research
and
as
far
as
I
can
tell,
there
is
some
issue
with
one
offense,
but
they
are
all
related
to
serialization
format.
For
example,
you
cannot
use
one
of
four
repeatable
inside
repeatable
objects
and
stuff,
but
it's
caused
by
wire
format.
It's
not
caused
by
a
design
issue
with
one
of
itself,
so
I
actually
think
it's
like
middle
ground
and
it's
allowed
us
to
remove
like
a
set
of
problems
with
like
type
names
and
other
things.
A
Review:
it's
not
like
small
differences
like
different
approach.
So
a
question
is
how
should
I
start
conversation
about
it?
I
was
thinking
about
creating
an
issue
and
having
like
a
table
of
what
a
separate
type
can
do
and
like
features
and
basically
saying
like
what
is
of
these
two
proposals
can
do
so
like
comparation
compression.
G
Wise
we,
we
already
have
a
framework
for
comparing
these
solutions
in
the
form
of
the
input
union's
rfc,
so
I
think
the
best
direction
to
go
for
that
would
be
to
add
it
as
solution
7
to
the
input
unions,
rc,
we
do
have
a
solution,
six
which
I
don't
think
is
actually
in
that
document.
So
I
would
encourage
you
to
use
the
number
seven
because
we
already
discussed
number
six,
even
though
it's
not
written
down
yet,
which
is
partly
on
me,
so
yeah
submit
it.
There
answer
the
existing
questions.
G
We've
got
all
the
evaluation
criteria
and
then
I
think
it
would
be
good
to
discuss
that
as
part
of
the
input
union's
rfc
working
group.
We
can
certainly
arrange
one
of
those
once
you've
done
that
and
see
whether
that
works
out
to
be
a
better
solution
and
another
issue.
A
If
another
way
ask
for
help,
if
somebody
have
experience
with
one
of
them
because,
like
my
knowledge
is
purely
theoretical,
it
would
be
interesting
if
somebody
actually
used
one
open
protobuf
and
have
like
a
real
experience
about
that.
We
can
work
together
on
this
proposal
to
incorporate
like
good
parts,
and
I
mean
bad
boys.
D
So
I'm
not
clear
what
the
idea
would
be,
how
would
you
be
specifying.
A
The
same
way
so
one
off,
basically,
you
create
a
group
of
fields
inside
the
type.
So
when
you
specify
type
inside
curly
braces,
you
create
you
write
one
off
and
set
of
curly
braces
and
couple
like
certain
number
of
fields,
fields
inside
so
basic
mechanism.
So,
like
my
point,
is
that
basic
mechanism
is
the
same
as
benji
initially
suggested,
starting
from
directive.
A
So
most
of
the
things
are
pretty
similar,
the
big
difference,
even
like
ability
to
use
and
put
in
output
types.
The
big
difference
is
that
we
create
separate
entity
and
type
system
or
we
just
add,
constrain
to
two
types
so
pratt
above
decided.
A
So
what
we're
basically
doing
right
now,
even
though
we
the
calling
it
tagged
union,
it's
like
a
new
concept
from
from
like
rust
and
swift
and
other
modern
languages
so
like
they
decided
to
create
separate
types
word
in
protobuf.
They
have
like
object,
type
and
inside
object
type.
You
can
group
a
field
under
one
of
so
mechanism
is
the
same.
So
wait.
A
You
don't
get
a
few
names
for
stuff
that
can
doesn't
return
so
like
from
query
perspective
is
the
same.
There
is
like
no
difference
from
query
perspective.
It's
a
difference
in
like
type
system
and
introspection
and
like
type
name,
for
example,
case.
So
if
it's
just
a
group
inside
the
type
we
just
return
name
of
the
type.
A
C
B
Yeah
well,
it
makes
me
I'm
a
little
hesitant
in
the
past.
We've
we've
been
careful
to
avoid
that
kind
of
generic
type
or
parameterized
type,
because
it
becomes
pretty
challenging
to
represent
an
introspection,
but
I
think
like
at
this
point.
We
should
continue
to
explore
alternatives.
We
we
should
have
high
confidence
that
the
one
we
propose
is
the
right
one.
So
we
should
keep
doing
that
in
parallel.
I
think
that's
the
right
thing
to
do.
E
I
just
want
to
say
overall,
it's
really
great
to
see
like
an
outcome.
After
all
these
years
of
of
discussion
and
work
and
and
yeah,
I
will
definitely
try
to
take
some
time
and
give
it
a
slow
review
and
hopefully
provide
more
feedback.
B
Yep
I
plan
to
do
the
same.
Okay
with
that.
Let's,
let's
wrap
the
meeting.
I
know
we
only
have
about
10
minutes
left
until
the
end
of
the
hour,
so
I
want
to
make
sure
everybody
has
a
chance
to
stretch
before
the
rest
of
your
day
or
evening,
but
thanks
so
much
for
walking
us
through
this
benji.
This
is
a
huge
advancement
and
you've
done
an
awesome
job.
Getting
this
rfc
put
together
in
the
spec.
B
I
feel
like
the
next
steps
here
are
both
collecting
additional
inline
feedback,
making
sure
that
you're
dialing
in
the
the
spec
text
and
answering
some
of
these
open
questions
and
then
probably
starting
to
to
implement
an
experimental
version
of
this
to
make
sure
that
we're
we
can
actually
support
this
from
the
parsing
and
an
execution
side.
G
B
You
very
much
everyone
all
right,
everybody.
That
concludes
our
meeting
thanks
so
much
we
covered
a
ton
of
ground
today.
I
always
appreciate
it
and
always
a
pleasure
to
get
to
hang
out
with
all
of
you,
lovely
group.
B
Raise
it
every
six
months,
I
have
the
same
question
they
they
they
float
around
in
the
the
bowels
of
zoom
for
a
couple
weeks
and
then
output
as
raw
files
somewhere
worst
comes
to
worst
I'll,
find
a
way
to
get
just
like
raw
video
files
hosted
in
like
a
file
service.
B
The
dream
is
to
get
them
on
youtube,
but
that's
proven.
A
Yeah
yeah,
like
you,
know,
foundation,
guys
figure
out
how
to
publish
it
even
for
graphql
http,
it's
also
already
on
youtube.
So,
basically,
all
our
archive
of
zoom
videos
is
on
youtube.
B
Let's,
actually
a
good
operational
thing
we
should
do
is
once
they
inevitably
find
their
way
to
youtube,
which
I
know
takes
a
little
bit
of
time.
B
We
should
go
back
to
the
agendas
that
they're
relevant
for
and
post
a
link,
so
we
just
edit
them
and
then
the
same
way
that
it
says
you
know
here's
the
meeting,
here's
the
live
notes.
We
just
add
one
more
thing:
it's
like
youtube,
recording.