►
From YouTube: GraphQL Working Group (Secondary, APAC) - 2023-01-11
Description
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools. Get Started Here: https://graphql.org/
A
A
C
D
A
E
E
E
So
if
I,
if
I
like
disappear
off
the
call,
then
that's
what's
happened.
I
hope
that
that
won't
be
the
case,
but.
E
How's
everyone
doing
it's
been
for
the
folks
in
Australia.
It's
the
first
time,
I've
seen
y'all
since,
before
the
holidays,
hope
everybody.
E
E
You,
sir
I,
just
dropped
a
link
to
the
agenda
in
the
chat
just
so
everyone
can
follow
a
wrong
I
think
we
have
a
tight
agenda
today,
but
let's
dig
into
it
welcome
all
by
joining,
we
all
agree
to
the
spec
membership
agreement,
participation,
guidelines,
contribution,
guide,
conduct,
Great
Links
there
to
all
those.
If
you
ever
want
to
read
up.
E
Let's
do
a
super
quick
intros,
especially
since
Anthony
youth.
It's
your
first
time
here
in
a
little
bit
of
time,
and
is
anybody
taking
notes
by
the
way.
E
But
anyhow,
let's
get
on
with
intros
we'll
go
in
the
order
that
is
listed
there
and
you
can
say
yourself
last
since
you're,
adding
yourself
I'm
at
the
top
list.
So
hello,
everybody,
my
name
is
Lee.
A
Hey
everyone,
my
name
is
Donna
and
representing
graphql,
Java
and
Adolescence.
B
And
Roman's,
not
here
so
I
will
go
next:
hey
I'm,
Anthony
I'm,
with
Apollo
graphql
I
work
on
the
iOS
client
project.
E
It
awesome
and
I
just
merged
your
pull
request,
so
we've
got
everyone
accounted
for
in
our
agenda
file
I
also
added
the
Google
doc
in
we've,
just
been
using
the
same.
We've
been
doing
one
per
month,
so
hopefully
everyone
can
see
that
I'll
add
a
little
line
in,
but
if
anyone
wants
to
help
us
take
notes
along
the
way,
that
would
be
very
helpful,
I
added
a
new
bit
to
the
agenda,
which
is
just
to
catch
everybody
up
with
what's
going
on
prior
and
we
do
have
Roman
here.
E
After
all,
fantastic
welcome,
Roman.
As
soon
as
you
get
connected
to
audio
and
visual,
you
can
single
up.
Okay,.
E
Since
a
handful
of
you
were
not
in
the
previous
meeting,
I
just
added
this
as
a
default
agenda
item
to
just
do
a
quick
recap
that
way
everyone's
kind
of
caught
up
on
on.
What's
going
on
in
the
last
meeting,
which
was
last
week,
the
primary
thing
we
talked
about
was
fragment
arguments
which
Matt
you
have
a
couple
updates
on.
You
can
help
walk
us
through.
We
talked
about
some
open
pull
requests
on
editorial
changes
from
Roman
and
Hansel,
which
were
emerged,
a
handful
of
which
have
some
call
for
actions.
E
There's
a
old
default
value,
validation,
work
that
actually
Andy
you
and
I
had
spent
a
lot
of
time
on
I.
Think
a
year
and
a
half
ago
that
Yakov
has
been
getting
back
into
a
healthy
State
for
the
Garfield
JS
stack
and
the
actual
final
spec
changes.
E
He
gave
us
an
update
on
and
then
well
it
says,
15
minutes
I
think
we
ended
up
spending
a
healthy
amount
of
time
on
on
deferred
stream
and
some
details
on
how
to
do
merged,
deferred,
fragments,
which
is
pretty
interesting.
But
if
anyone
has
any
questions
about
any
of
those
things,
I'm
happy
to
answer
foreign.
D
Value
stuff
like
so
it
doesn't
mean
like
your
work,
was
never
merged
early
yeah.
E
The
work
on
the
graphql
JS
stack
was
never
merged,
because
I
was
doing
that
work
at
the
same
time.
Excuse
me
that
Yvonne
and
a
couple
of
others
were
migrating.
The
code
base
to
typescript
and
he
asked
me
to
hold
off
on
merging
until
that
happened
that
ended
up
being
a
pretty
significant
refactor
and
so
the
like
restacking,
all
those
diffs
was
non-trivial,
which
yaakov
just
did,
and
there
was
also
some
spec
changes
that
may
need
to
change
based
on
some
of
the
Nuance.
There.
E
I
think
that
the
spec
PR
that
we
had
up
is
still
probably
accurate
draft,
but
it
actually
wasn't
clear
whether
Yakov
was
taking
over
championship
of
that
or
not
I
worry
that
the
action's
still
on
me,
but
I,
don't
think.
There's
anything
specifically
unique.
I
know
that
Andy
props
to
you.
You
got
ahead
of
the
curve
and
got
everything
merged
into
Garfield
Java.
So
things
are
in
a
better
State.
There.
D
Yeah,
so
maybe
my
memory
betrays
me
here,
but
I
think
there
was
basically
two
things
right
like
first
sorry,
first
was
like
brought
up
by
Benji
that
there's
some
validation
missing
in
general
for
for
default,
values
and
I
think
there
was
even
a
spec
addition
to
improve
validation,
somehow
I'm
not
sure
we
ever
implemented
more
validation.
But
fundamentally
we
implemented
the
moderately.
We
we
came
up
with
and
and
basically
fixed
all
default
value
handling
in
crafter
Java.
A
D
D
We
never
have
like
weird
State
now,
where
we
don't
know.
This
is
like
a
coerced
value
or
raw
value
or
literal,
like
all
of
these
nuances
and
and
confusions
went
away.
The
one
thing
that
we
ended
up
really
needed
is
like
the
additional
function
for
the
scalars,
like
this
value
to
HT
thing
which,
which
Pro,
which
converts
a
value
to
a
HT
literal,
that's
definitely
needed,
and
actually
this
work
influenced
the
custom.
Scalar
work,
also
they've
done
and
I
did
so
this
this
work.
D
What
we
did
a
little
said
in
some
way
the
foundation
that
we
could
have
a
consistent
custom,
scalar
spec
in
in
some
details,
so
yeah
overall
from
traffic,
Java
I
think
it
worked
very
well.
D
It
kind
of
fixed
up
all
the
things
that
that
were
unclear,
happy
to
see
the
progress
in
protocol
JS
also
I'm
I,
must
say
just
as
a
meter
comment.
I
I
feel
from
what
I've
seen
in
other
implementations
that
a
lot
of
other
implementations
get
away
with
a
simpler
model,
so
I
think
Python
and
Ruby
and
stuff.
D
They
don't
have
four
different
functions
in
a
coercing
interface
for
for
custom,
scalers
and
and
just
to
share,
like
I,
think
this
works
well
for
99
of
the
custom
scalers,
especially
if
the
ones
that
that
are
very
similar
to
the
building
ones.
D
E
D
Json,
maybe
in
some
respects,
for
example,
or
or
I'm
gonna,
have
another
good
example.
Some
custom
scalers,
where
you
didn't
have
literal
for
something
like
this.
So
it's
more
like
you,
you
you
you
we
we
made
it
100
now
and
before
it
was
95
Maybe
yeah.
D
A
E
Think
that's
right,
yeah
I
think
that's
right,
I!
Remember
there
being
an
input
from
the
custom
scalers
bet
about
like
one
of
the
particular
translation
paths
there
being
non-obvious
and
the
goal
of
that
work
was
to
remove
the
amount
of
times
that
you
would
have
to
do
something
that
was
not
obvious
yeah.
But
it's
also
tough
to
page
that
all
back
into
my
memory.
D
D
E
Awesome:
let's
talk
about
graphql,
scalars
and
Licensing.
E
E
E
The
tricky
part
here,
I
think,
is
that
there's
two
separate
things
that
we
need
to
think
about.
I
see
the
pull
request.
Open,
that's
been
sitting.
Sorry,
that's
been
sitting
on
me
for
a
while
adding
the
MIT
license
that
license
is
code,
not
specification
text
so
to
the
degree
that
there's
like
a
graphql
scalar's
technical
project
that
like
builds
the
website
and
like
all
the
code
written
that
sits
in
there
licensing.
E
That
MIT
is
exactly
the
right
thing
to
do,
and
so
we
will
add
that
and
I
think
that
aligns
tightly
with
actually
the
license
in
the
and
the
package.
Json
says
owfa,
but
owfa
is
the
license
that
we
would
want
on
the
spec
text
that
covers
spec
text.
There's
like
weird
reasons
for
why
they're
different,
but
that's
that's
what
it
is
I
think.
D
Okay,
yeah
I
think
it
makes
sense.
It's
like
the
the
for
us.
The
most
important
lesson
that
you
said
is
I,
think
the
owf
license
whatever
yes
and
that,
because
we
are
looking
not
for
code
contributions
right
like
we
have
a
little
bit
code
there
that
maybe
built
something
or
does
some
infrastructure,
but
the
actual
real
value
lies
in
the
spectex,
and
this
is
not
code.
Yes,
and
if
you
say
we
want
to
use
the
ow
F
license
the
same
as
for
the
actual
spec.
A
D
A
I
wonder
if
if
we
just
used
the
same
license
as
what's
already
existing
for
the
graphql
specification,
do
we
need
to
get
extra
sign
off,
or
can
we
just
say
it's
the
same?
We.
E
Yeah,
the
the
license
I'm
pretty
sure
the
license
for
the
spec
is
like
embedded
into
the
spec
itself.
I,
don't
think
that
we've,
like
chopped
it
out
to
a
separate
file,
necessarily.
D
E
We
can
we
can
copy
it.
Okay
and
there's
there's
a
version
we
can
link
to
as
well,
which
is
here.
I'll
show
you
just
put
a
link
in
the
in
the
chat.
E
Which
is
this
is
a
terrible
website,
but
that's
the
like
official
version.
A
E
E
A
D
It
would
also
be
created
not
a
treat
it
as
something
completely
different
right.
This
is
kind
of
stupid,
trafficker,
spec
text
in
The
Wider
sense,
even
if
it's
a
different
brief
on
everything,
it
would
be
great
that
we
don't
open
up
different
processes
and
stuff
around
this.
You
know.
A
D
We
can
because
it's
it
should
follow
the
same
rule
as
when
you
fix
something
in
the
enormous
thing
yeah
and
but
but
you
think
we
should
add,
like
a
line
to
Italy
into
the
into
the
templates
that
this
is
under
this
license.
E
E
E
Don't
know
if
it's
useful,
maybe
we
can,
like
add
I'll,
add
something
to
the
readme
that
just
like
enumerates
this
and
then
that
way
the
template
can
be
like
extremely
succinct
and
then
just
like
link
back
to
the
readme
and
that'll
be
more
than
enough
rather
than
me
doing
that
like
live
during
a
recorded
call,
let's
just
aim
to
end
end.
Our
call
on
timer
earlier
and
I
will
use
like
the
last
30
minutes
of
our
time
slot
to
go.
Do
that.
E
I
think
you
can
go
ahead
and
merge
it
yeah
there's
no
harm
in
doing
that,
feel
free
to
merge
that
and
then,
if
there's
any,
because
what
we'll
do
is
say
any
code
that
exists
is
MIT
licensed
and
any
specifications
that
are
in
the
repo
our
open
web
Foundation
agreement
license,
which
is
that's
owfa
cool,
so
the
I'll
do
a
follow-up,
PR
and
I'll
just
reconcile
I'll,
add
I'll,
add
whatever's,
missing,
I'll,
add
the
stuff
to
the
template
and
then
the
MIT
license
will
be
there.
So
we'll
be
good.
D
Yeah
that
that
would
be
awesome
because
we
want
to
promote
it
a
little
bit
more
like
get
a
blog
post
out
or
something
and
use
it
really.
So
then,
let's
not
hold
up
the
meeting
longer
that
he
has
time
to
think
totally.
E
E
You
know
we'd
want
to
make
sure
that
we've
got
the
license
in
before
we
merge
them,
but
like
in
terms
of
encouraging
people
to
start
showing
up
and
adding
PR's.
To
this
thing
you
should,
you
should
feel
unblocked
to
at
least
do
that,
especially
if
the
goal
is
to
like
get
the
legal
stuff
polished
out
imminently,
then
we
should
be
good
cool
anything
else.
We
need
to
get
the
graphical
scalers
project
up
and
running
is.
Is
it
just
the
getting
the
licensing
stuff
ironed.
A
D
A
A
Yeah
and
then
to
Do's
on
me
after
we
get,
the
legals
done
is
to
write
that
announcement.
Blog
post
I've
already
got
one
half
done
and
I'll
finish
it
up
with
Andy
and
I
was
also
thinking
the
graphql
specification
dot
could
link
to
this
custom
scalers
piece
in
the
custom
scale
section
just
so
it's
more
discoverable.
E
That's
a
good
idea
yeah,
we
could
add.
Like
a
non-normative
note,
there
I
like
that.
A
Yeah
cool,
that's
yeah,
that's
all
I
had
Andy
did
there
have
anything
else
for
it.
D
No
not
really
like
the
other
thing,
I
want
to
mention
as
I
spread.
The
word
I'll
use
it
or
like
like
look
into
it.
If
you
can
so.
E
E
Sorry
for
letting
that
sit
on
me
for
longer
than
it
probably
should
have.
Let's
move
to
Matt
you've
got
some
updates
on
fragment
arguments.
Yep.
C
So
the
last
working
group
meeting
a
week
ago,
we
decided
frame
Menards.
There
are
some
open
questions
that
I
put
an
action
item
on
me
to
gather
those
open
like
what
are
the
concerns.
What
are
things
that
we
really
need
resolution
on
and
additionally,
so
basically
the
set
of
concerns
I've
gathered,
the
ones
I
know
about
are
number
one.
C
Do
we
allow
shadowing
Global
variables
I'm
fairly,
confident
the
answer
is
yes
and
the
reason
I'm
confident
is
because
that's
how
relay
works-
and
it's
been
you
doing
that
relays
at
arguments-
definitions
like
if
it
works
for
relay
and
it's
been
used,
thousands
of
times
that's
Pro
and
they
have
not
had
any
support
issues
with
that.
That's
probably
good,
but
I'll
I'll
add
more
opportunity
for
people
to
comment
on
that.
C
C
Another
one
is
PR
reviews,
that's
just
like.
We
will
need
those
before
it
can
go
to
draft,
but
probably
I
should
iterate
on
the
PRS
a
bit
more,
especially
because,
as
I'm
going
through
bit
by
bit
on
the
variable
definitions,
piece
I'm,
finding
a
few
bugs
in
the
spec
text,
which
is
great
and
then
the
last
one
I
know
about,
is
a
somewhat
of
a
concern.
C
The
spectex
is
basically
describing
fragment
arguments
as
being
locally
scoped
is
defining
the
algorithms
using
a
kind
of
new
local,
locally
scoped
variables
concept
and,
whereas
in
graphql.js,
the
way
that
we're
currently
implementing
it
is
find
replace,
essentially
like,
as
you
hit
a
fragment
spread
like
replace
all
the
arguments
passed
in
with
the
values
and
like
create
a
new
instance
of
that
fragment,
but
yeah
yeah.
So
that's
those
are
the
concerns.
I
know
about
I
was
wondering
if
other
people
know
other
concerns.
B
Not
necessarily
a
concern,
but
we
had
a
conversation
today
about
this
internally.
That
way,
there's
some
thing
that
was
unclear.
It
says
at
the
top
of
the
pr
that
this
is
intended
to
be
like
a
client-only
feature.
C
Yeah
yeah,
that's
like
that,
might
have
changed
yeah
that
has
changed
the
pr
is
old,
so
possibly
a
better
thing
would
be
closing
this
P
like
I,
don't
part
of
the
problem
is
I,
don't
use
GitHub
internally,
I,
don't
use
GitHub
very
often
so
I
don't
know
people's
preferred
like
modes
I'm
used
to
making
very,
very
small
commits
of
making
a
hundred
of
them,
and
that's
not
how
GitHub
PR's
work
so
would
it
be
like
this
is
actually
a
very
good
concern?
E
I
think
that's
that's
probably
okay,
you
could
always
link
back.
You
could
just
like
enough,
has
significantly
changed
since
an
earlier
version
of
this,
that,
for
like
Clarity
of
progress,
we've
clean
slated
it
and
have
a
fresh
take
at
the
current
proposal
and
then
with
like
a
link
like
if
you
want
the
historical
backlog
of
what
led
us
here,
like
here's,
a
link
to
the
closed
PR
issues.
D
A
Sorry,
just
to
change
the
subject:
a
little
bit
Roman
was
having
difficulty
with
some
secure
mode
for
Zoom
thing:
I,
don't
know
if
that's
the
setting
in
the
Securities
tab
for
you
Lee,
you
might
try
and
rejoin.
E
Okay,
so
I've
also
not
seen
that
before
he
rejoins.
B
C
So,
there's
nothing
that
would
prevent
clients
from
doing
that.
In
fact,
the
right,
the
original
reason
I
made
the
pr
was
because
relay
already
had
these
had
a
in
its
compiler
already
was
doing
this
transform
and
it
would
just
be
a
lot
cleaner
to
have
those
AST
nodes
available
so
that
we
could
parse
them
and
do
the
transform
but
yeah.
So
so
there's
nothing
preventing
that.
It's
just
there's,
no,
like
the
all.
C
B
I
think
it's
actually
way
less
work
than
trying
to
transform
the
operation.
Definitions
is
so
I'm
all
for
that
I'm
just
wondering
if
there
was
for
for
Apollo
client.
We
need
to
support
like
every
server
out
there.
So
I
want
to
make
sure
that
there's
a
still
a
way
for
us
to
do
that,
theoretically,
for
servers
that
don't
implement
this
yet.
B
B
D
I
love
a
question
Matt
like
for
me.
It
looks
like
especially
if
you
say
it
could
be
theoretically
done
completely
on
the
client.
It
looks
like
a
little
bit
simplified.
Put
syntactic
sugar
like
a
simplified
thing,
is:
is
this
correct
or
is
it
like
some
gotchas
regarding
execution
or
validation
that
is
tricky
and
that
we
should
be
aware
of
so.
C
Nature
gotcha
is
that
when
you
implement
this
purely
on
the
client,
you
end
up
expanding
like
the
way
relay
does
it
is
that
we
expand
each
fragment
for
each
unique
set
of
arguments
that
are
passed
in
we
basically
it.
Basically,
they
become
template
definitions
instead
of
true,
like
parameterized
fragments,
and
that
has
server
cost.
That
has
that
has
like
execution
time
costs,
because
now,
if
you've
got
profile
picture
in
18
different
iterations,
now,
like
you
have
to
add
that
text
18
times.
C
So
so
we
we
do
the
transforms
client
side
to
so
by
the
time
that
we
persist.
One
of
these
queries
to
the
server
it
has
already
been
like
transformed
out,
so
the
fragment
that
is
fragment
with
width
like
with
argument
with
of
type
int
or
whatever.
Every
time
we
do
dot
dot
dot.
My
fragment
with
every
unique
thing
there
gets
transformed
to
being,
like
my
unique
fragment,
underscore
underscore
some
value
for
width.
E
I
wonder
if
you
have
some
setting,
that's
like
your
only,
but
you
can
only
participate
in
encrypted
meetings.
I,
don't
think
our
our
meeting
is
encrypted
because
I
did
a
little
bit
of
Googling
and
it
says
that
we'd
see
like
an
encrypted
lock,
icon
I,
don't
see
that
I
actually
don't
even
see
the
ability
to
turn
it
on.
So
no.
E
B
E
B
Should
be
allow
use
of
end-to-end
encryption
and
then
a
default
encryption
type,
either
enhanced
or
end
to
end
under
securities.
E
E
E
We'll
figure
it
out.
Can
you
pop.
E
C
This
is
a
status
check
and
it
was
helpful
because
I
found
the
PR
issue
and
I,
don't
I,
don't
think
we
added
I'm
I
didn't
have
time
to
put
in
notes.
Was
there
something
else
that
we
added
as
an
open
concern?
C
I,
don't
think
so
so
yeah?
It
was
basically
just
like
making
sure
I
gathered
the
open
concern
so
that
when
I
like
re-present
or
whatever,
as
like,
hey
people,
this
is
ready
for
actual
reviews
like
I
right
now,
I'm
the
one
that's
blocking
it
for
moving
forward.
I
want
to
make
sure
that
I
have
everything
I
need
so
that
other
people
become
the
thing
blocking
it.
For
me,.
E
C
D
Can
I
actually
add
one
one
thought
already
yeah
I
I
was
always
glancing
over
your
page
again
and
I.
See
like
you,
you
change.
The
overlapping
Fields
can
be
merged,
validation,
nothing
against
it.
Fundamentally.
D
I
just
want
to
call
out
that
this
is
our
most
expensive
validation
we
do
and
in
graphical
Java
we
actually
have
a
highly
optimized
version
Implement,
which
is
not
the
spec
text,
which
is
like
a
like
somebody
else
years
ago
did
some
work
and
we
adopted
this
work
and
and
we
we
saw
like
a
lot
of
performance
improvements
because
of
this
optimized
validation
and
and
I'm
a
little
bit
like
this
is
one
of
the
most
complex
pieces
in
the
whole
spec
and
and
I'm
I'm
a
little
bit
worried
about
changing
this,
how
it
affects
the
optimized
implementations
and
if
we
can
still
keep
it
optimized
I
just
want
to
call
this
out.
C
I
agree
one
of
the
key
things
that
so
this
is
actually
also
true
of
graphql.js
I'm,
not
sure
that
we
are
as
optimized
as
graphql
Java,
but
we
in
graphql.js
like
we
make
sure
that
we
only
visit
each
fragment
once
and
this
becomes.
So
if
you
just
do
the
pure
client-side
thing.
E
We
have
a
thesis
that
that
the
times
when
you're,
using
fragments
with
variables,
you
are
unlikely
to
have
merged
fragments
in
the
first
place
right
they're
going
to
be
one
else
or
in
the
case
where
you
have
more
than
one
of
them.
Your
intent
is
actually
to
have
them
be
separate
in
the
first
place,
yeah.
C
Such
a
separate
problems
right,
so
we
can.
We
can
actually
like
stop
the
validation
a
little
bit
earlier
because
of
fragment
arguments,
because
if
you,
if
you're
trying
to
spread
two
fragments
with
different
arguments,
we
don't
need
to
there's
two
fragments
of
the
same
name
with
different
arguments.
We
don't
even
need
to
go
into
each
of
those
selection
sets
we
can
just
pop
out
and
be
like.
That
is
not
what
you
intended
to
do.
C
D
Bit
more
inside,
like
I
We,
have
basically
I
know
of
three
different
validation:
algorithms,
the
one
in
the
spectix,
the
original
one,
the
craft
code.js
version,
which
is
optimized,
and
then
the
one
we
have
in
graphical
Java
based
on
other
work,
and
they
are
very
different,
all
three
so
so
I
think
I
get
what
you're
saying
it
would
be
interesting
to
to
actually
look
into
it.
How
we
can
adopt
this
rule.
This
validation
advantage.
A
C
Yeah
I
think
that
that's
definitely
going
to
be
the
difference
between
like
having
people
like
graphql
Java.
Adopt
the
rules
adopt
the
execution
would
be
the
difference
between,
like
the
pr
being
in
draft
and
whatever
the
third
stage
is
and
I
think
that
that's.
A
D
E
It's
worthwhile
to
just
treat
that
as
an
explicit
concern
to
run
to
ground
of
runtime
performance
effects
of
the
validation
steps,
because
I
think
there's
two
genres
of
that,
one
of
which
is
typical
usage
and
I.
Think
we
have
a
hypothesis
that
the
way
in
which
we
expect
most
people
to
use
this
well
theoretically,
could
create
a
performance
concern
in
practice.
E
Very
likely,
won't
but
I
think
there's
another
genre,
which
is
like
an
attack
surface
like
could
you
imagine
we
could
already
kind
of
dream
up
scenarios
where
people
write,
degenerate,
query
text
that
causes
validation,
performance
issues,
and
does
this
create
a
new
category
of
those
things?
If,
if
done
in
a
malicious
way
and
I
suspect,
the
answer
is
like
there's
an
upper
limit.
That
is
reasonable.
E
E
Sweet
anything
else
we
should
talk
about
today.
B
I'm
not
sure
what
you
need
to
do
to
put
like
suggest
actual
agenda
items
in
the
future.
Do
you
just
make
a
change
to
like
a
pull
request
to
the
agenda
with
the
agenda
items
you
want
to
add:
okay,
cool
I'm,
curious
about
having
more
discussion
around
fragment,
modularity
I.
B
Think
the
fragment
arguments
are
amazing
and
I
know
that
Matt,
like
you
guys,
have
been
really
excited
about
fragment,
modularity
and
I
kind
of
like
was
really
negative
about
a
lot
of
the
specific
ideas
you
had
in
the
past
there
or
critical
of
I
think
this
is
an
amazing
step
in
the
right
direction,
and
I
am
really
interested
in
considering
more
options
for
how
we
can
make
fragments
more
modular.
I
see
a
lot
of
value
in
doing
it.
B
I
have
for
a
long
time
that
I
I
still
think
that,
like
some
of
the
issues
around,
how
that
affects
response,
format
and
duplication
of
data
and
stuff
need
to
be
addressed,
but
I,
definitely
not
a
full-on
agenda
item
per
day,
but
I
I
think
we
should
really
continue
along
this
train
of
thought
and
and
put
more
effort
into
more
features.
We
can
do
to
make
fragment
modularization
a
better
experience.
One.
C
Thing
one
thing
just
to
be
aware
of,
because
I'm
also
like
being
part
of
the
defer
stream
work.
You
like
sessions
that
we're
having
it
does
sound
like
both
the
fur
and
stream
and
fragment
arguments,
are
kind
of
hitting
like
hitting
a
need
for
some
way
to
allow
duplication
of
like
fragments
within
a
response.
C
Basically
the
same
way
that
we
do
it
for
Fields,
because,
like
just
because
you,
you
can
have
the
same
field
with
different
arguments.
That
ends
up
producing
the
same
object,
and
we
will
just
duplicate
that.
We.
B
C
Yeah
so
that'll
be
like
figuring
that
out,
because
I
know
with
defer,
we
originally
had
labels
which
basically
produced
Mo,
produced
duplicated
duplicated
patches.
C
Similarly,
with
fragmentards
like
right
now,
the
validation
just
yells
at
you
and
is
like
you,
have
two
fragment
spreads
with
different
arguments
passed
in.
You
have
to
solve
this,
whereas
with
Fields,
when
we
hit
that
issue,
we
say
Alias
one
of
these
fields
right.
B
And
there
really
is
no
solution
for
this
without
some
sort
of
fragment,
modularization,
I,
agree,
yeah,
I,
I
think
that
the
the
challenge
there
is
trying
to
find
a
solution
that
identifies
where
the
actual
non-duplicated
the
data
that
will
be
different
based
on
different
fragments,
is
and
separating
that
out
from
all
of
the
fields
that
should
be
actually
merged.
Most
of
the
time,
if
you
have
a
fragment
that
has
some
different,
you
know
some
different
data.
B
You
still
end
up
having
a
bunch
of
fields
on
it
that
are
going
to
be
the
same,
and
how
can
we
expose
that
in
a
way
that
is
reasonable,
I'm,
not
sure
what
the
answer
is,
but
I
definitely
want
to
keep
working
on
this
stuff.
So
if
you
ever
want
to
get
together
with,
if
you
have
ideas
or
you
want
to
brainstorm
other
things,
there
are
people
at
Apollo
who
are
interested
in
making
this
happen
makes.
E
Awesome
we
will
wrap
a
little
bit
early
thanks.
Everyone
for
the
good
discussion.
E
I'll
use
some
of
the
remaining
time
left
in
our
time
block
to
get
that
licensing
stuff
put
together
for
graphical
scalers,
see
y'all
in
the
next
meeting,
which
should
be
I,
got
the
next
one
I
think
next
week
and
then
the
full
one
after
that
and
for
the
Australian
folks
next
time
next
month.
Talk
to
you
then
bye.