►
From YouTube: Corpus Management Proof of Concept - Apollo Client Demo
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).
A
So
the
outcome
of
this
should
be
a
working
proof
of
concept
that
uses
and
consumes
graphql
and
rest
endpoints
and
then
also
allows
us
to
inject
mocked
out
data.
And,
aside
from
being
able
to
do
this,
we
should
be
able
to
easily
swap
one
for
the
other.
So
we
should
be
able
to
build
version
one
with
mocked
out
data.
So
we
have
something
to
put
in
front
of
customers
to
test
and
then
swap
that
mocked
out
data
for
either
graph
ql
or
rest
or
both.
A
So
I'm
going
to
jump
right
into
it.
So
this
is
a
very
basic
demo,
but
I'm
going
to
reload
the
page
here
and
there's
really
not
much
of
a
ui.
This
is
just
to
look
at
the
network,
work
request
and
see
if
we
could
do
it
and
then
also
look
at
the
code
after
that.
So
we'll
see
over
here
is
the
graphql
endpoint
and
the
data
that's
returned.
A
So
basically
we
have
these
packages
that
belong
to
a
project
in
the
future.
We'd
be
able
to
swap
that
out
for
corpuses,
whether
we
call
them
packages
or
corpuses
is
still
yet
to
be
determined
or
it
could
be
packages
with
some
type
of
filter
to
only
return
packages
that
fit
are
qualified
as
corpuses
and
then
we
also
have
this
rest
endpoint
and
this
rest
endpoint
is
the
equivalent
for
the
graphql
one
or
it
gets
you
the
equivalent
data
right.
A
You
have
the
project
url
and
then
you
have
packages
and
that's
the
document
address
endpoint
and
the
response
you
get
here.
This
project
is
none,
so
it's
still
a
successful
like
status
code,
but
it's
returning
an
empty
array
because
we
don't
have
any
same
thing
with
graphql.
I
don't
I
hit
the
endpoint,
it
doesn't
fail,
it's
a
200,
but
I
don't
have
any,
let's
say
valid
data
at
this
moment,
but
the
endpoint
works.
A
A
A
This
is
the
this
part
over.
Here
is
the
actual
graphql
query
for
packages
you
see
project
and
then
packages,
and
then
nodes
essentially
is
going
to
contain,
like
the
the
fragment
that
just
tells
us
the
the
value,
here's
the
properties
we
want
on
that
object,
so
corpus
state
in
this
case
is
this
fragment,
so
id
name
created
at
we'll,
add
whatever
we
want
as
needed.
A
So
going
back
to
the
resolvers.
Sorry
to
the
query
these
two
over
here,
graphq
apollo
client,
allows
us
to
inject
these.
I
guess
virtual
properties
that
essentially
allow
us
to
swap
that
out
for
whatever
data
we
want
client-side.
So
that's
what
the
client
directive
is.
So
when
you
define
this
client
directive,
we're
able
to
get
back
we're
able
to
define
a
resolver,
a
resolver
allows
us
to
do
whatever
we
want
in
it,
whether
we're
doing
a
rest,
ajax
request
or
if
we're
just
mocking
out
data.
A
So
you
see
that
the
the
style
like
the
pattern
is
very
similar.
We
name
the
name
of
the
field,
any
parameters
related
to
it
and
then
this
at
client
directive
to
distinguish
that
we
want
to
customers
over
the
find
we
go
over
to
resolvers,
and
this
is
essentially
where
that
logic
is
happening,
for
I
guess
the
the
queries
right.
So
here
we're
doing
the
actual.
What
we
would
traditionally
do
for
a
rest,
ajax
request
and
then
over
here
for
the
mocked
version,
because
it's
statically
co,
you
know
coded.
A
We
just
return
the
array
that
we've
hard
coded
here
and
that's
that's
pretty
much
it.
So
the
idea
being
that
if
we
were
going
to
swap
out
graphql
for
rest,
for
example,
all
we
would
have
to
do
here
and
these
are
all
equivalent
essentially
so
if
you
were
going
to
swap
out
project
packages,
you'd
be
able
to
do
swap
this
line
out.
Take
the
content
out
of
here
and
then
do
at
client,
and
then
we
would
just
define
the
the
custom
resolver.
A
So
it
would
show
up
as
query
I
guess
packages
and
then,
whatever
rest
requests.
We
need
for
that
and
if
we
were
going
in
the
opposite
direction
from
rust
to
graphql,
we
take
out
this
resolver
and
then
we
go
back
to
the
query
and
we
would
take
out
at
client
and
then
we
would
just
define
the
remainder
of
the
fields
that
we
want
in
that
request
is
standard
graphql
same
thing
for
the
mock
packages:
we'd
remove
at
client.
A
A
We
might
want
to
rename
to
rename
this,
but
this
would
stay
the
same
and
then
in
the
resolver
we'd
swap
out
this
mock
data
for
something
like
this.
We're
making
an
api
call
and
that's
pretty
much
it,
and
I
will,
I
guess,
go
over
here
and
show
this
is
the
actual
data
that's
getting
spit
out
from
the
actual
two
network
requests
and
then
the
mock
data.
So
if
I
set
a
breakpoint
real
quickly,
I'll
show
you
what
that
looks
like
from
the
front
end
view
side
of
things.
A
This
is
going
to
be
not
to
find
the
first
go-around,
because
this
is
the
initial
load
and
then
the
request
fire
off
that
that's
normal
for
view.
But
you
see
here
now
that
we've
actually
made
the
request
you're
able
to
see
what's
in
packages.
So
this
is
where
it
kind
of
like
we're
able
to
kind
of
coerce
the
data
into
what
we
need.
A
So
packages
in
this
case
is
just
empty,
is
an
empty
array
because
we
don't
have
anything
in
there
yet,
and
then
this
is
also
an
empty
array
because
we
don't
have
anything
from
graphql
or
rest,
even
though
it's
hitting
in
the
back
end
like
the
same
database
queries
it's
two
different
endpoints,
but
that
is
expected.
So
whatever
packages
we
get
here
and
here
would
be
identical.