►
Description
Deep Dive into GraphQL and React RFC-s by John Joyce and Arun Vasudevan at Jan 15 2021 Community Meeting
B
Yeah
sure
thanks
srishan,
thanks
anna,
that
was
great
to
hear
how
you
guys
are
using
it
at
the
company.
So,
as
many
of
you
may
know,
I'm
kind
of
a
recent
community
member
I
joined
about
a
month
ago.
Previously
I
was
working
at
linkedin
on
a
federated
graphql
layer
and
more
recently
I
have
joined
sri
shanka
in
his
in
his
venture.
So
as
part
of
sort
of
booting
up
with
data
hub,
I
set
myself
a
goal
to
try
to
do
some
work
on
the
front
end.
B
B
So
the
first
thing,
there's
kind
of
two
parts
to
what
I've
been
working
on.
The
first
thing
is
actually
adding
a
graphql
endpoint
into
the
existing
data
hub
front-end
server,
which
is
a
play
server.
The
reason
I
chose
to
add
it.
There
was
that,
first
of
all,
it
was
just
the
clearest
pathway
we
already
had
the
server.
We
can
just
add
a
new
endpoint
there
that
supported
the
graphql
spec.
B
I
didn't
have
to
spin
anything
else
up,
but
also
I
figured
that
the
existing
ember
app
may
benefit
from
being
able
to
talk
to
a
graphql
server
in
the
future.
So
I
decided
to
place
it
there
and
the
second
thing
you
can
see
that,
basically,
what
I've
done
is
just
add
a
little
module
to
data
hub
front
end,
and
the
second
part
is
introducing
a
new
react
client
that
talks
to
this
graphql
endpoint
to
create
the
views
on
the
front
end.
So
what
we
essentially
have
here
is
sort
of
a
parallel
ui
stack.
B
A
B
So,
first
I'll
talk
about
why
I
thought
it
was
a
good
idea
to
sort
of
add
a
new
application.
Specifically,
you
know
I
had
come
to
the
project
without
much
much
experience
with
ember,
and
I
think
I
personally
faced
the
steep
learning
curve
of
ember
trying
to
get
up
to
speed
on
the
existing
data
hub
client,
and
so
I
think
that
technology
wise,
it
would
make
sense
to
add
a
react
app
mainly
because
it
can
extend
the
reach
and
accessibility
of
the
data
hub
front
end.
B
B
B
B
These
aspects
so
specifically
making
sure
that
those
levers
for
customization
and
extension
by
individual
organizations
are
built
into
the
front
end
from
the
beginning.
We
can
have
a
chance
to
clean
up
some
of
that
dead
code
that
may
not
be
used
today
and
then.
Finally,
we
can
make
sure
that
we
have
very
clear
and
documented
paths
to
doing
things
like
extending
the
front
end.
B
So
you
know
in
order
to
understand
what
those
endpoints
from
the
play
server
were
returning.
They
were
just
json
globs
I'd
have
to
kind
of
probe
those
endpoints
directly.
Some
of
them
had
sort
of
these
view,
models
that
are
specific
to
the
client,
like
data
set
view,
and
some
of
them
were
just
gms
models
that
were
passed
through
so
like
the
corp
user
pdl.
B
So
I
found
that
it
really
helped
my
my
own
personal
iteration
speed
by
sort
of
taking
the
time
at
the
beginning
to
establish
that
explicit
contract,
and
I
think
graphql
is
great
for
this,
because
it
provides
these
self-documenting
strongly
typed
and
validated
contracts.
It
provides
like
a
dependency,
which
is
this
intermediate
api
layer
that
the
client
can
depend
on,
which
makes
it
also
very
easy
to
sort
of
switch
the
implementing
server
technology
in
a
way
that's
opaque
to
the
end
client.
B
The
next
thing
is,
you
know,
I
think,
graphql
in
itself
kind
of
reduces
the
the
api
calls,
as
well
as
the
noise
and
the
by
virtue
of
being
able
to
sort
of
ask
for
exactly
what
you
want,
as
well
as
being
able
to
traverse
related
entities
with
fewer
api
calls.
So
there's
just
a
reduction
in
this
back
and
forth.
B
So
if
you
guys
want
to
see
kind
of
how
I
did
it,
I
have
a
few
rfcs
open.
One
on
graphql
queries,
one
on
mutations,
still
some
discussions
ongoing,
which
I'll
discuss
in
a
bit
and
then
I
have
a
new
proposal
to
sort
of
incubate.
This
parallel
react
app,
as
well
as
a
proof
of
concept
for
for
all
of
those
things
as
well,
and
I
think
with
that,
I'm
going
to
just
quickly
jump
into
a
demo
of
the
react
stuff.
B
I've
been
working
on
now,
I'll,
okay,
can
you
I
might
want
to
screen
share,
let's
see:
okay,
okay,
yeah.
So
right
now
like
this
is
very
mocked
like
we
are
working
against
graphql,
but
we're
using
this
mock
graphql
server
that
instead
of
the
datahub
frontend
to
actually
populate
the
data,
but
I'll
just
show
a
few
screens
just
as
a
proof
of
concept.
So
here
you
can
see.
I
directed
us
right
to
a
search,
because
this
is
something
I've
already
implemented,
but
you
can
see
it's
pretty
similar
to
the
existing
search.
B
A
B
Our
proposal
is
that
we
essentially
take
the
public
gms
models,
not
the
entity
and
aspect
models,
but
the
models
that
are
exposed
at
the
gms
get
and
batch
get
api
layer
which
is
like
dataset.pdl,
for
instance,
and
use
those
to
actually
auto-generate.
This
graphql
schema
such
that
we
don't
have
to
sort
of
maintain
multiple
type
systems
or
schemas
across
different
layers
of
the
stack
right.
Now
we
kind
of
have
this
divergence.
B
In
some
cases
there
are
different
view
models
on
the
front
end,
and
what
that
means
is
that
it's
just
more
difficult
to
extend,
there's
more
steps
to
to
make
changes.
However,
you
know
I
recognize
that
there
may
be
cases
where
we
need
kind
of
those
front-end
specific
fields,
and
I
think
we
can
do
both
with
some
sort
of
extension
system,
which
we
can.
We
can
talk
more
about
in
offline.
B
The
second
thing
is
modeling
mutations,
there's
kind
of
two
schools
of
thought
floating
around
right
now.
One
is
sort
of
keeping
the
both
the
mutations
and
the
is
actually
sort
of
entity
oriented
to
the
front
end,
which
means
we
don't
explicitly
model
this
concept
of
entity
and
aspect
specifically
like
the
differentiation
between
the
two
on
the
front
end
and
the
front
end
simply
treats
all
of
these
models
as
entities
just
single
documents,
which
it
can
do
updates
against
as
opposed
to
having
to
have
different
routes
or
different
mutations.
B
For
each
aspect,
say:
ownership
schema,
etc.
That
you
need
to
change.
You
can
just
have
one
top
level
data
set
that
you
can
update.
With
all
of
that
information,
I
think
you
know
the
downside
to
the
aspect.
Oriented
is
that
you
just
have
this
more
coupling
throughout
the
entire
stack,
where
aspects
as
a
concept
sort
of
bleed
across
everywhere
right
into
data
up
front
end
and
then
eventually
into
the
client.
B
So
this
is
still
very
much
an
open
discussion
ongoing
I'm
interested
to
hear
what
the
community
members
think
for
certain
and
then
the
next
thing
is
sort
of
the
the
react
ember
drift
problem,
and
I
think
you
know
we're
very
aware
that
this
can
happen.
I
think
our
straw
man
is
that
in
the
long
term
the
react
app
should
be
kind
of
the
default
disposition
of
the
community,
and
what
that
means
is
you
know
in
the
short
term,
there's
definitely
going
to
be
that
functional
difference
as
react.
B
I
think
in
our
proposal
we
sort
of
recommend
a
migration
of
clients
from
the
ember
app
to
the
react
app
at
that
point
and
then
eventually,
eventually
deprecate
support
for
the
ember
client
in
the
long
term,
and
with
that
I'm
going
to
talk
about
one
other
open
discussion,
we
have
going
right
now,
specifically
a
collaboration
with
with
expedia
who
is
also
interested
in
graphql,
albeit
in
a
different
light.
So
I'm
going
to
hand
it
off
to
arun
who's,
going
to
talk
about
their
experience
with
graphql
and
datahub.
C
C
So
that's
the
main
motivation
and
where
it
fits
in
the
architecture
is
mainly
like
from
the
front
end.
There
would
be
a
separate
graphql
service
as
now
we're
thinking
it
like
a
string
boot
service
that
that
would
call
the
common
resolvers
the
common
resolvers
are.
Basically.
This
is
where
me
and
john
would
work
together
on
coming
up
with,
because
john
is
calling
up
from
his
play
server
these
common
resolvers.
C
So
we
didn't
want
to
duplicate
these
resolvers,
so
we
would
try
to
come
up
with
something
common
for
both
of
us,
and
these
would
call
the
gms
dolls
directly
through
the
sleep.
The
rest
of
the
architecture
would
be
familiar
for
you
guys,
because
that's
that's
similar
to
what
data
hub
is
these
green
components
are
the
only
ones
that's
added
yeah.
Moving
on
these
are
some
of
the
details
on
how
I'm
planning
to
implement
it.
C
So
that's
the
metadata
graphql
api
in
itself
would
be
a
standalone
deployed
that
would
call
the
common
resolvers
to
get
all
the
resolvers
fields
and
from
there
would
be
the
wrestling
call
to
the
gms
dolls
and
specific
to
the
gms
clients
say
the
data
sets
or
ownerships
or
any
of
the
other
things,
the
ml
model
that
that
gets
added.
So
all
of
this
would
be
called
from
the
common
resolvers.
C
B
Thanks
erin
yeah
I'll
just
go
ahead
and
summarize
that
discussion.
So,
although
the
specifics
are
still
in
flux,
I
think
what
we're
thinking
is
that,
because
a
roon's
use
case
requires
sort
of
a
standalone
application
that
will
not
be
communicated
to
from
a
front-end
as
in
like
react
or
ember.
But
instead
a
node
server
will
essentially
have
a
common
library
that
we
can
both
work
against,
which
has
essentially
a
shared
graph
derived
from
the
gms
models,
as
well
as
a
shared
set
of
resolvers.
That
can
be
pulled
into
both
of
those.