►
Description
Welcome & State of GraphQL - Lee Byron, GraphQL Foundation
A
Hey
everybody
welcome,
I'm
super
excited
to
be
here.
This
is
the
the
first
conference
I've
been
to
in
person
since
the
pandemic
started.
How
many
of
you
are
in
similar
boat
as
me,
a
lot
of
hands
all
right.
So
you
know
I've
been
feeling
like
weird
as
I've
been
seeing
this
many
humans
in
3d,
so
I'm
apologize.
If
I
come
off
as
like
weird
and
aloof,
it's
just
a
weird
new
world,
we're
finding
ourselves
in.
A
Let's
see
there
we
go,
I
have
something
else
to
say:
oh
yeah
yeah.
I
wanted
something
else
to
say.
This
is
also.
This
is
also
kind
of
a
special
conference.
This
is
the
first
conference
that
was
put
together,
bolts
and
nuts
by
the
graphql
foundation,
so
that's
actually
pretty
cool.
That
was
one
of
the
original
goals
of
creating
the
foundation
and
I'll
talk
a
bit
about
that
in
a
minute.
I
was
running
these
kind
of
open
and
neutral
events,
so
this
is
kind
of
the
first
example
of
that.
A
Obviously
we
we
started
in
a
rough
spot
in
forming
the
foundation
in
2019
and
2020
is
going
to
be
the
year
that
we're
going
to
start
our
event.
Strategy
didn't
really
work
out
so
anyway
welcome.
I
hope
this
goes
well
and
then
also
it's
pretty
cool
to
come
together.
I
don't
know
if
you
know
this,
but
graphql
turned
10
years
old
this
year,
which
is
pretty
wild,
so
I
guess
I've
been
kind
of
at
this
for
a
while.
It
makes
me
feel
a
little
bit
old,
but
I
feel
really
grateful.
A
You
know
I've
gotten
to
work
on
this
technology.
That's
had
a
pretty
interesting
impact,
a
lot
across
a
lot
of
people
and
a
really
long
time,
but
the
thing
I
feel
most
proud
about
is
sort
of
building
this
really
awesome
core
community
that
helps
make
graphql
great
many
of
which
are
here.
Thank
you
for
being
here.
I
know
many
others
are:
are
tuning
in
live
you're
going
to
get
to
hear
from
plenty
of
them
later
today,
so
I
won't
steal
their
thunder,
but
I
should
introduce
myself
for
those
of
you.
A
I
haven't
met
yet
my
name
is
lee.
I'm
one
of
the
creators
of
graphql
and
the
executive
director
of
the
graphql
foundation,
so
10
years
into
graphql.
I've
changed
a
fair
bit
myself,
so
this
is
actually
a
picture
of
me
back
in
2012
when
I
was
young
and
spry
working
at
facebook,
where,
along
with
dan
schaefer
and
nick
schrock,
put
together
the
first
version
of
graphql
after
many
many
long
nights.
A
This
is
something
a
little
bit
more
recent,
so
I
I've
aged
a
little
bit,
but
like
significantly
more
so
in
the
last
few
years,
because
I
got
I
got
a
family
and
these
two
very
busy
little
boys,
the
little
one
there
just
started
walking
so
I'm
in
for
it
I'm
in
for
it.
So
anyway,
I've
had
to
learn
to
be
kind
of
judicious
with
my
time
and
in
fact
that's
a
huge
reason
behind
why
I
started
the
graphical
foundation.
In
the
first
place,
it
was
kind
of
an
attempt
to
scale
myself.
A
But
I
have
some
news
here,
which
is
my
time
at
robinhood
is
actually
coming
to
an
end
pretty
soon
and
I'm
going
to
be
joining
this
new
company
called
watershed,
so
I'm
going
to
help
lead
their
product
engineering
team.
I'm
super
excited
about
this.
Many
of
you
probably
don't
haven't
heard
of
watershed.
My
hope
is
to
change
that
not
just
for
the
folks
in
the
room,
but
for
the
industry
wide
watershed
is
a
company
that
builds
tools
for
other
companies
to
measure
and
reduce
their
carbon
footprint.
A
So
I
actually
think
that
climate
change
is
going
to
be
the
most
critical
challenge
of
the
next
generation,
not
crypto,
but
climate
change,
and
so,
if
I've
learned
anything
from
my
engineering
career
so
far,
it's
that
you
can't
move
a
metric
that
you
don't
track
and
you
can't
move
it
very
fast
or
very
far
without
good
tools.
So
watershed
is
addressing
both
of
these
needs
to
help
companies
face
head-on
the
measurement
and
reduction
of
their
carbon
footprint,
and
we
need
to
grow
really
fast
to
do
that.
A
So
I'm
going
to
start
here
in
a
couple
of
weeks
and
if
this
mission
sounds
like
it
resonates
with
you
and
you
like,
graphql
and
typescript,
you
should
come
talk
to
me
because
we're
trying
to
find
the
best
web
engineers
we
can
find
so
we
can
grow
really
quickly.
Come
talk
to
me
or
drop
me
a
message
if
that
sounds
interesting
to
you,
but
anyway
enough
about
me
I'll
get
off
my
high
horse
before
we
get
into
the
deep
dive
talks
today
and
tomorrow.
A
So
I
thought
what
might
be
most
interesting
was
to
first
tell
the
story
of
the
initial
conditions
that
led
us
to
build
graphql
in
the
first
place,
and
that
was
facebook's
move
to
mobile,
so
facebook
was
actually
originally
built
for
the
web.
Didn't
have
any
mobile
component
and
actually
our
first
mobile
components
were
just
wrappers
around
our
website.
So
we
we
technically
had
ios
and
android
apps.
They
were
just
wrappers
around
our
mobile
website,
but
this
was
an
intentional
strategy.
A
You
know
we
really
bet
big
on
the
web
for
a
good
reason,
because
I
remember
when
steve
jobs
got
on
stage
to
introduce
the
iphone
back
in
2007
and
he
called
it
a
breakthrough
internet
communication
device
and
it's
got
safari
the
best
web
browser
in
the
world
and
it's
all
on
the
iphone.
It
was
like
literally
one
of
the
three
things
he
was
like.
It's
an
ipod,
we're
like
we
love
ipods
like
it's
a
phone.
A
It
was
like
apple
made,
a
phone
he's
like
and
it's
for
the
internet,
and
I
was
like
hell
yeah,
I'm
a
web
engineer.
This
is
going
to
be
awesome
and
then
the
next
year
google
was
like
okay,
you
all
heard
about
this
iphone
where's,
my
g
phone,
and
they
talked
about
this
whole
strategy
that
they
acquired
android
and
they're
gonna
be
rolling
this
out
and
I
was
like
yes,
this
is
great.
A
So
five
years
later,
apple
had
put
all
of
its
energy
into
native
apps
and
had
left
mobile
safari,
basically
to
rot.
It
was
years
behind
at
web
standards,
not
a
ton
of
bugs
google
hadn't
even
bothered.
They
watched
what
the
iphone
was
doing
and
they
just
like
didn't
even
put
chrome
on
android
for
years.
A
It's
called
your
s1
risks
and
one
of
the
very
first
ones
was
this
whole
thing
of
like
an
acknowledgement
about
the
whole
industry
shifting
to
mobile
and
how
facebook
had
like
no
answer
to
this,
and
this
could,
just
you
know,
totally
topple
the
company,
so
we
knew
we
were
in
trouble
and
failure
to
adjust
to
these
kind
of
major
shifts
in
the
past
has
definitely
crippled
and
killed
other
major
companies.
So
you
know
we
kind
of
understood
that
these
circumstances
were
not
academic.
A
They
were
not
theoretical,
they
were
very
real,
so
we
decided
to
build
news
feed,
which
is
the
very
first
thing
that
you
see
when
you
open
facebook,
as
a
native
ios
view,
backed
by
a
restful
api,
and
we
immediately
countered
some
issues,
so
it
was
slow.
We
had
to
coordinate
a
whole
host
of
network
requests
going
back
and
forth
to
make
up
news
feed
work,
and
this
was
in
an
era
where
3g
networks
were
were
the
key.
Not
5g
is
pretty
good.
A
3G
was
pretty
slow,
so
this
was
really
painful
and
they
were
also
really
fragile.
So,
okay
network
speeds
get
faster
over
time,
but
some
of
the
relationships
between
how
engineers
work
together,
they
don't
change
quite
as
fast
so
changes
to
the
api
needed
to
be
carefully
carried
over
to
client
code.
Otherwise,
the
app
would
just
crash.
This
would
happen.
A
lot
and
the
client-side
engineers
were
looking
at
the
api
documentation
and
was
like
that's
what
the
docs
say
and
it's
like
the
server
doesn't
actually
do
what
the
docs
say.
A
We
heard
all
about
that
from
rachel
earlier
very
real
problem,
and
it
was
also
very
tedious,
so
client
work
was
often
totally
blocked
and
deploying
new
changes
to
the
server
and
anytime.
The
api
needed
to
change
you'd
have
to
go
through
this
whole
sort
of
like
blocking
thing.
Where
oh
we
wanted
this
thing.
We
can't
get
started
until
the
server
ships,
their
new
thing
and
they're
not
ready.
Yet
it
was.
It
was
really
really
slow
to
get
stuff
done
so
anyway,
these
issues
in
mind.
A
A
A
It's
robust
rather
than
fragile,
because
you
describe
all
the
things
that
you
could
do
with
the
schema
and
then
clients
just
describe
the
subset
of
those
that
they
actually
need
to
populate
a
particular
view,
no
more,
no
less,
and
so
it's
pretty
resilient,
and
that
opens
up
this
whole
host
of
superpowers
that
these
days
we
kind
of
take
for
granted.
But
at
the
time,
are
a
huge
deal
like,
for
example,
static
analysis
locally.
A
You
can
tell
if
your
query
is
good
or
bad,
not
just
when
you
run
it,
but
before
you
even
check
it
in
so
you
could
do
things
like
linters
and
unit
tests
and
keep
code
that
breaks
things
out
of
master
fantastic
and
on
the
server.
You
could
make
sure
that
any
changes
to
your
types
are
statically
checked.
A
So
if
you
make
a
breaking
change,
then
similarly,
you
can
catch
that
before
you
check
it
in
or
at
least
if
you
decide
to
check
it
in
you
kind
of
know
what
you're
in
for
and
this
ends
up
being
really
empowering,
because
clients
are
describing
what
they
need,
and
that
means
that
they're
rarely
blocked
by
the
server,
and
this
means
that
graphql
apis
never
need
to
version.
So
we've
got
some
meta
folks
here
in
the
room.
A
They
can
check
me
if
I'm
wrong,
but
I'm
pretty
sure
that
this
means
that
a
decade
later,
facebook
meta
is
still
on
version.
One
of
its
graphql
api
technology's
evolved
a
lot,
but
it's
never
needed
to
like
major
bumper
version
so
pair
this
with
the
static
types
and
now
you
have
this
really
cool
platform
for
building
tools,
code
generation,
api
explorers,
ide
integration,
lots
of
really
awesome
stuff,
oops
one.
I
went
too
fast
on
my
errors.
There
documentation,
also
first
class
citizen.
A
We
heard
from
rachel
earlier
about
how
important
it
is
to
keep
your
documentation
up
to
date
with
your
implementation
and
we
baked
that
directly
into
the
type
system,
so
that
documentation
is
actually
available
in
code
and
so
co
code.
Generating
tools
can
actually
look
this
up
and
put
them
in
the
right
places,
and
it
was
actually
fairly
easy
to
adopt
because
in
the
first
couple
of
years,
graphql
out
there,
everyone
thought
it
was
some
new
database
language,
and
I
already
have
a
database,
don't
make
me
use
a
new
database.
A
It's
like
we're,
not
doing
databases,
it's
just
arbitrary
code.
Just
like
rest
api.
You
write
a
rest
api
endpoint,
you
just
query
arbitrary
code
underneath
that's
what
we're
doing
too,
and
this
was
great
because
it
meant
that
it
could
be
adopted.
Super
fast,
the
news
feed
team
took
up
the
the
first
version
of
graphql
very
quickly
and
it
spread
pretty
barely
across
the
rest
of
facebook
really
driven
by
product
engineers.
A
So
anyway,
towards
the
end
of
2012,
we
released
this
new
ios
app
powered
by
graphql
and
have
been
on
a
similar
path
ever
since
plenty
of
evolution
still
graph
code
under
the
hood.
So
at
the
same
time
the
group
is
working
on
another
project
that
was
react
and
the
next
year
at
js
conf,
we
open
source
react,
and
this
has
turned
into
of
course,
one
of
meta's
most
important,
open
source
projects
and
really
was
the
highlight
of
just
what
open
source
could
mean
to
the
company.
A
We
had
to
open
sourced
a
handful
of
things
before,
but
they
didn't
really
have
the
impact
this
had,
so
we
were
really
excited
and
a
little
bit
later,
a
couple
years
later,
some
of
my
teammates
gave
this
talk
at
a
react.js
conference.
Talking
about
relay
got
a
bunch
of
relay
folks
in
the
room,
and
this
was
the
very
first
time
we
talked
about
relay
publicly
and
it
brought
together
react
and
graphql.
A
The
audience
was
like
this
is
amazing:
are
you
going
to
open
source
if
you
can't
use
it?
It's
like
the
goal
is
not
like
yeah
we're
open
starting
to
sing
this
thing
today,
so
we
just
wanted
to
like
kind
of
talk
about
how
we
were
solving
this
data
fetching
problem,
but
we
were
so
inspired
by
the
reaction
that
we
got
there
like.
Maybe
we
should
open
source
relay.
That
would
be
great,
but
you
can't
really
open
source
relay
without
also
open
sourcing
graphql.
A
Does
it
even
make
sense
to
do
that
like
what
does
it
even
mean
to
open
source
graphql,
so
I'll
admit
like
I
was
actually
the
person
in
the
room
that
was
like?
No,
this
is
a
bad
idea.
I
don't
think
it
makes
any
sense.
I
was
pretty
skeptical,
I
don't
know
if
notable
companies
would
really
use
this
if
it
would
be
a
big
waste
of
time
and
also
it
wasn't
really
clear
what
it
would
even
mean
to
open
source
it,
because
graphql
is
just
a
bunch
of
php
code
like
interwoven
throughout
facebook's
core
systems.
A
So
maybe
we
could
extract
that
into
a
library,
but
even
if
we
did
we'd
end
up
with
a
php
library
and
there
weren't
a
ton
of
other
companies
using
php,
so
I'm
not
sure
that
that
would
gain
a
ton
of
traction.
But
anyway
we
decided
what
actually
made
graphql
great
was
the
idea,
the
the
interface
and
the
language
and
less
so
the
actual
specific
implementation.
A
So
we
wrote
a
specification
that
described
graphql
with
the
hope
that
this
would
lead
to
other
implementations
and
we
wrote
the
first
of
those
and
that
was
graphql
js,
which
we
hoped
would
get
a
little
bit
more
attraction
than
php.
I
think
that
was
a
fair
bet,
and
later
that
year
we
announced
graphql
as
an
open
source
project.
A
We
shared
the
specification
and
the
implementation
with
the
community
and
asked
them
to
hey,
read
it
read
this
back
and
if
this
is
interesting,
build
it
for
your
language
too,
and
by
the
end
of
that
year,
so
like
this
was,
I
think,
august
2015
and
three
months
later
there
were
already
six
major
projects
in
the
work
to
port
graphql
to
other
languages.
So
very
impressive,
and
today
I'm
pretty
sure
you
can
find
graphql
implemented
in
two
dozen
languages,
which
sounds
crazy.
A
That's
a
lot
like
are
there
even
that
many
languages
people
are
using
to
build
stuff.
Yes,
most
of
them
are
being
used
in
production
by
various
companies,
pretty
wild
and
the
graphical
community.
You
know
it
started
as
hobbyists.
A
lot
of
people
who
are
building
that
stuff
were
just
people
who
thought
this
was
cool,
but
very
quickly.
It
started
to
get
used
by
real
companies.
So
we
saw
early
adopters
like
the
new
york
times,
walmart
intuit,
airbnb,
netflix,
twitter,
amazon,
github
and
actually
a
bunch
more.
A
So
this
has
just
grown
and
grown
and
we
saw
our
community
really
grow.
So
I
grabbed
the
screenshot
from
from
meetup
a
couple
of
years
ago
and
it's
not
to
say
these
are
all
the
meetups
today.
This
was
like
in
2017..
These
were
the
amount
of
meetups
that
were
specifically
talking
about
graphql
and
some
cadence.
This
is
really
awesome
and
now
also
there's,
of
course,
many
graphql
specific
conferences
across
the
world,
not
just
this
one.
There
are
many.
Some
of
you
probably
been
to
a
couple
of
those.
A
So
frankly,
all
this
is
still
kind
of
incredible
to
me.
I'm
really
impressed
by
this
and
I'm
very
happy
to
say
that
my
early
skepticism
was
completely
unwarranted,
but
we
still
face
some
problems
so
turns
out.
You
know
we
had
filed
a
bunch
of
patents
back
around
the
very
beginning
of
the
graphql
project,
and
patent
office
takes
a
while
and
it's
a
black
box,
and
five
years
later
they
came
out,
be
like
hurrah.
A
Here's
your
patents
and
the
you
know:
open
source
community
loves
patents,
and-
and
meanwhile
you
know,
there's
this
whole
rigmarole
over
the
reactors
using
this
modified
bsd
license
and
a
bunch
of
people
were
pretty
grumpy
about
that
and
graphql
code
was
also
using
that
the
spec
itself,
just
like
didn't,
have
a
license.
I
think
technically
it
had
a
bsd
license,
doesn't
mean
anything
for
respect.
So,
just
in
this,
like
weird
spot,
we
started
getting
people
who
actually
knew
what
they
were
doing.
A
The
person
who
wrote
this
particular
article
is
a
copyright
lawyer,
so
he
knows
what
he's
talking
about
when
he
says
that
you
know
we're
not
doing
it
right.
So
after
learning
way
more
than
I
really
cared
to
about
open
source
law
and
having
to
make
friends
with
our
legal
team,
I
got
this
resolved,
so
we
re-licensed
the
spec
under
a
more
friendly
license
that
included
explicit
grants.
A
All
of
our
code
got
re-licensed
as
mit,
and
you
know
the
the
same
person
who
wrote
they
added
this
update
and
he
said
hurrah.
I
know
you
know
definitely
feel
right
feel
comfortable,
recommending
graphql
for
all
uses.
So
great
okay,
this
problem
is
solved,
but
I
started
to
get
this
feeling
in
the
back
of
my
head,
that
graphql
is
starting
to
outgrow
its
corporate
ownership
model
and
might
eventually
need
a
life
outside
of
facebook.
A
So,
a
couple
years
later,
after
I
had
left
facebook
myself,
I
formed
the
graphql
foundation
as
an
open
and
neutral
owner
of
graftual.
It
owns
its
code
and
artifacts
as
well
as
patents,
licenses
trademarks,
all
that
good
stuff,
but
like
what
exactly?
Is
this
thing?
What's
the
graphql
foundation,
and
what
does
it
do
so?
The
mission
of
the
foundation
is
to
accelerate
the
development
of
the
graphql
ecosystem
and
enable
widespread
adoption,
and
it
does
that
in
two
really
important
ways.
A
The
first
is
our
member
board,
so
the
member
board
is
full
of
companies
that
join
the
graphql
foundation
and
contribute
financially.
They
also
take
action
on
community
initiatives,
for
example.
This
event
is
hosted
in
large
part
thanks
to
the
contributions
of
our
members,
and
they
also
make
decisions,
so
they
contribute
financially
and
they
also
get
to
vote
and
decide
how
to
leverage
that
shared
pool
of
resources.
A
So
in
2009,
when
I
was
getting
the
foundation
together,
I
was
just
talking
to
folks
that
I
know
were
using
graphql
or
building
services
that
helped
people
use
graphql
and
said:
hey,
come
come,
do
this
with
me
and
I
got
a
handful
of
them
to
say:
yeah
sounds
awesome,
and
these
were
most
of
our
founding
members.
We
got
facebook
aws
ibm
into
it.
Neo4J
is
still
in
there,
salsify
apollo
hisura,
and
this
kept
growing.
So
today
we've
got
28
member
companies.
A
In
fact,
just
in
the
last
couple
of
months,
this
grew
from
25
to
28,
so
we're
still
growing
really
quickly
and
the
vast
majority
of
these
are
not
just
financial
backers.
They're
they're,
really
proactive
contributors,
they're
doing
stuff
they're
showing
up
to
board
meetings
they're,
you
know
they're
taking
action,
and
this
is
fantastic
and
you
know
I
would
love
to
see
this
number
keep
going
up.
So
if
you
know,
if
you
work
somewhere
and
you
care
about
graphql,
the
financial
contribution
here
is
not
huge.
A
It's
meant
to
be
very
accessible
because
we
want
people
who
care
about
this
to
come
work
with
us,
so
companies
contribute
financially,
but
I
kind
of
wanted
to
really
avoid
a
pay
to
play
situation.
So
earlier
in
my
career,
I
was
one
of
facebook's
delegates
to
the
tc39,
the
javascript
body,
and
that
was
this
pay
to
play.
A
So
there
was
a
bunch
of
moments
that
felt
really
awkward
where
someone
in
the
community
had
fantastic
ideas
and
we
wanted
to
bring
them
in,
and
there
was
just
like
all
this
like
insane
rules
and
how
to
get
like
a
clearly
brilliant
person,
with
a
great
idea
with
enthusiasm
to
like
show
up
and
represent
that
idea.
Just
didn't
feel
right,
so
I
didn't
want
us
to
end
up
in
that
similar
situation.
A
But
actually
this
working
group
predated
the
foundation,
so
back
in
2016
was
less
than
a
year
after
open
source
and
graphql.
We
had
the
very
first
dedicated
graphql
conference,
there's
about
350
people
totally
nuts
to
me
that
the
very
first
dedicated
conference
happened
so
quickly.
But
at
this
conference
I
gave
the
closing
talk
and
I
announced
sort
of
you
know
big
boy
shoes
for
for
graphql.
We
were
going
to
take
on
a
couple
more
kind
of
heavyweight
procedures
to
make
sure
the
the
technology
was
going
to
evolve.
A
A
These
were
the
origins
of
our
working
group.
So
really
our
working
group
goes
back
almost
six
years,
which
is
pretty
wild.
So
when
we
created
the
foundation,
I
wanted
to
make
sure
that
that
group
felt
very
well
supported,
so
we
did
a
collaboration
with
this.
The
small
group
called
the
joint
development
foundation
most
of
what
they
do.
A
The
attendance
and
the
ongoing
work
in
these
meetings
somehow
seems
to
keep
accelerating
like
you'd,
think,
six
years
later,
like
maybe
it
would
have
peaked
and
trailed
off,
but
no.
This
is
the
one
that
we
had
literally
last
week
and
I
counted
we
had
24
attendees
and
that's
not
a
typical.
This
is
a
common
meeting
is
to
have
roughly
two
dozen
people.
We
had
a
packed
agenda.
The
meeting
went
two
hours
long.
We
actually
had
to
bump
one
thing
to
the
next
month.
Talk
in
addition
to
this.
A
We
have
subcommittees,
there's
just
a
ton
of
really
really
interesting
work
going
on
to
advance
graphql
you're
welcome
to
join
these
they're
free
and
open,
but
in
addition
to
this
we
record
them
all,
there's
actually
a
screenshot
from
a
youtube
video
we
post
all
of
them
on
youtube.
We
also
take
extensive
notes-
and
this
is
in
fact
benji
our
resident
community
maintainer
and
note
taker
who
I
don't
have
no
idea
how
he
does
it,
but
has
himself
overlaid
over
the
notes
in
every
meeting.
It's
fantastic.
A
The
final
group
that
makes
up
the
foundation
is
our
technical
steering
committee
and
in
many
other
foundations,
this
group
has
a
lot
of
responsibility,
but
because
the
working
group
predated
it,
the
working
group
really
takes
on
the
vast
majority
of
technical
responsibility,
so
the
tsc
is
really
more
of
like
a
formal
body.
These
are
the
administrators.
A
So
if
something
pops
up
that
needs
administrative
help,
the
tsc
is
there
to
help
that
out.
You
can
kind
of
think
of
this
as
like
the
core
maintainer
group
for
a
project
where
you
might
have
like
a
whole.
Broad
set
of
people
may
contributing
and
maintaining,
but
there's
like
a
tight,
narrowly
defined
group
who
are
the
core,
and
you
have
sort
of
extra
permissions
and,
as
I
mentioned
before,
I'm
a
fairly
new
dad
and
so
I've
had
to
learn
to
be
very
judicious
with
my
time.
A
So
before
I
was
like,
I
was
kind
of
the
graphql
admin
and
sometimes
something
would
pop
up
and
I'd
be
busy.
I
wouldn't
be
able
to
jump
in
and
help,
and
so
the
tsc
has
been
a
fantastic
way
to
scale
myself.
These
help
these
people
help
manage
our
core
projects,
help
merge,
pull
requests,
they
organize
our
working
group
meetings.
They
stay
atop
a
ton
of
issues,
I'm
very
very
pleased
to
have
such
a
fantastic
group
to
lean
on
and
they're,
also
responsible
anytime.
A
We
need
to
take
a
vote
on
something
which
we
very
very
rarely
need
to
do
almost
everything
we
do
by
consensus,
but
every
once
in
a
while.
We
need
to
do
a
vote
and
one
thing
that
actually
has
a
legal
requirement
to
do.
A
vote
is
ratifying
our
spec
and
last
fall.
We
did
exactly
that.
We
ratified
the
very
first
version
of
the
graphql
spec
and
it's
governed
by
all
of
the
above.
A
So
this
might
feel
a
little
underwhelming
like
we
did
a
spec
release
and
there
was
no
new
major
like
whoa
an
incredible
new
feature.
But
to
me
this
actually
seems
right.
This
feels
good,
because
at
10
years
old
graphql
really
needs
to
feel
stable,
because
other
technology,
companies
and
services
are
built
on
top
of
it
and
those
need
to
thrive.
So
frequent
changes
may
be
exciting
for
us
core
developers,
but
if
it
creates
a
ton
of
thrash
across
the
ecosystem,
that's
not
a
good
thing.
A
So
I've
actually
been
thinking
about
the
phase
that
we're
in
now
a
bit
more
and
remembering
back
to
that
first
graphql
conference
from
2016.,
and
in
that
talk
I
shared
that
you
know
less
than
a
year
after
open
sourcing.
I
was
really
surprised
by
how
well
things
were
going
and
how
I
had
actually
kind
of
written
down
some
predictions
of
what
I
thought
might
happen
with
some
like
rough
dates
as
to
when
I,
when
I
thought
they
would
happen,
and
I
called
it-
the
graphql
secret
master
plan
for
world
domination.
A
So
I've
revisited
this
a
few
times.
So,
if
you've
seen
one
of
my
talks,
you
might
recognize
the
slide,
but
just
to
kind
of
recap.
The
first
few
months
was
like
all
right,
we're
going
to
get
hobbyists
and
some
personal
projects
and-
and
that
was
looking
pretty
accurate.
I
was
happy
with
that,
but
then
we
like
whizzed
down
the
list
really
fast.
So
I
thought
that
was
going
to
take
about
two
years
to
see
graphql
implemented
in
10
languages,
but
this
actually
happened
in
slightly
less
than
one
year.
A
Around
the
two
year
mark,
we
had
this
like
very
large
and
growing
list
of
tech
giants
and
fortune
500
companies
all
not
just
using
it,
but
like
publicly
talking
about
how
they
were
using
graphql
and
in
the
years
since
that's
continued
to
grow
really
rapidly.
So
the
previous
times
I've
talked
about
this,
I
said
you
know.
Maybe
the
next
thing
is
ubiquity
and
I
said
before
I
don't
know
if
I
really
know
how
to
define
that
or
what
that
means.
A
A
I'm
convinced
that
the
core
of
graphql
itself
is
pretty
evergreen,
much
like
how
sql
is
still
in
pretty
frequent
use,
despite
being
well
over
50
years
old,
but
just
as
variants
of
sql
have
evolved
quite
a
lot
in
that
time,
so
must
graphql
and
graphql
is
built
with
front-end
developers.
Client-Side
engineers
in
mind-
and
the
one
thing
we
know
for
sure
is
that
web
and
mobile
tech
stacks
are
rapidly
evolving,
and
so
as
they
do,
we
have
to
keep
our
eyes
out
for
emerging
problems
and
see
how
or
if
graphql
can
help
them
face
those.
A
Pretty
much
every
year
that
I
talk
about
graphql,
I
say
I
always
have
underestimated
just
how
hard
it
is
and
how
important
it
is
to
invest
in
really
good
tools.
So,
actually,
I
think
some
of
the
most
important
work
going
on
in
the
graphql
space
are
the
developer
companies
who
are
building
high
power
tools
for
graphql.
I
think
that's
really
critical
to
establish
graphql
as
a
mature
and
stable
technology.
A
So
here
we
are
again
super
thrilled
to
be
kicking
off
this
for
everyone
who's
here
in
person.
Thank
you
for
being
here
and
everyone
who's
tuning
in
live,
as
you
can
tell
I'm
really
proud
of
the
graphic
foundation
and
what
it's
let
us
do
over
the
last
few
years.
I
think
it
only
gets
better
as
more
people
show
up
to
help
participate.
So
again,
if
you
use
graphql,
if
your
company
uses
graphql,
I
would
love
to
see
you
participate.
I
would
love
to
see
your
company
on
our
list
of
members.