►
From YouTube: GraphQL.js Working Group - 2021-11-24
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).
C
B
C
Yeah,
I
think
we
can
start,
especially
since
introduction
is.
C
C
C
A
D
C
And
don't
forget
to
add
yourself
into
agenda,
it's
like
simply.
You
can
hear
some
more
cars
from
rope
and
other
changes.
Just
add
your
name
and,
and
I
stand
into
chat
yeah
so
probably
next
to
introducing
ourselves.
C
Yeah,
so
next
thing
is
review
agenda.
I
think
we
have
like
reach
a
parked
agenda.
I
corrected
a
little
bit.
It
was
some
formatting
issues
and
actually
we
have
only
10
items
because
previously
it
was
like
15
or
something
because
martin
was
surrendered
differently.
C
B
C
So
first
item
is
for
me
it's
about
reviewer,
team,
yeah
and
last
time
I
promised
to
to
create
a
document
describing
it.
C
I
had
some
like
personal
issues,
but
just
before
this
call,
I,
like
I
wrote
text
that
we
discussed
and
I
think
it's
much
I
posted
on
a
chat
I
wanted
to
update
agenda.
I
will
update
it
afterwards
with
the
link
to
this
issue.
Basically,
it's
just
describe
what
we
agreed
on
yeah
and
that's
some
like
numbers
yeah.
C
One
yeah,
I
think
I
can
just
go
through
it,
so
I
can
describe
the
goal
and
you
can
open
it
and
read
and
par
or
I
can
share.
Actually
I
can
share
a
screen
to
go
faster.
So,
let's
let
me
share
and
discuss
it.
Yeah.
B
C
A
go
described
by
the
why
we
start
with
initiative
and
let's
have
a
scope
as
we
discussed
it's
experiment
and
we
want
to
check
if
it
works
or
not,
and
it's
based
on
actual
metrics
and
do
we
have
like
stacked
pr
by
stacked,
meaning
like
nobody
reviewing
them
and
also
as
we
discussed
it's
like
a
temporary
measure.
That's
why
it's
like
a
issue.
It's
not
a
document
inside
the
repo.
C
I
think
we
have
like
extensive
discussion
last
time
and
by
the
way,
if
you
have
question
about
when
we
move
through
a
document.
If
you
have
questions,
you
can
stop
me
and
we
can
discuss
it
so
also.
There
is
expectation
from
from
membership.
Reviewing
team,
so
they're
not
expected
to
review
everything
they
expected
previous
stuff
that
they
specifically
been
gone
and
it's
cool
because,
like
we
have
with
with
github,
we
can
actually
bring
the.
B
C
Book
yeah
and
anybody
can
add
this
with
pink,
so
they
can
also
review
anything.
They
want
it
just
like
they
expected
to
provide
feedback
on
stuff
that
they
specifically
tucked
on
yeah
and
since
people
have
day
job
and
not
everybody
actually
paid
to
to
do
it.
So
I
can
work
time,
so
we
need
to
manage
the
time
effectively
and
basically
use
only
if
we
are
stuck
to
unblock
it.
What
was
the
purpose
of
this
with
process?
So,
let's
understand
everybody
most
happy
with
how
like
bears
that
get
match
get
much.
C
The
problem
was
that
some
pr
has
stopped
and
as
we
discussed
there
is
a
major
procedure
specifically
exclude
spec
proposals,
because
first
they
like
should
be
review
really
thoroughly,
and
second
thing
is
right:
pr
into
graphql
js
merged
before
changes
merchant
to
spec,
so
people
from
my
working
group
expected
to
review
them
so
by
proposal,
and
I
think,
as
we
discussed
on
previous
meetings,
main
concern
was
not
about
proposals
but,
like
other
players,
also,
its
usually
spec
proposals
is
not
proposed
by
first
time
contributors
or
proposed
by
yeah.
C
So
I
specifically
excluded
and
yeah
rules
that
we
discuss.
Two
members,
two
weeks
from
last
non-trivial
change
not
from
what's
approved,
but
from
time
the
person
changed
something
lost.
It's
prevent
a
situation
when
pinpoint
when
one
reviewer
say
one
thing
another.
We
were
required
another
thing
and
like
we're
in
situations
that
technically
parents
approved
but
yeah.
Nobody
like
people
didn't
read
the
last
version
and
one
week
since
review
comments.
C
Result
it's
give
white
people
time
to
if
you
press
resolve,
but
I'm
personally
disagree
for
example
it's
my
comment
and
I'm
disagreed,
give
me
time
to
say
I
can't
disagree
and
achieve
an
issue.
I
think
one
week
is
enough
to
provide
thing
to
keep
in
mind.
It's
like
also
include
the
fact
that
people
have
like
different
working
schedules
and
can
review
stuff
and
they're
like
on
weekends.
Not
everybody
get
paid
for
doing
that
stuff,
so
yeah
overview
commands
address.
We
have
here
for
that
it
should
work.
C
B
C
Yeah,
I
need
to
figure
it
out.
I
I
tried,
I
think
I
think
I
checked
and
it's
public
some
and
sorry
somebody
calling
me
a
second
time,
so
I
think
it's
something
important.
I
will
take
it
for
me.
C
A
C
Sounds
good
one
one
thing
so
I'm
I
manage
expectations
from
myself
and
as
we
discuss,
the
whole
idea
is
to
distribute
work.
If,
if
you
want
to
volunteer
to
do
it
to
manage
what
board
okay
yeah,
you
can
create
it
and
post
a
post
command.
Saying
like
let's
coordinate
on
what
yeah
yeah.
C
So
yeah,
by
the
way,
also,
if
you,
if
you
want,
if
you
see
like
any
pair
stacked
and
like
48
hours,
feel
free
to
ping
like
the
entire
team,
it's
not
only
like
they
are
after
it's
like
you
can
do
it
like
yourself,
so
don't
block
it.
C
I
need
to
return
the
agenda
second,
so
if,
if
I
remove
correctly
next
item
was
from
yosaka
all
right.
A
Yeah
release
schedule
so
now
we
have
released
v16
after
almost
a
year
or
so
so
what
so?
This
is
about
like
setting
up
canary
releases.
I
think
we
discussed
last
time
a
little
bit
on
this
topic
that
we
need.
Can
we
releases
and
automatic
automated
automated
version
bumps
on
releases
so
having
setting
up
change,
sucks
or
something,
and
I
think
you
open
up
something
in
graphqlgs
right
before
it.
So
yes,
so
if
I
understand
it
correctly
each
time
so,
each
time
you
merge
a
pull
request
to
main
will
release
that
branch.
C
Yeah,
I
think
we
need
to
look
to
first,
we
it's
like
depends
on
how
painful
wait
if
release
have
any
consequences.
Ideally,
we
don't
need
to
change
anything
in
git
history.
So
if,
if
you
don't
need
to
change
anything
and
give
history,
we
can
technically
release
like
because,
if
we
create
commit
for
every
every
battery.
C
C
A
Maybe
I
think
yeah,
if
you
have
depend
about
if
you
open
like
well
at
least
for
renovate,
but
we
use
it.
So
I
you
know
so
how
that
works
is
if
it,
if,
if
you
have
a
bump
like
if
you
even
if
it's
multiple
time
it
will
take
care
of
it
like
updating
to
the
latest
one.
So
if
you
haven't
up,
if
you
haven't
merged
that
dependency,
update,
you'll
only
get
the
latest
one.
So
let's
say
we.
A
C
Yeah,
I
think
we
can
figure
out
it
like
when
we
address
all
the
issues
we
can
before
doing
that
we
can
figure
out.
What's
the
easiest
path
and
also
I
don't
like
like
when
you
look
at
releases
in
github
yeah,
it
will
have
like
a
bunch
of
releases
with
one
entry
and
we
use
releases
as
changework.
Basically,
so
I
think
like
I'm.
A
Sometimes,
like
it's
a
rare
occasion,
that's,
I
think,
that's
fine.
If
we
hit
into
a
problem
in
the
future
where
we
are
merging
like
15
times
a
day,
then
maybe
yes,
but
if
you're
only
going
to
merge
like
once
or
twice
a
week,
I
don't.
I
don't
see
any
issues
merging
on
every
polar
class.
C
It's
not
like
third
party
appears
yeah,
I
think
like.
C
Yeah-
and
you
know
one
thing-
I'm
like
totally
think
it's
like
totally
critical-
is
to
have
releases
that
don't
change
in
get
history
before
we
need
to
address,
like
version
ts
things
and
packages
and
figure
out
how
to
do
releases
either
by
tooling
or
wrote
our
own
scripts
figure
out
what
would
work
and
also
doc
sites
dioxide
the
whole
canary.
There
is
ideas
based
on
that.
We
switch
to
unstable
mind
and
what
mean
like.
We
need
to
provide
some
docs
for
stable
version.
C
A
Yeah
so
with
the
docusource,
that's
simple,
because
you
can
have
a
next
version
of
docs
and
then
you
have
like
a
released
version.
So
when
we
release
like
let's
say
16.1,
you
release
the
docs
with
the
16.1
tag
and
then
docusource
manages
the
versioning
for
you.
So
that's
not
an
issue
yeah
one
thing
we
discussed
it's.
C
One
one
thing
we
discussed
previously,
I'm
like
for
canary
release
in
combination
with
is
unstable
mine.
So
basically
we
switch
to
1700
alpha
one
and
start
working
like
on
d4,
another
experimental
features
and
do
like
some
point
breaking
and
yeah.
So
before
doing
that
to
simplify
like
matching
stuff
back
and
forth,
I
want
to
match
your
dock
pair.
Basically.
A
C
A
Okay,
because
yeah
I
forgot
to
put
this
in,
but
the
third
point
for
the
release
would
be
like
experimental
branches,
because
right
now,
it's
it's
only
you
who
can
like
release
your
experimental
branch
yeah.
So
ideas
like
automated
way
whenever,
like
someone
pushes
to
that
experimental
branch
that
it
gets
published,
so
we
don't
have
to
like.
Yes.
C
B
C
Yeah
or
if
we
plan
a
big
release
like,
for
example,
we
plan
releasing
1700,
we
can
just
snapshot
like
branch
out
main
and
stabilize
it,
meaning
create
release.
Candidates,
ask
people
to
test,
and
everything
goes
very
little,
so
back
porting
things
and
branching
out
table
releases
and
actually,
on
this
point
it's
not
an
agenda,
but
maybe
it's
an
agenda.
You
had
that
another
item,
a
second
one
about
yeah,
not
automatic
releases.
C
I
wanted
to
take
this
opportunity
and
discuss
release.
I
think
it's
called
risk
maintenance
in
many
projects,
so
some
somebody
who's
responsible
for
for
bug,
porting,
not
backpacking,
to
review,
bug,
ported
stuff
and,
like
figure
out
what
what's
breaking
change,
what
not
breaking
change.
What
can
be
marched
backwards?
C
What
cannot
so
I
wanted
to
ask
if
you're
interested,
if
you
want
your
it's
like
a
part
of
responsibility,
I
can
shift
basically
to
use
a
hedge
be
responsible
for
for,
like
15
and
16
releases,
once
we
branch
out
main
to
be
unstable,
because
I
think
it's
too
much
context
to
keep
and
head
in
in
my
head.
What's
contact
happening
on
mine
and,
what's
going
into
other
branches,
are
you
interested
in
something
like
that.
A
C
In
the
releases
since
we're
like
always
go,
I
don't
want
to
make
like
everything
super
automatic
one.
It's
like
the
more
automatization
the
scary
scariest.
It
is
to
to
do
releases
unstable.
I
don't
care
if,
like
really
script,
is
not
working
on
alpha
releases,
but
it's
problematic.
If
you
break
people,
maybe
with
the
time
we
figure
out
automation,
but
now
I
prefer,
like
a
person
being
responsible
for
cutting
releases,
and
it's
like.
C
A
C
C
C
So
I
think
we
can
agree
that
the
last
stable
version
should
be
supported,
so
mean
quite
16
and
everything
else
based.
If
we
have
volunteers
to
do
what
work
or
not.
A
C
C
currently
currently
suggestions
that
we
have
it's
like
14
was
released
like
three
years
ago,
so,
two
or
three
years
ago.
So
people
still
use
it
because,
like
some
old
packages
use
it
so
yeah,
my
position
is
the
same.
If,
if
person
is.
C
And
also
it's
per
case
basis,
so
it's
like
really
bad
security
vulnerability
if
it's
like
really
bad
cv,
meaning
like
data
leak
or
something
like
remote
code
execution.
E
For
the
canary
releases,
so
we
would
switch
main
to
17
alpha
and
then,
after
that
figure
out
how
to
automate
the
the
publishes.
The
publishing.
C
Make
all
non-breaking
changes
in
16
to
hawaii
potentially
like
in
future?
Maybe
we
can
do
automatic
releases
on
16
just
for
what
reason,
if
possible,
to
make
changes
before
switching,
if
not
possible,
with
the
required
breaking
change
or
anything
else
after,
but
it's
technicalities
basically
yeah
you're
right.
C
What
people
usually
do
is
like
have
everything
on
unstable
versions
and
if,
if
the
desired
feature
is
not
ready,
they
branch
out
and
just
remove
that
feature.
What
way
it's
like.
You
don't
need
to
constantly
replace
its
way
and
you
don't
need
to
constantly
release
like
every
release
into
two
versions.
C
E
But
the
I
guess
I
guess
what
I
was
asking
was
the
automatic
publishing
nightly
or
publishing
on
every
commit
on
unstable
the
canary
releases
like
that,
doesn't
need
to
be
tied
like
we
don't
need
to
have
that
working
before
we
start
doing
the
unstable
vein
or.
C
Yeah,
maybe
like
idea,
if
we
can
do
it,
let's
do
it
based
on
how
much
time
we
want
to
spend
on
it.
So,
let's
too
quick
random
day,
tuesday
next
week,
if
by
tuesday
next
week,
we
figure
out
how
to
do
like
some
stuff
and
do
the
commentation
website
will
basically
like
on
wednesday
next
week
will
branch
out
1700,
even
if
something
happened,
we
can
fix
it
on
1
116..
C
C
C
Yeah,
so
it's
actually
an
item
for
this
meeting
in
one
week
to
switch
to
unstable
mine.
Basically
it
will
be
16
and
we
can
remove
duplicate
stuff
and.
D
C
By
the
way
like
about
394
ideas
that
some
stuff,
then
it's
not
breaking
correct
support
for,
I
think
iteratables
if
happen
in
16.
If
not,
it's
happened,
just
a
17,
but
it's
not
like
ipa
changes,
nothing
same
with
like
your
your
perform
benchmark,
it
can
run
in
16.
So
it's
like
yeah,
but
the
idea
is
that
next
week
we
switch
anything
else
from
europe
or
anybody
else
on
that
topic
before
we
switch.
A
C
C
Having
a
power
client
not
supporting
a
new
release,
but
since
a
power
client
is
figure
out
brian,
I
think
figure
out
how
to
deal
with
it.
So
it's
not
working
anymore.
It's
still
important,
but
it's
not
working
anything
as
far
as
I
know
so,
let's
experiment
with
it
on
canary
releases
it's
safer
because,
like
we
can
release
something,
people
can
try,
it
can
try
for
multiple
months
on
different
releases
and
yeah,
okay,
which
this
is
my
suggestion
for
a
timeline
because
I'm
like
I,
I
recognize
the
problem.
C
C
And
it's
also
a
pretty
weird
one:
since
we
remove
language
construct,
we
use
typescript
synonyms
and
we
switch
from
them
but
yeah.
I
agree
with
arguments
in
that
issue
actually,
like.
I
think
that
I
wanted
to
complete
before
with
call.
I
was
writing
a
comment
describing
my
understanding
on
the
situation
and
action
steps
to
do.
I
think,
like
one
thing
we
need,
is
to
write
right
like
plan
on
that
issue.
So
it's
not
like
stuck,
and
I
will
finish
it
up
and
post
and
another
thing
in
that
comment.
C
Orta
is
member
of
typescript
team
and
north
have
a
knowledge
of
rafiel
and
I
think
even
garakil
jazz,
so
he'll
have
a
contact
and
if
he
available,
I
don't
know
like
his
ability,
because
it's
like
fenty
thank
giving
yes,
but
I
like
him
to
comment
and
because
I'm
not
typescript
expert-
and
I
think
graphql.js
is
pretty
big
project,
so
we
can
ask
typescript
team
at
least
somebody
from
a
typescript
team,
at
least
like
comment
and
suggest
what
what
what
the
proper
solution
that
situation
can
be.
A
So
so
we
have
two
options
right
now.
I
think
previously
we
have
discussed
in
this
working
group
that
in
v17
we
can
take
a
radical
approach
of
just
abandoning
cjs
and
only
support
esm.
That's
one
way,
the
other
way.
I
think
this
was
discussed
on
pull
requests
that
we
can.
We
we
can
publish
a
graphql
dash
esm
package
to
npm,
so
we
can
have
a
graphql
package
that
we
publish
normally
and
then
your
graphql
esm
package
esm
only
so
so,
which
way
like
how
should
we
begin
like?
A
Which
way
should
we
go
with,
because
we
have
some
like?
We
have
pull
requests
ready
for
both
ways
currently
and
how
well
not
for
the
esm,
only
one,
but
just
the
esm
package
and,
like
I
think,
the
previous
one
that
pablo
opened
was
closed
because
the
issue
was
like
having
two
instances.
That
instance
of
issues
so
maybe
is
maybe
we
should
just
fix
that
instance
of
issue
all
together,
because
I
was
trying
this
on
dino
and
like
on
dino.
We
have
that
issue
where
we
can't
really
like.
C
I
think
at
this
point
like
we
discussed
it
like
five
times
so
problem
is
not
mechanism
itself
problems
that,
since
speed
dependency
like
we
cannot
have
like,
if,
if
you
create
a
schema
with
one
version
of
graphql
js
and
pass
it
to
another
version
of
graphql
js,
even
if
we
figure
out
instance
of
it's
like
schemas,
are
not
compatible
like
with
execute
expect
like
some
new
method
in
graphql
schema.
So
it's
a
thing
like
instance,
even
even
if
we
disable
instance
of
if
we
have
like
duplicating.
C
C
We
have
like
a
break
constant
and
by
if
you
use
break
from
one
package
and
visit
from
another
package,
it's
not
working
together,
so
instance
off
with
a
symptom.
It's
not
problem
so
how
to
make
it
work
with
dinner.
Yeah!
It's
another
issue,
you
know
doesn't
have
this
issue
and
you
know
you
don't
have
like
good
dependencies.
C
So
basically,
instanceof
was
a
mechanism
for
not.
We
need
to
figure
out
like
if
we
need
it
into
india
or
not,
but
we
cannot
remove
it
on
npm,
like
it's
solving
real
issue
and
npm,
and
if
you
can
get
history,
lee
added
it
on
purpose,
with
like
description,
why
he
added
it?
C
A
C
Yeah
but
you're,
not
passing
versions
between
version
tiers
between
models
like
if
you
have
dependency,
creating
something
I
think
we
can
take
it
offline,
and
maybe
it's
even
worse.
So
I
can
explain
you
and
if
you're
interested,
you
can
write
a
book
article
or,
like
I
don't
know,
like
some
design
document,
why
we
have
it,
and
I
will
explain
it
to
you
and
we
try
to
document
it
because
we
have
a
constantly
but
think
why
it's
important.
I
think
it
will
be
effect
more
effective.
C
If
I
show
you
code
samples
and
explain
what
happens
so
yeah
one
story
short.
Basically,
we
cannot,
even
even
if
we
remove
instance,
of
check
completely
current
mechanism
it
we
will
still
have
like
problems
in
npm
in
not
basically
like
with
duplicating
pain
packages.
A
C
One
size
for
for
front-end
bundle
size.
Another
issue.
One
issue
is
compatible
between
different
version
and
another
issue.
If
you
have,
if
you
build
make
build
for
front
end,
you
will
have
duplicating
like,
like
all
the
code,
duplicated
twice.
F
But
isn't
that
isn't
that
an
issue
with
basically
any
javascript
library?
I
mean
it
sounds
a
bit
like
we're
protecting
something
that
is,
you
know
just
something
in
the
javascript
ecosystem
and
I
think
and
we're
preventing
basically
something
that
every
javascript
library,
like
every
user
of
javascript
needs
to
handle,
like
I
I
know,
is
that.
Are
there
other
other
libraries
that
use
the
same
mechanism.
C
Yeah,
what's
what
what
I'm
interesting?
It's
not
a
problem.
It's
a
promo
specifically
with
spirit
dependencies.
So
with
the
library
that
appear
dependency,
I
think
react
is
not
providing
esm
like
for
what
reason
and
what
I
like
actually
wanted
to
see
what
react
is
doing,
and
they
still
don't
have
some
support.
C
If,
if
you
find
any
pertepana's
popular
peer
dependency
library
that
do
any
some
support,
I
will
be
like
very
interesting
to
see
how
they
implemented,
because,
like
so
it's
like
two
separate
problems,
instance
of
and
we're
having
different
version
and
like
mechanism
for
providing
different
version
and
duplicating
I'm,
I'm
like
open
to
suggestion.
I
actually
think
like
bubble
approach.
C
Bubbles
approach
with
like
separate
release
can
work
it
just
like
I'm
for
testing
it.
I'm
like
want
to
be
sure
that
when
we
do
something
when
we
release
new
version
of
cgs
and
dsm
packages,
they
both
work
together
or
like
they
both
work
in
different
scenarios.
C
C
A
Two
packets
isn't
an
issue.
The
issue
is
like
now
like:
how
do
you
get
the
users
to
use
it
properly?
Is
the
other
thing
we
need
to
see
because
we
can
publish
two
packages
for
like
what
if
someone
uses
the
esm
package
and,
on
the
other
hand,
they're
using
a
cgs
package,
will
that
have
any
issues
like.
C
F
C
Yeah,
we
can
add
like
dot
asm
and
it's
compatible.
So
basically,
if
somebody
somebody
is
says,
like
the
support
section,
zero,
zero,
they
support
like
peer
dependency,
allow
you
to
plug
esm,
you
don't
need!
Basically
you
don't
need.
C
A
Yeah
we
should
have
that
instance
of
issue
resolved.
I
think
because,
like
I
mean
personally,
I
wouldn't
prefer
to
like
have
like
install
those
different
packages.
It's
just
like
add.
Yes,
I'm
something
that
that,
just
like
experience
wise,
I
don't
like
okay,
it
will
solve
the
problem,
but
I
like
it's
it's
overhead
for
the
user
like
it's
not
just
for
us,
but
as
a
user
too,
like
if.
B
C
Thing,
I
think,
what
what
proven
to
be
working
in
the
case
of
of
previous
discussion
when
pablo
wanted
to
just
switch
to
esm-
and
I
explained
him
why
not?
And
he
changed
like
approach.
I
think
we
can
try
the
same.
We
can
either
do
it
asynchronously
or
something,
and
I
can
explain
and
make
an
easy
document
to
figure
out
like
because
instance
of
issue
is
more
complicated
and
I
feel
like.
A
C
No,
like
actually
like
problem,
is
opposite
instance
of.
Is
it's
not
solution
for
for,
like
duplicate?
It's
like
solution,
for
you
have
a
different
version,
a
new
dependency
3,
which
is
incompatible.
You
cannot
parse
parse,
query.
A
C
A
A
C
A
C
C
Another
punch
and
visit
function
compare
like
return
with
a
break
and
if
it's
equal,
when
it's
like
break,
if
it's
not
equal,
it's
like
do
it's
like
replace.
So,
basically,
every
event
I
think,
is
working
based
on
graph.
Graphql
js
expose
export
constant
and
you
can
return
in
your
call,
but
you
can
return
that
cons
because.
A
C
C
C
C
C
C
C
Yeah
I
have
like
we
discussed
that
synchronously.
I
have
like
some
some
stuff
that
I
tried
locally
yeah
like
bubble
parser,
for
example,
you
can
remove
it,
you
don't
need
it
and
some
other
way.
I
figure
out
a
way
how
to
change
output
directory,
basically,
how
I
have
have
done
pr
and
yeah.
Let's,
let's
do
the
same
thing.
We
we
discuss
with
rope
so
like
I'm,
I'm
like
thinking
about
new
approach,
which
means
like
instead
of
having,
especially
for
things
that
don't
change
spec
and
it's
not
public
api.
C
A
C
Yeah,
I
think
we
can.
We
can
write
writing
miles
a
mile,
and
this
I
think
we
can
ask
even
better
if
we
we
do
it
for
ricky.
I
think
ricky
have
like
their
whole
credentials
and
everything
for
doing
so.
Maybe
it's
better
to
just
like
yeah,
to
schedule
to
schedule
like
a
call
with
rick
and
do
it
in
one
hour
and
not
having
like
back
and
forth.
C
I'm
not
a
nightlife
expert,
and
I
didn't
do
it
so
like
I
trust.
If
we
have
time
enough
time
to
do
it,
we
can
ask
him
to
help.
A
Okay,
because
the
other
part
I
have
on
that
regent
item
is
so
now,
once
we
have
the
docs
site
in,
we
need
like.
We
need
a
way
to
get
tutorials
in
and
like
more
documentation,
and
so
we
need
like
a
minimum
bar
that
someone
can
just
merge
those
in
like
because
we
don't
want
to
wait
for
like
three
months
to
get
like
a
tutorial
that
seems
uncomfortable.
A
A
A
C
Yeah,
like
quadrant,
do
you
mean,
do
you
mean
like
used
directly
for
a
quadrant.
A
Like
well
so
graphql
gs
can
be
used
in
different
scenarios
right,
not
just
like
making
servers
or
like
that.
Like
just
client-side
things,
you
can
do
like
cool
things
with
it,
like
people
can
have
like
stitching
examples
or
federation
examples,
which
is
something
like
you
can
do
with
graphql
js.
Plainly,
I
mean
modifying
the
functions
right
so
like
having
sort
of
advanced
guides
in
tutorials.
I
think.
A
F
No,
but
that's
that's
not
the
case
anymore,
I
think
now.
If
there's
something
waiting,
I
can,
I
can
merge
it
there.
Oh.
C
D
C
Like
code
is,
is
the
actual
first
thing
it's
like
on
the
main
side,
so
it
have
bigger
visibility.
It's
not
sub
domain,
it's
like
command
side
yeah,
but
when
it's
like
like
duplicating
stuff.
So
if,
if
you
have
like,
I
don't
know,
graphql
helix,
for
example,
yeah
you
create
tutorial
like
and
you
want,
like
people
can
post
from
graphql.org
for
different
reasons
like
visibility,
search
engine
optimization
like
anything
like
it
was
there
in
the
code
and
you
also
post
to
graphql
js.
A
F
Are
we
talking
so
we're
talking,
there's
the
just
to
get
so
I
get
the
context.
So
today,
there's
like
a
graphql
js
tutorial
like
very
basic
on
how
to
write
like
a
simple
server
with
graphql
gs
on
like
a
sub
domain
that
is
unreachable
on
graphql.org.
F
What
now
you're,
building
sahaja
yogi,
if
you
understand
correctly,
is
like
a
documentation
website
for
graphql
gs
right.
Yes,
so
I
think
that
it
makes
sense
to,
in
my
opinion,
it
makes
sense
to
move
the
to
move
the
the
tutorial
into
the
graphql
gs,
because
what
you
see
what
you
just
linked,
the
graphql
dot
org
slash
code.
This
is
just
a
list
of
tools.
There's
it's
not
around
tutorials
and
each
each
tool
in
their
own
websites
contain
like
the
docs
and
a
simple
tutorial
of
getting
started.
F
What's
exist
on
the
subdomain
on
graphical.org
for
graphql
gs
tutorial.
It's
like
a
simple
tutorial.
I
think
in
my
opinion,
we
should
put
it
on
graphql
on
the
graphql
gs
website
for
visibility,
and
this
tutorial
should
stay
simple.
I
mean,
I
think
it's
a
good
tutorial
overall,
I
remember
I've
done
it
a
couple
of
years
ago.
It's
a
good
tutorial,
a
simple
tutorial:
it
gets
you
like
get
started
easily
and
you
understand
the
core
basics,
which
I
think
is
important
and
then,
at
the
end
of
the
tutorial,
we
could
tell
people.
F
So
this
is
like
playing
graphql.
Yes,
there's
all
kinds
of
like
higher
level
tools
and
frameworks,
and
then
we
could
link
them
into
the
graphql.org
code
to
find
all
the
different
alternatives
that
are
ordered
there.
But
I
think
it's
good
for
beginners
or
learners
to
actually
look
at
the
core
library
and
how
to
build
something
basic
with
it.
And
then
you
know
start
with
whatever
framework
you
want
to
choose.
F
It's
a
good
guy,
I
don't
know
if
it's
we
need
to
maintain
it
inside
the
graphql
gs
website.
I
think
it
will
be
like.
I
think
what
you're
saying
is
a
good
point
like
if
we're
gonna
start
maintaining
like
tutorials
for
all
the
different
javascript
frameworks
and
all
their
versions.
I
think
it's
gonna
be
hard.
I
think
it's
better
for
to
have
a
good
starting
point
like
very
basic
thing,
just
the
basically
the
same
tutorial
that
exists
on
raphael.org,
but
nobody
has
access
to.
F
Nobody
can
reach
to
and
put
it
on,
graphql
gs,
because
it
makes
sense
and
then
just
from
that,
the
end
of
this
tutorial
just
to
like
link
back
to
graphql.org,
slash
code,
and
then
people
could
just
choose
whatever
library
they
want
and
use.
The
tutorial
on
their
libraries,
like
helix,
will
have
a
tutorial.
Apollo
server
has
a
tutorial
like
yeah
yeah.
C
One
thing
we
can
do
in
this
suggestion:
maybe
you
can
do
it
on
graphql
dot
work
in
what
section
is
to
have
like
attacks,
so
like
some
of
the
tools
like
graphql
shield
is
not
starting
point.
It's
like
things
that
you
use
afterwards,
so
maybe.
F
So
in
graphql.org
code,
it's
divided
so
for
each
language,
first
of
all,
it's
divided
by
languages
and
then
for
each
language.
You
have
client
server
and
tools,
so
you
have
so
basically
what
what
we
can
do
in
the
end
of
at
the
end
of
the
graphical
js
tutorial
is
to
link
directly
to
org
graphql.org
javascript,
slash
server,
okay,
yeah.
So
then
it
will
be
exactly
to
you
know.
C
I
didn't
show
it
yeah
and
all
the
servers
provide
you
easy
to
start.
Example:
tutorials,
it's
like
yeah.
So
what
thing
I
didn't,
so
you
actually
have
something.
F
C
F
F
I
agree
with
you
like
to
basically
separate
how
you
create
the
schema
and
how
you
execute
it,
but,
but
I
think
it's
still,
I
think
the
tutorial
that
is
on
the
graphql.org
on
the
unspecified
url
is
a
good
tutorial
for
the
basics.
I
think
it's
it's
not
necessarily
like
in
order
for
people
to
go
ahead
and
build
their
servers
with
plain
graphql
gs,
even
though
I
still
think
it's
a
it's
a
interesting
and
good
experience,
but
it's
it's
just
a
good
knowledge
of
the
core
library
and
then
that's.
F
C
F
C
F
F
F
You
know
create
the
wrong
assumption
and
it's
good
for
for
us
to
actually
show
that
it
kind
of
like
separated
right
like
show.
Okay,
this
is
our
use
graphql
and
then,
if
you
want
to
send
it
over
http,
you
know
use
whatever
you
want
and
you
know,
or
we
could
still
use
graphql,
it's
especially
raphael
and
then
just
add
a
sentence
around
it.
I
don't
know
we'll
see.
C
If
anybody
volunteers,
you
can
build
like
without
any
library,
it's
it's
a
fun
like
article
and
a
fun
like
advanced
tutorial
advanced,
like
example.
How
to
you
can
use
like
not
just
api
and
actually,
typically
from
it
and
build.
The
server
like
even
express
graphql
is
like,
like
less
than
1000
lines
of
code
with
everything
graphical
so.
F
C
Okay,
good
work,
so
it
was
the
last
topic.
I
think
there
is
anything
else
anyone
wants
to
discuss
before
before
next
working
group,
stuff
that
we
cannot
decide
asynchronously.
A
C
A
C
And
yep,
so
it
was
really
packed
agenda.
I
think
yeah
hour
and
20
minutes
and
we
had.
I
think
it
was
very
productive
and
we
have
like
agreed
on
action
items
and
like
stuff
that
we
need
to
do
like
next
week
and
before
next
working
group.
So
let's
focus
on
delivering
it
and.
C
Next,
next
working
group,
we
discuss
new
topics
and
also
action
action
items
of
this
one,
so
it
was
great.
It
was
great
working
group,
co
nc
in
one
month,
bye.