►
From YouTube: GraphQL Working Group - July 1, 2021
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
A
Hi
lee
I
I
almost
thought
that
I
might
have
made
a
mistake
with
the
time
zone
because,
usually
you
are
always
there.
C
I
just
set
it
up
this
morning.
You
know,
we've
been
talking
about
potentially
doing
this
for
a
long
time
and
I
keep
hearing
good
things,
so
I'm
just
gonna
try
it.
A
C
Though
I'm
I'm
with
you,
that's
that
was
my
biggest
hold
out,
but
I
gotta
say
after
spending
I'm
in
a
couple
different
open
source,
slack
groups-
and
I
found
the
use
of
threads-
is
like
way
lighter
weight
than
in
like
a
work.
Slack
group,
where
there's
just
a
lot
more
activity
happening
in
real
time.
C
Yeah
there's
like
a
threshold
where,
if
you're,
if
your
like
number
of
messages
per
hour
or
whatever
is
lower
than
this
line,
then
it's
like
more
confusing
than
helpful
to
have
threads
but
yeah
yeah,
I'm
kind
of
with
you.
A
And
the
the
the
thing
is,
I
I
looked
at
some
of
the
microsoft's
lectures
that
they
have
now
for
their
open
source
projects,
and
sometimes
you
cannot
follow
the
discussion
because
they
are
happening
two
or
three
discussions
at
once.
Yeah
you
can.
You
cannot
also,
but
they
are
working
on
that,
so
it
might
be
solved
in
a
couple
of.
C
A
C
I'm
merging
attendance
prs
as
I
see
them.
E
And
can
we
have
the
live
notes
as
well?
Please
lee.
A
A
A
C
I
also
love
how
every
time
I
make
these
notes.
It
says
google
doc,
where
the
link
is
shared
with
anyone
on
the
internet
and
anyone
who
has
access
has
edit
access.
They
really
don't
want
you
to
do
that.
I
have
to
go
through
so
many
like
buttons
like.
Are
you
sure
everyone
can
edit
this
document
yeah?
I
know.
C
All
right-
and
that
brings
us
to
1105-
which
is
a
great
time
to
start
thanks,
everybody
good
to
see
you
again.
It's
been
a
month
hope
everyone's
doing
all
right
in
your
corners
of
the
world.
C
Let's
kick
things
off
as
per
usual.
By
joining,
we
all
agree
to
the
spec
membership
agreement,
participation,
guidelines
and
code
conduct
links
there
in
the
agenda.
If
you
ever
want
to
refresh
yourself
on
what
those
mean
next
we're
going
to
do
a
quick,
round-the-room
intro
of
attendees,
we
will
use
the
order
as
it's
listed
in
the
doc,
and
if
you
missed
anyone,
that's
okay,
we'll
just
read
them
out
and
we'll
add
folks.
C
If
you
are
not
on
the
list
already
just
send
up
a
request
that
way.
We've
got
a
record
of
who's
in
which
meeting
I'm
on
the
top
of
the
list.
So
hello,
everybody,
my
name
is
lee.
E
Him,
hey
everyone,
I'm
benji.
I
work
on
the
graphile
suite
and
I've
got
a
few
graphql
spec
things
in
the
works
at
the
moment.
B
I'm
from
ibm
research
I
work
on
some
open
source.
A
Projects,
I'm
michael
stark,
I'm
with
chili
cream
and
I'm
working
on
the
hot
chocolate
implement
hot
chocolate,
grappler
implementation.net.
F
Oh,
hey
everyone.
I'm
robert
from
aws.
C
Toss
your
name
on
the
agenda,
my
man,
okay,
let's
I
think
we've
got
action
happening
in
the
notes,
benji
as
per
usual,
taking
the
lead,
but
always
a
good
reminder
to
please
jump
in
and
help
out
with
that,
especially
since
a
couple
of
these
things
on
the
list
are
benji's,
so
I'm
sure
he'll
appreciate
some
additional
help.
C
Let's
take
a
quick
look
over
the
agenda.
Make
sure
everything
here
is
what
we
want
to
talk
about:
we're
going
to
talk
about
the
previous
action
items,
I'm
bringing
full
unicode
back
on
the
agenda.
Hopefully
this
is
a
very
boring
but
exciting
update,
we'll
talk
about
defer
and
stream
out
of
order.
Payloads
talk
a
little
bit
about
slack
and
discord.
That'll
be
fun,
argument,
uniqueness
and
that's
it
relatively
short
list.
So
today's
meeting
might
be
on
the
shorter
side
right
can.
I
I
add
something:
quick
yeah
should,
I
just
add
it
to
the
agenda.
Sure,
oh
a
pr,
but
talk
about
it
great.
I
just
wanted
to
talk
about
the
state
of
graphql
subscription.
C
C
C
It
looks
like
we
only
have
two
ready
for
review
require
argument:
uniqueness.
That's
on
the
agenda
benji.
I
assume
you
marcus
is
ready
to
review.
C
Yeah
yeah,
then
brian
and
I
are
working
on
this
last
step
this
actually,
the
other
one
is
related
to
the
cut
of
the
spec,
which,
from
my
point
of
view,
is
ready
to
go.
We
have
to
take
the
formal
vote
from
the
tsc
still
which
brian's
gonna
help
us
with,
and
then
I'm
gonna
do
a
little
bit
of
extra
help
to
for
the
marketing.
So
that's
there's
a
reminder
to
myself.
C
Is
it
safe
to
close
this
argument?
Uniqueness,
one
benji,
since
it's
on
the
agenda.
C
Just
one!
Action
item
closed,
that's,
okay,
a
lot
better!
We've
had
better
months.
We
have
16
other
action
items
open
it
might
take.
I
know
I
said
this
last
time,
but
I
mean
this
time
I'll,
take
a
bit
of
time
after
the
meeting
and
come
through.
Some
of
these
I
think,
there's
a
handful
that
should
be
pretty
easy
to
close
out.
C
E
I
think
this
is
still
ongoing.
I
know
that
the
the
graphql
ruby
folks
were
having
some
troubles
with
it.
E
Okay,
but
I
don't
know,
I
don't
think
like
we
haven't,
had
reports
back
from
all
of
the
different
implementations
as
far
as
I
know,
but
I
it
does
seem
like
this
might
be
one
that's
a
bit
tricky
because,
as
you
as
you
know,
it's
tricky
in
graphql,
js,
right
and
a
lot
of
them
are
based
on
graphql
js,
and
I
think
that's
going
to
make
things
interesting
to
everyone.
C
Correct
I'll,
just
nudge
that
one
a
bit,
let
me
see
if
I
can't
find
the
the
last
in
that
stack.
C
Because
I
would
love
to
make
sure
that
we
can
move
that
that
stack
of
changes
along
and
it's
a
doozy,
that's
for
sure,
but
I
want
to
make
sure
that
it's
not
just
you
know
sitting
there
give
me
one
sec
to
find
that
perfect.
I
found.
C
C
Okay,
nudged
all
right
anything
else.
We
need
to
talk
about
on
any
of
these
other
open
action
items.
E
Yeah,
maybe
rob
can
comment
on
the
deferring
stream
one
as
well
number.
E
G
Yeah
the
the
spec
vr
has
been
open
for
for
a
while.
I've
been
getting
small
comments
here
and
there
for
past
a
couple
months
been
trying
to
address
them.
G
Yeah,
I
guess
I'm
not
really
sure
what's
next
for
this,
I
know
for
the
the
js
side
of
it.
I'm
waiting
for
the
16
version
to
be
cut
before
the
code
changes
could
start
getting
merged
into
the
js
repo.
C
Yeah,
okay,
I'm
going
to
close
this
one
since
it's
been
open
for
quite
a
number
of
months
and
it
does
seem
like
in
fact,
there
have
been
pretty
steady
review
on
that
since
there's
been
like
a
steady
stream
of
improvements
and
if
we
want
to
trigger
another
review,
then
we'll
just
open
another.
One
of
these.
C
Great
too
close,
okay,
better
than
mine,
all
right.
C
That's
exciting
two
two
and
a
project
down,
so
there
you
go
this
okay.
Are
we
good
to
move
on?
Okay,
take
silence's
approval
there.
Next
on
this
list
is
from
me
it
is
the
full
unicode
change
and
this
one
I
had
in
can't
remember
who
was
last
month
or
the
month
before
that
to
move
it
to
final
draft
and
it's
basically
sat
unchanged.
I
I
don't
believe
there
are
any
other
open
questions
and
the
pull
request
has
had
some
fine
tuning.
C
Actually,
I
think
right
before
last
month's
meeting
that
was
just
around
adding
additional
test
cases,
so
I
I'm
feeling
highly
confident
in
this
change,
so
I
want
to
put
it
up
for
final
approval,
and
I
don't,
I
think
we
should
probably
have
enough
people
here
to
make
good
on
that
anyone
not
hold
confidence.
Anyone
want
to
keep
holding
this
one
from
approval
or
any
just
open
discussion
on
this.
C
C
I
assume
people
are
reading,
so
just
feel
free
to
speak
up
once
you're
read
through.
C
I
know
this
one's
kind
of
like
in
the
weeds,
so
it's
like
not
like
it's
unlocking
something
massive.
Actually
I
shouldn't
say
that
it
unlocks
being
able
to
write
emojis
directly
in
graphql
text,
what's
more
fun
than
that.
E
We
all
want
to
achieve
that
goal.
We
we
all
want
to
put
emojis
in
our
graphql.
I
just
think
many
of
us
don't
feel
that
we've
maybe
necessarily
got
the
knowledge
required
to
comment
on
this
either
way.
No,
that's
a.
C
C
And
that's
that's
certainly.
I
think
why
this
is
getting
solved
now.
Instead
of
I
think
the
original
issue
on
this
was
opened
in
2016.,
and
the
biggest
thing
that
has
changed
is
the
accrual
of
knowledge,
where
I've
talked
to
people
from
the
unicode
consortium
and
be
like,
if
you
were
going
to
design
a
language
from
scratch
that
had
full
unicode
support
like
what
would
you
do
and
that's
essentially
where
this
has
led
us
as
well
as
looking
at
this
small
handful
of
languages
that
actually
have
come
out
relatively
recently.
C
So
if
you
look
at
the
spec
for
rust
or
the
spec
for
swift
or
kotlin,
all
relatively
new
languages
all
follow
this
pattern
where
they
they
use
the
concept
of
a
unicode
scalar
value,
which
is
the
right
way
to
do
that.
They
rise
as
opposed
to
like
manually,
defining
which
specific
code
points
are
not
allowed.
You
just
like
offload
that
responsibility
to
the
unicode
definition,
and
then
the
other
is
like.
C
How
do
you
do
escape
sequences
for
for
unicode
values
that
are
higher
than
fff
higher
than
four
digits
of
hex
code
java
had
one
where
they
could
do
like
four
digits
or
eight
digits,
and
that
unicode
folks
look
at
that
and
say
like?
No?
No,
no
don't
do
that.
You
want
something.
That's
variable
width
and
so
javascript
has
the
syntax.
Now,
with
the
curly
braces,
swift
has
the
syntax.
Now
I
think
python
has
adopted
the
syntax.
C
K
If
what
you're
looking
for
is
like
a
good,
solid
review,
would
it
make
more
sense
to
not
have
a
graphql
expert
stamp
this
and
instead
have
a
unicode
expert
stamp
this,
because
I
could
probably
I
can
like
scrounge
around
people.
We
both
probably
know
that
are
likely
unicode
experts
and
because
I
would
feel
like
if
you
and
somebody
who
we
kind
of
agree
yeah,
they
really
know
unicode
and
like
have
done
it
somewhere
else.
K
C
Yes,
we
did
this,
there's
there's
a
comment
on
this
rfc,
it's
in
like
the
middle
of
it,
so
you
gotta
experience
the
comments,
because
there's
been
a
lot
from
ben
hamilton
who
is
in
fact
a
unicode
expert.
Oh
then,
then,.
G
I
say
and
implemented
unicode.
K
L
There
you
go
so
one
question
that
might
already
be
answered
would
be:
are
there
any
cases
where
existing
schemas
would
be
broken
by
this,
like
with
a
parser
update
and
or
do
we
know
the
answer
to
that
great
question?.
C
No
and
carefully,
no,
because
actually
one
of
the
reasons
why
I
think
there's
light
urgency
to
complete
this
is
a
lot
of
implementations
accidentally
support
full
unicode,
because
their
parsers
do
not
follow
the
spec
perfectly
and
instead
what
they
do
and
including
graphql
js,
which
is
the
reference
symbolization
and
does
not
formally.
You
know
not
allow
these
and
part
of
why
it
accidentally
does.
C
That
is
because
java,
a
couple
other
languages
internally
represent
strings
as
16-bit
like
a
sequence
of
16-bit
characters,
and
so,
if
you
send
surrogate
pairs
in,
then
you
get
the
like
appropriately
encoded
value
back
out,
even
though
graphql
spec
itself
says
nothing
about
that.
So
there's!
Actually
that's!
There
are
two,
I
would
say
one
minorly
contribution,
virtual
and
one
moderately
controversial
thing
in
this
change.
C
The
minorly
controversial
one
is
that
we're
moving
from
explicitly
banning
control
characters
in
graphical
text
to
not
doing
that,
and
I
would
say,
that's
only
minorly
controversial
because
I
think
initially
it
was
a
reasonable
idea,
but
it's
a
fish
swimming
upstream.
Every
other
language
does
not
do
this,
and
so
it
actually
creates
more
confusion
than
it
helps.
There
have
been
a
handful
of
bugs
that
are
like
people
file.
Why
they're
they're
confused
as
to
why
they're
getting
a
syntax
error,
because
they're,
like
you
know,
wrote
something
javascript
generated
the
moderately.
C
The
moderately
controversial
thing
is
we're
allowing
json
style
encoded
surrogate
pairs,
which
that's
the
one
thing
our
unicode
expert
ben
hamilton
said,
would
be
not
advisable,
but
if
we
didn't
do
that,
it
would
be
a
breaking
change
because
of
that
accidental
unicode
support,
so
people
are
already
encoding
emojis
into
their
and
other
high
playing
characters
into
their
graphql
text
with
double
encoded
surrogate
pairs
because
they
found
that
just
works.
Graphql
js
supports
it.
Graphical
java
supports
it
both
accidentally,
so
we're
making
that
just
a
formal
part
of
the
spec
and
there's.
C
If
you
read
the
spectex
closely,
it
says
you
know.
Please
don't
do
this.
Please
use
this
newly
introduced
variable
with
encoder,
but
if
you
have
existing
text
that
does
that
it
won't
break.
So
that's
that's
actually
a
very
good
question
and
something
that
I
was
pretty
careful
to
make
sure
that
nothing
would
break.
E
Just
one
other
comment
on
it:
you
have
a
pending
question
to
andy,
who
I
don't
think
is
on
the
line
at
the
moment
it
might
be
worth.
I
did
catch
up
with
him
offline
I'll
show
you.
C
C
Yeah
there
andy-
and
I
had
so
andy-
deserves
a
fair
amount
of
credit
here,
he's
the
one
who
really
pushed
this
for
a
while
until
I
joined
in
with
him.
C
This
surrogate
pairs
are
always
kind
of
a
mind
squeeze
to
talk
about,
and
especially
when
you're
talking
about
the
difference
between
the
spec
text
and
an
implementation
where
that
implementation
has
quirks
around
how
unicode
works
itself.
That
includes
java
and
javascript,
and
so
we
wanted
to
make
sure
we
had
some
note
that
explained
exactly
what
what
you
should
be
careful
with
with
an
implementation,
and
so
this
final
form
andy-
and
I
are
both
happy
with.
C
All
right
any
other
questions
or
concerns.
It's
been
a
long
road
for
this
one.
I
should
dig
up
the
og
issue
that
asks
for
full
unicode
support.
I
will
move
this
to
approved.
I
will
not
merge
it
yet,
because
I
want
to
make
sure
that
we
get
this
spec
cut
done
first
and
then
so
I
have
sort
of
like
a
lightweight
freeze
on
the
spec
repo
until
we
get
that
done
and
I'll
merge
anything
that
and
anything
else
that
happens
approved
after
that.
C
G
I
actually
talked
with
him
yesterday
at
the
graphql
js
meeting
about
this,
so
I
could
recap.
His
question
was
in
the
implementation
in
this
in
the
reference
implementation,
pr,
it's
possible
to
receive
stream
payloads
out
of
order.
That
could
happen
either
if
you
are
resolving
an
array
of
promises
and
a
later
promise
resolved
before
an
earlier
one
or
with
an
async,
iterable
and
fields
below
the
async
interval
take
longer
to
resolve.
G
If
a
later
one
takes
longer
than
an
earlier
one.
Does
I
I
the
basis
I
was
going
off
of
is
that
we
wouldn't
hold
up
anything
to
make
sure
things
get
returned
in
a
specific
order.
G
I
it's
not
exactly
explicitly
called
out
in
the
spec,
so
I
will
do
that.
But
if,
if
there
are
up,
if
there
is
an
opposition
to,
if
there's
like
a
good
reason,
why
it
should
it
should
do
that,
it's
certainly
possible.
C
There
is
that's
a
really
interesting
point.
There
does
seem
to
be
a
category
of
things
which
are
not
dependent
on
one
another
and
we
should,
in
the
spec,
explicitly
allow
for
out
of
order
payloads
and
a
category
of
things
which
do
depend
on
one
another,
and
my
assumption
was
that
there
would
be
some
sort
of
order
requirement
to
the
payloads
for
those
like.
If
you
had
nested
defers,
does
the
most
nested
defer?
C
Could
that
payload
come
back
before
the
defer
above
it,
and
if
it
does
like
what
is
a
client
supposed
to
do
with
that?
Does
it
just
have
to
hold
on
to
it
until
the
intermediate
one
is
resolved?.
K
This
might
be
a
good
like
edge
case.
I
I
am
not
aware
exactly
of
how
we've
solved
it
at
facebook,
but
either
coe
or
joe
savona
from
relay
might
know
and
like
their.
It
feels
like
out
of
order
stream.
C
There
there
is
an
important
semantic
thing
like
the
idea
of
an
outer
like
we
should
not
allow
out
of
order.
Payloads
right
like
either
payloads
have
an
order
and
therefore
they
should
come
back
in
that
order,
or
they
don't
have
an
order,
and
we
should
make
it
very
clear
in
the
spec
that
they
don't
have
an
order
just
because
like
if
someone
is
seeing
the
stream
of
payloads
appear
and
says:
oh
wow,
that's
that's
out
of
order,
then
that
would
imply
that
there's
like
a
bug
or
a
bad
behavior.
C
Or
I
guess
another
way
to
say
that
is
our
spec
should
be
clear
about
where
there's
order
dependencies
and
where
there's
not,
so
that
we,
we
know
how
to
interpret
a
payload
ordering
as
valid
or
invalid
and
therefore,
like
clients
know
what
scenarios
they
need
to
be
able
to
handle.
A
Does
it
provide
any
benefit
to
the
client
to
have
an
out
of
order
content?
I
mean
it
makes
it
more
complex
to
the
client
for
for
the
server
I
mean
if
the
server
server
supports
it.
It's
easy
just
send
it
down,
but
I
think
it
introduces
complexity
to
the
client
and
therefore
it
should
have
a
benefit
also.
K
A
C
C
A
A
C
G
Yeah,
there's
definitely
a
couple
different
scenarios.
There's
I
think
what
yakov
was
originally
talking
about
was
what
matt
said
with
stream
payload,
specifically
the
ordered
list,
not
coming
back
in
the
same
index
order.
There
is
also
this
case
that
we
posted
where
it's
a
child
field
on
apparent
object.
C
I
don't
know
if
it's
necessarily
about
the
order
that
they
are
parsed.
I
I
this
is
my
just
personal
assumption.
A
personal
assumption
is
that
if
you
have
a
handful
of
fields
and
their
only
relationship
is
their
parse
order
and
they
are
all
deferred
in
some
way
that
those
do
not
have
a
dependency
on
one
another
and
should
be
able
to
be
delivered
in
arbitrary
order.
C
But
if
you
have
something
that
is
a
nested
that
is
nested
under
another
defer,
my
assumption
would
be
that
that
thing
would
not
even
start
to
execute,
or
certainly
I
don't
stop
to
serve
to
decide
when
it
starts
to
execute,
but
it
wouldn't
be
delivered
to
a
client.
Some
of
this
is,
I
think,
about
expressivity.
Like
can
you
if
you
and
this
guy
think
it's
back
to
what
michael
is
saying
like
what
is
the
benefit
to
a
client?
C
But
if
it
doesn't,
then
it
could
potentially
interpret
it
as
a
bug.
So
the
reason
why
I
say
express
ability
is:
is
there?
Can
you
represent
that
in
a
different
way
say
we
had
a
restriction.
That
said
a
nested
deferrer
cannot
be
like
there's
an
there's,
a
dependency
ordering
where
the
there
is
an
order
in
which
these
must
come
back.
C
And
if
you
wanted
to
get
that
nested
field,
could
you
and
I
I'm
pretty
sure
the
answer
is
yes,
you
just
have
to
write.
You
have
to
use
like
two
parallel
fragments,
one
that
deep
drills
to
get
the
field
that
you
want
and
then
another
that
gets
the
other
things
that
you
want
and
then
those
should
that
should
like
break
the
dependency
between
the
two.
K
Yeah
all
right,
I
do
think
like
from
a
client
perspective,
maybe
not
relay,
but
at
least
my
client
I'm
fairly
certain
would
break
or
like
would
just
give
you
back
null
if
you
gave
us
a
path
of
to
some
inner
stuff
that
had
not
previous,
like
if
part
of
that
path
had
not
previously
been
sent
right.
So
if
we're
like
user
dot
best
friend
dot
other
best
friend
like
if
I
have
gotten
a
user,
but
I
haven't
yet
gotten
user.best
friend
like
I,
I
think
a
common
thing
to
do.
K
A
But
essentially
that's
what
I
mean.
If
you
have
a
normalized
store,
then
you
have
not
something
you
can
patch
it
onto.
You
cannot
create
the
relations
or
it
might
be
very
complex,
and
thus
you
you
essentially
then
go
back
to
buffering
this
thing.
So
you
get
it
early,
but
you
cannot
do
anything
with
it.
That's
what
I
meant
with
and
the
client
suddenly
has
no
benefit
of
having
the
data
early.
C
So
my
I
think
the
nested
case
is
fairly
clear
here,
that
it
would
be
far
more
beneficial
to
just
structure
a
query
in
a
different
way
if
your
intent
was
to
not
have
that
dependency,
the
one
that
I
think
is
more
interesting,
maybe
the
one
that
originally
cued
the
conversation
rob
is
about
like
a
stream
on
a
list,
can
you
get
indices
of
that
list
out
of
order
or
you
have
to
get
the
first
in
the
c
before
the
second
into
c
or
the
third
indices.
G
G
In
that
case,
you
do
have
like
the
field.
The
path
does
exist
for
you
to
insert
the
item
into
it's.
If
I
guess
the
client
needs
to
handle
like
a
sparse
list.
For
that
I
don't
know
it's.
It
seems
like
it's
like
the
case
where
you
have
like
an
array
of
promises
and
each
one
is
going
to
resolve
concurrently.
I
would
I
kind
of
feel
like
it's.
It
could
be
useful
to
get
the
later
list
items
when
they're
ready.
G
I
I
mean
the,
for
I
mean
the
so.
The
order,
like
the
actual
order
of
the
items
in
the
list
should
be
determined
by
things
like
arguments
to
the
field
or
other
directives
right,
like
sort
of
like
a
sort
order
like
so
my
assumption
was
just
that
it
would
always
come
in
in
the
list
order,
because
the
stream
directive
should
not
have
any
knowledge
about
any
about
the
actual
ordering
of
the
list.
Does
that
make
sense.
C
Lists
are
inherently
ordered,
though
you
know
like
there's
I
I
can
imagine
scenarios
where
you,
if,
if
there
is
not
an
implied
order
to
the
list,
then
waiting
for
the
first
one
before
the
later
ones
would
be
kind
of
an
explicitly
bad
thing.
C
It
certainly
seems
like
it
shouldn't
break
a
client,
though
I
rabbi,
your
your
point
seems
fair
that,
like
returning,
an
array
of
promises
is
like
a
completely
reasonable
abstraction
and
even
like
a
cache,
having
some
way
to
say
like
hey
and
basically
what
you've
done
is
deferred
every
element
of
this
list,
and
so
whatever
we're
gonna
do
to
represent
deferred
blocks
like
we're
gonna,
do
the
same
thing
here
in
the
cache.
K
K
G
It
could
happen
even
if
you're,
using
like
something
like
an
async
interval,
where
you
have
to
load
the
first
item
in
the
list
before
you
start
loading
the
second
one.
It
could
also
happen
if
in
a
resolver
below
each
of
the
list
item,
so
you
for
you
load
the
first
item.
Now
you
start
resolving
a
field
underneath
the
first
item.
Now
you
load
the
second
item.
You
start
resolving
a
field
under
the
second
item
and
the
field
under
the
second
item
finishes
before
the
first
one
started.
So.
K
Yeah,
okay,
I
think
what
we
do
is
that
we
basically
server
side
produce
a
buffer.
That
will
wait
for
that
first,
one
to
be
done,
and
then
we
can
send
both
at
the
same
time,
but
I
don't
believe
that
it's
possible
to
send
that
second
one
before
the
first
one
has
finished
and
I
could
be
wrong.
This
is
why
early
on
I
like
kawaii,
will
know
this
and
likely
will
have
like
more
wacky
of
edge
cases
or
like
wacky
of
possibilities
than
I
can
think
up
on
the
spot.
E
E
So
I
think
there
is
value
in
making
sure
that
the
server
side
does
those
things
in
in
some
order
and
that
the
client
can
just
basically
say
if
I
receive
something
that
I'm
not
expecting,
I'm
just
going
to
throw
it
out.
I'm
just
going
to
say
this
isn't
valid
like
this
server's,
not
a
valid
graphql
server.
K
It's
also,
I
think,
the
case
where
it's
reasonable
on
the
server
to
have
a
list
resolver
that
does
not
always
like
every
time
you
call
it
returns
a
list
and
returns
a
list
in
a
different
order,
depending
on
which
elements
in
the
list
resolved
soonest
and
like
that,
wouldn't
break
anything
if
it's
okay,
if
like
the
client,
can
handle
that
list
being
essentially
unordered.
G
You
could
always
wrap
like
in
in
order
like
a
an
unordered
list
into
an
ordered
one,
but
you
shouldn't
like
it,
but
definitely
like
you.
It
shouldn't
go
in
the
other
direction
automatically.
C
Another
way
like
if
we
want
to
punt
on
this
problem,
then
the
question
is:
how
do
we
reasonably
restrict
this
such
that
we
can
come
back
to
this
in
the
future,
and
it
seems
to
be
in
that
case
that
the
thing
that
we
would
do
is
have
streams
require
the
order
of
a
list
be
the
order
that
it
would
come
back.
Had
it
not
been
streamed
right,
so
you're
going
to
get
index
0,
then
index
1
and
index
2.,
like
basically
matt
what
you
described.
Facebook
server.
C
Does
the
buffered
approach
on
the
buffering
happens
on
the
server
rather
than
the
client
rather
and
then
in
the
future?
Should
we
want
to
revisit
that?
We
we
could
have
and
like
it
still
would
allow
the
unordered
case
right
like
if
you,
if
you
have
a
actually
unordered
list
under
the
hood,
that
it
like
raiifies
as
an
ordered
list
through
graphql,
then
whatever
like
resolve
them
in
whatever
order
you
want.
C
C
That
would
be,
I
don't
even
know
what
we'd
call
it
out
of
order
or
unordered,
or
something
like
that.
That
would
allow
us
to
then
resolve
those
things
in
another
way,
because
I
think
you
can't
go
the
other
way
around
right.
Like
you
can't
start
by
saying
we
don't
define
the
ordering
in
which
these
things
come
back
or
they
may
come
back
like
a
server,
may
choose
to
do
out
of
order,
delivery
and
then
later
say:
oh
actually,
we
we
want
to
restrict
that
behavior.
K
K
Yeah
so
yeah.
The
reason
I
was
like
unclear
midway
through
was
like
the
when
you
creating
a
client.
You
can't
you
need
to
make
sure
that
you
never
give
to
an
old
client.
If,
if
we
establish
that
you
have
to
have
an
ordered
list,
the
one
requirement
is
all
future.
Graphql
servers
that
implement
deferred
need
to
be
able
to
give
to
any
old
client
a
order.
A
strictly
ordered,
deferred,
payload.
C
Yeah
that
that
was
kind
of
my
thought
of
why
you
would
want
why
you
would
want
an
argument
to
opt
in
to
a
less
strict
delivery
order,
because
it
means
that
your
client
can
assume
strictness
and
then
opt
into
less
strict
and
therefore
more
complicated
to
to
handle
by
the
client.
But
you
know
with
potential
performance
gains
and
then
that
way
nobody's
going
to
send
that
argument
out
yet
because,
like
we
won't
have
one
and
if
later
in
the
future,
we're
like.
C
Oh
actually,
this
is
an
important
use
case
that
we
want
then
we'll
go
do
that.
But
the
other
thing
this
conversation
reminded
me
of
is
react
suspense
lists.
I
don't
know
if
y'all
are
familiar
with
that,
but
I'll
post,
the
link
in
the
chat
there's
a
parallel
discussion.
C
I
know
that
happened
within
the
react
contributors
where,
when
building
suspense,
they
basically
faced
the
exact
same
question,
which
was
they
had
an
array
of
promises,
and
this
was
like
a
user
experience,
not
a
developer
experience
thing
but
had
to
decide
like
what
is
the
appropriate
way
to
show
those
in
the
ui
as
they
start
to
resolve
and
the
initial
take
was
like
they
just
resolve
and
you
show
them
and
then
later
there
was
like
an
overwhelming
demand
for
having
a
more
strict
display
order,
and
so
the
suspenseless
component
got
built
where
you
can
define
whether
you
want
you
know.
C
Essentially
it
does
buffering
right
does
buffering,
where
only
reveals
them
in
the
order
in
which
they're
defined-
and
I
believe
facebook
uses
this
heavily
internally,
which
probably
aligns
with
what
you're
talking
about
matt.
K
Yeah,
I'm
not
super
familiar
with
the
react
anymore,
but
that
would
not
surprise
me.
I
assume
we
use
it
heavily
internally,
given.
G
G
But
I
think
it
should
be
more
of
like
a
tree
structure
or
something
so
that
we
can
prevent
both
the
deferrer
and
the
out
of
order
streaming
list
and
that's
probably
less
controversial
for
everyone.
So
we
should
probably
do
that
and
if
it
is
like
important
later
on,
then
we
could
opt
into
it
with
a
new
argument
or
something.
C
It's
also
it's
kind
of
nice
that
the
on
the
server
it's
actually
slightly
easier
to
not
buffer
yeah,
which
means
that
it's
it's
hopefully
not
too
difficult.
To
also
add
this
in
because
at
least
for
a
list,
I
think
all
you
would
do.
Is
you
just
create
another
layer
of
promises?
That
just
say
I
depend
on
all
of
my
fields
getting
resolved,
but
I
also
depend
on
the
previous
item
and
then
boom
we've
got
about
like
promises
to
the
buffering
for
you.
So
hopefully
it's
not
too
difficult
to
add
that
piece
in.
C
But
I
think
I
think
you're
right.
I
think
if
you
like
map
over
the
async
iterator,
that
also
does
buffering
for
you.
A
A
We
could
actually
deliver
the
inner
object
first
in
some
cases,
because
we
have
like
execution
plans
that
in
some
cases,
see
okay.
I
already
have
all
the
information
that
I
need
to
get.
The
child
object
object,
so
I
can
parallelize
the
request
journey,
but
most
clients
would
just
have
an
issue
with
that.
A
C
Well,
it
seems
like
the
takeaways
are
number
one
broad
agreement.
The
spec
should
at
least
say
something
about
delivery
order,
and
then
two
is
for
tree
based.
Dependencies
seems
like
there's
broad
agreement
that
your,
if
you,
if
the
assumption
is
that
clients
are
going
to
essentially
stitch
these
back
together,
that
the
like
stitch
path
should
be
resolved
on
the
client
and
then
that's
your
dependency
order.
C
G
But
so
I
mean,
but
we
will
definitely
need
more
functionality
than
what's
there
currently
of
just
of
just
not
caring
about
order
at
all.
So
I'll
start
to
look
into.
That
seems.
C
All
right,
let's
move
on
next
one
is
benji.
This
one
came
from
you
a
suggestion
to
move
from
slack
to
discord.
So
we've
we've
heard
this
suggestion
many
times.
E
E
Times
but
I
was
trying
to
look
back
over
slack
history
to
find
something
that
I
remembered
being
discussed
and
it's
gone
it's
too
long
ago,
and
I
think
that
this
is
painful.
E
I
think
important
discussions
tend
to
take
place
on
github,
which
is
good
and
desired,
and
obviously
they
take
place
in
the
graphql
working
group
meets,
but
there
are
offhand
you
know
the
odd
sentence
or
just
like
something
where
you
want
to
look
back
on
to
see
exactly
what
it
was
that
that,
like
I
remember
that
person
said
a
thing
about
that
thing.
What
was
it
exactly
that
they
said,
because
my
memory
is
fuzzy
and
I
think
the
loss
of
that
content
is
painful.
E
We
have
talked
before
many
times
about
different
solutions
and
the
one
that
people
keep
suggesting
is
discord.
I
know
personally,
I
moved
over
the
graphile
chat
to
discord
a
few
years
ago
and
have
not
looked
back.
It's
been
absolutely
brilliant.
It's
been
really
stable,
really
easy
to
manage.
E
It's
got
really
nice
tools
and
from
what
I
can
tell
discord
is
kind
of
growing
up
as
well.
It
was
very
much
like
a
a
gamer's
chat
system
years
back,
but
it
is
it's
still
that,
but
it
is
also
like
becoming
a
little
bit
more.
You
know
suit
and
tie.
E
So
I
think
it
is
becoming
more
appropriate
for
this
kind
of
community
and
I
think
that
they
are
actually
putting
effort
in
that
regard
as
well.
So
we
may
need
to
tweak
the
default
settings
to
make
it
more
appropriate
or
whatever,
but
I
think
it
is
generally
beneficial.
There
are
obviously
differences
from
slack.
I
know
one
of
the
ones
that
lee
has
an
issue
with
which
I
heard
you
discussing
earlier
when
I
signed
on
was
the
lack
of
threading.
E
There
are
solutions
to
that.
So,
for
example,
if
you
were
to
look
into
the
typescript
discord
server,
they
use
a
system
where
they
effectively
have
like
cycled
chat
rooms
where
you
effectively
trigger
a
thread
which
creates
a
or
takes
you
into
a
chat
room
to
discuss
that
thread.
There
are
other
ones
so
like
there's,
a
really
big
bot
for
discord
called
yet
another
general
purpose
discord,
bot.
E
And
that
has
a
feature
where
you
have
tickets,
so
you
effectively
say
ticket
and
it
will
create
a
channel
for
discussing
that
ticket.
So
there
are,
there
are
workarounds
they're
not
quite
as
convenient
as
just
going
clicking
on
the
thread
button
and
discussing
in
there,
but
it
has
to
be
said,
not
everyone's
a
fan
of
threads
anyway.
E
So
I
think
that's
very
much
down
to
personal
preference.
For
me,
the
not
losing
the
older
messages
outweighs
pretty
much
all
of
the
negatives
I
can
think
of
of
moving
to
discord,
so
I'm
very
much
for
it.
But
I
would
like
to
gather
other
people's
opinions
and
I
think
lee
you
set
up
a
discord
server
for
us
earlier.
C
I
did
I
saw
on
the
agenda
and
I
figured
better
late
than
never.
Let's
just
get
one
up
and
running
and
play
with
it
and
yeah.
I
I
think
the
last
time
I
used
discord
in
any
serious
way
was
when
the
reactiflex
folks
started
to
move
their
things
over,
and
it
was
a
little
bit
rough
in
the
beginning,
and
so
I
was
like
maybe
we'll
wait,
but
I'm
with
you,
I
think,
like
there's.
C
I've
been
very
frustrated
with
slack
of
not
having
any
kind
of
embrace
of
open
communities
and
discord
is
done,
the
exact
opposite,
and
in
fact
that's
how
I
I
just
googled
discord,
open
source
and
they've
got
like
a
landing
page.
That
says,
please
create
a
discord
project
for
your
open
source
work,
so
fantastic
on
them.
For
that,
I'm
I'm
for
it.
I
think
you
know
I
I'm
with
you
on
threads.
It's
in
my
work
slack.
C
We
heavily
use
threat
like
basically
no
discussion
happens
outside
a
thread,
but
I've
noticed
in
more
casual
or
less
aggressive,
slack
environments.
Threads
are
inconsistent
and,
like
you
either
want
to
thread
everything
or
thread
nothing.
Because
then
am
I
supposed
to.
Should
I
reply
to
them
in
the
thread?
Should
I
reply
to
them
in
the
chat
stuff?
C
Like
gets
crosswised
in
both
ways,
and
it's
it's
not
good
so
yeah
I,
I
will
only
very
lightly
mourn
the
loss
of
threading,
especially
if
it
means
that
over
the
long
run
we'll
get
our
history
back,
which
I
think
is
gonna
be
much
better,
so
I'm
for
it.
I
think
we
should
try
it
out.
A
A
Traffic
we
have
on
the
on
the
discord.
If
it's
not,
if
it's
a
huge
traffic
that
you
have
in
a
channel,
then
threats
might
really
be
a
loss,
but
anyway
this
court
said
so
they
have
that
on
their
agenda,
so
it
might
come
around
at
some
point
that
they
get
threats.
F
For
discord,
I'm
I'm
generally
in
favor
of
it
I've
also.
I
personally
prefer
it.
I've
seen
a
lot
of
success
with
it.
There's
two
trade-offs
that
I
wanted
to
call
out.
One
is
that
I've
had
some
trouble.
There's,
certainly
not
built
in,
or
at
least
I
don't
know
how
use
the
future
of
it
is
a
way
to
automatically
archive
message
history
for
a
given
channel.
F
Maybe
that's
not
as
much
of
a
requirement
here,
but
I
it's
a
pain
for
me
and
then
the
other
is
that
slack
still
has
much
stronger
bot
integration
right.
So
if
you
want
to
do
anything
like
slack
ops,
stuff,
obviously
that's
the
place.
I
know
that
that
is,
you
know,
discord
supports
bots,
so
it's
a
matter
of
the
ecosystem
becoming
more
short,
more
mature
over
time,
but
it's
also
a
matter
of
kind
of
looking
around
the
corner
and
seeing,
if
we're
going
to
need
any
of
those
requirements
in
the
next
six
months,.
C
That
is
good
to
know.
My
hope
is
that
I
have
not
looked
into
this,
so
this
is
speculation,
but
I'm
hoping
that,
because
they
have
started
to
embrace
the
open
source
community
that
most
of
the
bots
that
we
would
be
interested
in
have
already
been
built
or
are
being
built.
I
think
that
the
only
bot
that
we
currently
use
is
the
github
sync
bot
that
just
mirrors
all
the
github
activity
into
a
channel,
so
you
can
follow
along
in
one
place.
C
A
E
We
didn't
transition
from
slack,
actually
we
transitioned
from
gita,
I
think,
but
but
basically
all
I
did
was
I
just
posted
in
the
channels
we're
moving
here
in
all
the
channels
and
then
every
time
someone
posted
a
message.
I
just
replied
with
no
we've
moved
no
response
to
the
actual
question,
just
like
it's
over
here
now.
A
E
Yeah,
it's
definitely
an
issue
and
I've
seen
it
recently.
The
graph
the
graphical
discord
has
recently
merged
with
another
discord
server.
I
think
the
the
guilds
one
and
that
has
still
had
people
posting
in
the
original
one,
even
though
it
has
retired
in
its
name.
So
that
will
be
an
issue
for
a
while,
but
I
think
basically
the
solution
is
don't
reply
to
people
like
don't
answer
their
questions
instead
redirect
them,
and
hopefully
that
will
you
know,
get
the
message
across.
E
That
said,
if
we're
doing
this
as
a
trial
rather
than
a
commitment,
I'm
not
sure
exactly
what
the
the
trial
phase
would
involve,
because
we
don't
want
to
be
too
too
harsh
if
we
might
come
back
here
again.
So
I'm
not
exactly
sure
on
that.
A
Who,
who
owns
this
lecture,
is
that
you
lee
or
yeah?
Are
we
because
there
is
also
a
possibility
to
lock
the
channel
so
like
at
one
point
post
a
message
and
say:
okay,
we
are
now
moved
and
then
lock
the
channel
for
new
messages.
C
Yeah,
I
think,
because
it
would
we
yeah,
I
think
we
should
trial,
run
it
for
a
month
or
so
and
in
the
process
like
really
try
to
do
it
not
just
like
create
it
and
let
it
sit
there.
But
I'll.
I
pinned
the
message
in
the
wg
channel
and
I'll
do
the
same
in
a
couple
other
channels
and
just
I'll
I'll
mirror
over.
C
I
think
there's
like
five
channels
in
slack
that
are
actually
important
for
the
running
of
the
project
and
I'll
make
sure
that
all
of
those
have
a
corollary
and
after
a
month
or
so
if
everything
looks
good,
we'll
be
slightly
more
aggro
about
moving
things
over
or
rename
things
to
yeah,
retired
or
whatever,
and
but
really.
C
H
I
have
set
up
discord.graphql.org,
which
goes
off
to
the
discord.
Invite
url
for
the
for
the
one
you
just
set
up
here.
H
It'll
take
a
little
bit
for
let's
encrypt
to
provision
the
certificate,
so
you
might
get
an
error
on
that,
but
it
it
will
make
it
easier
to
point
people
over.
You
know
go
over
to
discord.graphql.org.
H
Was
just
going
to
say
that
other
projects
which
have
moved
off
of
slack
for
exactly
the
same
reason,
have
also
exported
the
entire
message?
History-
or
this
is
the
entire
public
message
history
and
then
archive
that,
so
you
can
at
least
refer
back
to
things
which
happened
in
the
public
channels,
because
even
if
they're
not
being
displayed
that
information
is
still
there,
it
doesn't
export
the
private
chats.
H
So
you
know
direct
messages
and
things
like
that
or
slack
rooms
that
are
that
are
private,
wouldn't
come
as
part
of
that,
but
it
at
least
keeps
a
record
and
an
indexable
record
of
what
the
project's
been
talking
about.
A
Yeah,
I
think
private
challenge
is
not
the
main
concern.
H
A
E
In
all
seriousness,
with
the
with
the
open
source
program
that
discord
do,
you
can
also
get
your
own
vanity
url
that
they
call.
So
I
suggest
that
we
do
this
as
well.
So
for
graphile
we
have
discord,
dot,
gg,
slash
graphile
and
we
can
probably
do
discord
dot,
gg,
slash
graphql.
E
I've
already
done
that
once
so,
I'm
happy
to
to
spearhead
that
I
think
I'll
probably
need
the
relevant
permissions
or
embley.
You
can
take
that
one
if
you
prefer
whatever.
C
J
I
can
also
add
a
bit
on
that
like
we
have.
The
guild
has
like
a
popular
discord
channel
and
the,
and
we
modeled
the
channel
the
server
and
we
modeled
all
the
channels
according
to
just
being
general
graphql,
and
we
have
no
business
of
like
having
our
own
discord
channel
if
there
is
a
graphql
channel,
so
we
can
just
hand
it
over
there's
a
lot
of
channels
active
channels,
a
lot
of
active
people.
J
There
will
be
that's
why
also
we
merged
with
the
graphql
community
discord
channel,
because
the
idea
was
to
just
grow
it
and
then
at
some
point
when
the
foundation
is
taking
over,
you
can
just
take
over
this
one.
So
I
don't
know
if
it
makes
sense
or
not,
but
yeah
we're
very
happy
to
do
that.
E
I
think
another
like
important
question
about
this,
and
about
chat
in
general
is
exactly
what
the
scope
of
the
chat
server
should
be
like
is
it
is
the
scope
of
it
to
talk
about
foundation,
graphql
foundation
projects,
or
is
it
you
know?
Is
it
appropriate
to
have
a
channel
for
each
graphql
related
project
that
wants
one
and
that
kind
and
like
the
meetups,
and
you
know
everything
else
that
can
go
on
what?
What
exactly
policy
do
we
have
in
place
for
the
the
existing
slack
on
that
on
that
regard,.
C
The
existing
slack
is
really
a
free-for-all.
It's
anyone
is
allowed
to
show
up.
You
don't
need
a
formal
invite
and
then
at
that
point
it's
just
it's
a
slack
group
you
anyone
can
create
a
channel
and
do
whatever
they
want.
So
you
know
the
I
think,
there's
no.
As
long
as
people
are
abiding
by
the
code
of
conduct,
then
we
should
be
in
good
shape.
C
There's
not
a
huge
amount
of
activity
on
the
slack
there's
some
questions
in
general
and
there
are
a
handful
of
channels
around
language,
specific
things,
but
I
think
mirroring.
The
same
is
probably
wise.
C
C
C
All
right
we'll
get
that
set
up
benji.
I
think
I
just
gave
you
a
bunch
of
permissions.
Let
me
know
if
there's
others
that
you
need
to
get
stuff
done,
but
otherwise
feel
free
to
start
making
stuff
and
yuri.
I
don't
know,
maybe
we'll
follow
up
offline
about
what
it
would
take
to
merge
or
combine
or
do
something
with
these
I'm
with
you.
I
think
it
makes
sense
to
have
sort
of
like
one
unified
place,
but
we'll
get
there.
J
C
Thanks
very
exciting:
okay.
Moving
on,
we
have
argument
uniqueness,
hi
everyone,
I'm
lavan.
E
So
I
mean
I'm
in
iran's
place
here.
He
couldn't
make
it
to
to
this
meeting.
So
he's
asked
me
to
to
champion
this
for
him,
but
effectively,
we've
had
this
work
on
going
for
a
while.
The
argument
uniqueness,
like
it
comes
up
during
the
action
items
on
many
of
our
working
group
meetings
ivan,
has
now
written
the
spec
changes
that
are
required
for
this
and
has
added
the
unique
argument.
Definition,
names,
rule
validation,
rule.
E
Basically,
we
don't
have
a
rule
in
the
spec
right
now
that
says
that
arguments
have
to
be
unique.
We
have
the
fields
have
to
be
unique,
but
we
don't
have
that
written
for
arguments.
So
this
is,
I
looked
over
it
earlier.
It's
a
very
small
change
to
the
spec
in
three
places.
I
think
three
places
that
just
basically
adds
the
constraint
that
argument
names
must
be
unique,
so
yeah.
Basically,
I
think
my
job
here
is
to
try
and
have
us
advance
this.
Maybe
a
stage.
E
But
it
is
a
very
late
addition
to
the
schema
to
the
agenda.
G
C
Looks
like
in
the
last
couple
of
hours,
so
ivan
is
traveling
so
too
busy
to
show
up
here,
but
not
too
busy
to
write
some
code
so
good
on
him.
So
he's
put
these
things
up
for
review
already,
literally
over
the
last
hour
or
so
pretty
pretty
fantastic.
C
C
A
Have
I
have
another
question
not
not
regarding
this?
If
this
go
is
what
about
the
amaze
specification
release,
do
we
have
a
release
already.
C
The
cut
is
ready,
I'm
holding
on
committing
anything
to
the
spec
record
repo
until
we
formally
cut
it.
The
last
piece
is
that
we
need
a
formal
vote
brian's
going
to
help
us
with
that
formal
vote,
but
I've
had
the
material
up
to
review
for
coming
on
two
months
now.
So
there's
no
excuse
to
not
be
well
versed
in
the
material,
so
we're
just
gonna.
Take
a
quick
vote.
A
And
just
just
for
the
procedure,
is
there
a
deadline
for
the
vote
so
or
is
it
by
everybody
has
to
consent.
H
It's
it
needs
to
be
open
for
at
least
a
week,
but
of
course,
if
we
hit
the
threshold
before
then
then
the
vote
can
close.
I
believe
it
is
a
majority
vote,
although
I
will
have
to
double
check
on
that.
I
H
Yeah,
so
this
is
it's
a
tsc
boat,
so
give
me
one
second
here
and
I'll
drop
the
link
to
everybody
who's
currently
on
the
tsc.
I.
C
These
are
these,
are
I
mean
we
list
the
affiliation
in
here,
but
they're.
The
idea
with
the
tsc
is
they're
all
individuals,
so
I
think
we
added
james
in
with
the
assumption
being
that
he
would
have
knowledge
of
and
well
represent,
apollo
where
he
doesn't
work
there
anymore,
but
his
his
term
does
come
up
at
the
end
of
the
year.
So
if
he
decides
he
doesn't
want
to
be
on
there
anymore.
I
guess
he
could
decide
to
forfeit
at
any
time
too.
If
he,
I
think
he
still
represents
apollo.
I
To
a
certain
extent,
okay,
a
lot
of
his
dna
is
still
into
company.
C
There
was
one
other
thing
you're
going
to
talk
about
brian.
It
is
yours.
I
Oh
yeah,
so
this
is,
we
can
make
this
quick
we're
at
apollo
for
the
second
half
of
the
year,
we're
sort
of
trying
to
figure
out
what
we
want
to
do
with
subscriptions,
and
so
the
history
of
this
is
that
there
was
apollo
initially
had
the
created
like
a
repository,
and
I
think
uri
might
have
had
played
some
role
when
he
was
at
apollo.
It
was
called
like
subscription
transport
ws
or
something
at
some
point.
It
fell
into
this
dis
maintenance.
I
Maybe
I
can
say
that
or
like
we
just
haven't,
had
the
people
to
work
on
it,
and
so
there
was
a
fork
of
it
done
by
a
community
member
which
is
now
suppose
really
the
one
of
the
more
popular
graphql
websockets
implementations.
I
So
like
I'm,
conflating
subscriptions
and
websockets
to
a
certain
extent,
I
maybe
I
should
have
labeled
this
topic,
websock
websockets
and
not
subscriptions
but
anyways.
My
question
is:
is
this
something
that
the
graphql
working
group
wants
to
adopt
like?
I
know
that
we
already
have
a
graphql
hd
http,
like
working
group
like
a
subtle
workout.
A
Snlfc
on
the
graph
or
http
working
group-
and
we
are
also
now
moving
to
the
it's-
I
think
graphical
ws
is
a
new
one
and
it's
proposed
there-
it's
not
yet
merged,
but
there
is
a,
I
mean,
he's
very
active
and
he,
I
think,
solved
a
lot
of
the
rough
edges
that
the
original
apollo
protocol
had
so
there's
work
on
it.
I
Yeah
so
there's
a
lot
of
there's
a
couple
like
protocol
changes,
which
happened
like
I
think
in
august
of
last
year,
so
we're
trying
to
figure
out
like
what
is
what
are
what
are
the
exact
changes
in
the
protocol
between
like
apollo,
subscription
the
apollo
protocol
and
then
sort
of
the
new
graphql
websockets
protocol
like
and
it,
and
so
if
this
is
something
that
the
graphql
working
group
would
like
to
sort
of
look
over
yeah.
A
And
this
is,
I
mean
if
you
look
at
the
package
in
javascript,
it's
taking
really
off,
so
I
can
see.
Most
implementations
are
switching
over.
I
hope
that
we
get
the
support
in
for
the
net
implementation
this
for
this
month
and
yeah.
It's
it's
very
active
so
also
when
you
post
something
in
there.
He
almost
dances
in
two
or
three
hours.
So
it's
very,
very
active
contributor.
A
Because
that
I
mean
that's
mainly
transport,
so
what
what
we
would
our
server
do
is
at
the
moment
we
support
both
protocols,
so
we
essentially
did
abstract
it
and
then,
depending
on
the
sub
protocol
and
web,
socket
that
you
provide,
we
either
use
the
apollo
the
old
apollo
version,
because
there's
still
a
lot
of
tooling
that
uses
the
apollo
stuff
or
this
new
protocol.
E
We
do
the
same
in
postgraph
file,
so
we
support
both
protocols
in
parallel,
yeah
yeah,
I
mean
yeah.
That's
a.
C
Sounds
good
it'll
be
exciting
to
have
it
all
in
one
place.
I
think
it
makes
sense
to
have
like
expand
the
idea
of
graphql
over
http
to
like
graphql
transport
and
then
talk
about
those
two
concepts,
because
websockets
is
really
like
it's
about
they're
both
about
how
to
do
this
over
the
web
and
that's
really.
A
Yeah
and
the
over
http
spec
deals
now
with
this
graph
of
web.
Also
with
there's
also
rob,
did
a
lot
of
work
on
the
incremental
delivery
stuff.
So
it's
not
only
the
simple
http
poster
displays
right.
There.
I
Yeah,
we're
gonna
have
to
figure
out
what
the
differences
are
at
apollo
between
the
apollos
protocol
and
sort
of
the
new
working
group
protocol,
and
hopefully
we
can
figure
out
a
way
forward
on
apollo
10
yep.
A
It
would
be
really
great
if
you
guys
get
more
into
participating
in
there,
because
you
have
a
huge
user
base.
E
Right,
it's
also
worth
having
a
look
back
at
some
of
the
older
working
group
meetings,
because
dennis
actually
attended
those
meetings
and
explained
his
protocol
what
the
differences
were
from
the
apollo
1
and
why
those
differences
are
there.
I
believe
there
was
security
concerns,
for
example,
like
I
don't
know
whether
it
was
like
double
initialization
problems
or
zero
initialization
problems
like
there
were
things
that
could
be
skipped
out
of
the
needn't
be
or
things
that
could
be
fired
twice.
E
That
would
only
be
expected
to
be
done
once
and
various
other
things
like
that.
So
I
think
that
he,
he
does
definitely
have
a
good,
I
mean.
Obviously
he
knows
why
he
did
those
things
so
talking
directly
with
dennis
about
that.
I
think
would
be
wise,
but
also
looking
over
the
the
previous
recordings.
I
I
have
I'm
agnostic
about
that
sort
of
stuff
and
I'm
sure
that,
like
you,
guys,
have
been
working
really
hard
on
it
and
I'm
excited
to
see
the
changes
that
have
been
made
and
definitely
there's
been
a
lot
of
interest
in
it
like
like,
if
you
think
about
like
what,
like
websocket
protocols,
are
out
there
like
wham,
the
the
unfortunately
named
web
stuff
right
like
it's
all
like
graphql,
could
do
do
a
lot
by
entering
that
space
for
subscriptions,
and
you
know
websockets
yeah
or
it's
already
in
that
space
so
exciting.
Thank
you.
C
Oh
sorry,
I
made
it
yeah
thanks
for
that.
Okay,
I
think
that
was
the
last
thing
on
our
agenda
today.