►
From YouTube: The Graph by Yaniv Tal
Description
Berlin Ethereum Meetup 2019/06/18
Interoperability Edition
A
So
you
know,
we
really
believe
that
you
know
we
want
software
to
be
built
on
a
solid
foundation
and
I
often
get
this
feeling
that
the
way
that
software
is
deployed
globally
today
is
a
bit
like
building
on
quicksand
and
so
I
think
you
know.
All
of
us
in
this
room
are
probably
here
to
try
to
work
on
this
problem
and
we're
at
the
very
kind
of
you,
know,
beginning
stages
of
this,
and
you
know
it
starts
by
building
on
protocols
that
have
certain
guarantees
right
around
stability,
openness,
security,
verifiability,
and
you
know
right
now.
A
We're
focused
a
lot
on
like
financial
use
cases
and
you
know
defy
dows
there's.
You
know
a
lot
of
these
early
cases
coming
up,
but
you
know
we.
We
really
believe
that,
like
this
is
just
how
all
software
should
run,
eventually
that
you
know
you
have
protocols
that
provide
these
guarantees
and
you
kind
of
build
up
from
there
and
that
that's
gonna,
allow
you
know
society
and
civilization
to
you,
know,
scale
and
coordinate
in
ways
that
you
know
we
can't
do
today.
A
So
the
problem
that
we
solve
is
once
you
try
to
build
an
application
on
top
of
a
block
chain
like
aetherium.
You
quickly
realize
that
it's
actually
pretty
hard
to
get
the
data
that
you
need
directly
to
your
front.
End
application,
alright,
so
you're,
building
some
kind
of
web
or
mobile,
app
and
you
want
to
you
know,
run
some
kind
of
query
to
get
some
data.
You
want
it.
A
Maybe
filter,
search,
paginate
and
maybe
try
to
do
this
using
like
web
through
j/s
or
something
like
that,
and
basically
it
either
takes
too
long,
or
you
know
you
kind
of
have
to
just
load
all
of
the
data
on
the
client
and
filter
it
locally
and
and
you
kind
of
get
stuck
and
basically
the
problem
is
that
block
chains
are
missing.
This
indexing
layer.
So
when
you
have
a
database,
a
database
maintains
indexes.
A
A
A
So
basically
the
way
it
works
is
you
define
what's
called
a
sub
graph
and
a
sub
graph
basically
defines
how
to
index
that
data
in
a
reproducible
way.
So
all
data
on
the
graph
comes
from
a
web.
3
data
source,
so
that's
kind
of
the
Box
on
the
right
there,
and
that's
really
important
for
us
that,
in
order
for
this
to
be
reproducible,
it's
important
that
the
data
doesn't
come
from
any
sort
of
web
2
data
source.
A
So
if
we
allow
you
to
just
hit
some
kind
of
HTTP
API,
that
API
could
return
different
data
every
time
and
you
wouldn't
have
that
reproducibility
so
right
now
we
support
aetherium
and
ipfs
and
we're
going
to
be
adding
more
data
sources,
more
block
chains,
more
storage
networks,
more
protocols
over
time,
then
you
define
these
mappings
which
are
compiled
to
wow
them.
So
you
can
do
any
arbitrary
data
transformations
on
the
data
from
those
data
sources.
A
So
so
the
quick
pitch
on
graph
QL
is
it's
the
easiest
most
convenient
way
to
fetch
data
from
a
server
and
instead
of
rest,
where
you
have
one
endpoint
per
resource,
we're
likely
the
endpoint
doesn't
have
exactly
the
data
that
you
want,
which
then
forces
you
to
make
like
multiple
round
trips
and
there's
kind
of
just
this
mismatch
between
what
the
server
provides
and
what
the
client
wants.
You
can
define
the
entire
schema
upfront.
You
say
here
all
of
the
different
entity
types.
A
A
So
I'm
gonna
show
a
brief
demo
of
the
graph,
so
so
this
is
graph
Explorer
you
can
see
if
you
go
to
the
graph,
calm,
slash
Explorer
and
you
can
see
some
of
the
featured
sub
graphs.
We
have
at
the
top
here
and
then
there's
a
bunch
of
sub
graphs
that
people
are
like
building
and
deploying
every
day.
So
we
can
take
a
look
at
some
of
these,
so
there's
this
like
melon
port,
one
and
I'm,
going
to
try
to
zoom
in
a
little
see
if
that
works.
A
A
So
in
melon
port
they're,
like
a
fund
protocol
on
a
hiriam,
and
you
can
see
it's
a
really
rich
schema.
There's
all
of
these
different
like
entity
types
is
to
just
kind
of
graph
QL.
So
you
can
see
these
like
investors
and
trading
and
shares
and
policies,
and
like
all
of
these
things,
so
if
I
check
out
like
a
fund,
so
a
fund
has
a
name,
it
has
a
manager.
It
has
like
all
of
these
fields
on
it
and
you
can
see
that
it's
all
like
relational.
A
So
you
know,
a
fund,
for
example,
refers
to
like
the
investment
history
and
I.
Can
click
on
the
investment
history
and
see
what
that's
got
like
the
shares
and
the
share
prices
and
the
amounts.
And
then
you
can
run
queries
kind
of
in
this
playground
here
and
we
stand
up
this
graph
QL
API.
So
these
are
public,
endpoints,
HTTP
and
WebSocket
endpoints
that
you
can
hit
directly
from
your
web
or
mobile
app.
A
So
the
graph
acts
as
like
live
API
back-end
that
you
hit
from
your
apps
to
get
all
all
your
data
so
now
everything's
like
super
exploded
and
big.
But
let's
take
a
look
at
another
one,
so
this
is
P
pyth,
which
is
a
fun
app.
It's
got
like
a
Twitter
clone,
so
we've
indexed
like
53,000
entities
here,
and
so
these
peeps
are
like,
like
the
tweets,
and
we
recently
added
this
like
saved
queries
feature.
So
you
can,
you
know,
type
a
query
and
then
give
it
a
name.
A
So
it's
easy
to
find
so
this,
for
example,
is
like
PP
users
and
their
followers.
So
if
I
want
to
grab
the
accounts
and
get
their
names
and
then
their
followers
I
can
do
that.
I
hit
play
I,
get
back
those
responses
and
and
what's
cool
is
even
if
I
don't
know
what
data
is
available.
I
can
hit
like
control,
space
and
I.
Get
this
like
autocomplete,
so
I
can
see
that
if
I
want
for
these
followers,
I
could
get
like
any
of
these
additional
fields.
So.
A
A
So
here's
a
bunch
of
like
peeps,
so
you
could
see
you
could
like
really
easily
build
like
a
Twitter
type
clone.
On
top
of
this
API.
You
can
ask
for
just
the
data
that
you
want.
You
get
it
back,
and
so
that's
how
you
kind
of
query
data
and
use
the
graph
to
get
the
data
that
you
want
so
now,
I'll
show
you
what
it's
like
to
build
one
of
these
sub
graphs.
A
That's
doing
like
a
coffee
supply
chain
on
it
area,
which
I
think
is
pretty
cool,
because
you
know
coffee
is
an
example
of
like
some.
You
know
market
where
you
know,
prices
are
really
opaque
and
you
know
these
farmers
aren't
getting
a
lot
of
money
for
their
labor,
and
so
you
could
create
this
kind
of
direct-to-consumer
or
any
kind
of
you
know
marketplace
to
connect
people
directly
to
these
farms.
A
A
So
in
your
manifest,
you
specify
the
data
sources,
so
this
is
going
to
be
an
aetherium
contract.
Here's
the
contract
address,
and
then
these
are
the
events
that
I
want
to
listen
to
and
so
there's
different
types
of
triggers.
So
we
support
events,
and
recently
we
added
call
handlers
as
another
kind
of
trigger,
so
you
can
trigger
anytime.
A
smart
contract
function
is
called.
You
could
use
that
as
a
trigger,
and
then
you
specify
the
handlers
they
get
called.
A
Then
you
specify
your
graph
QL
schema.
So
this
looks
very
much
like
what
we
were
looking
at
before
this
is
standard
graph
QL.
It
defines
basically
the
the
data
model
and
then
you
have
your
mappings.
So
so
the
mappings
are
built
in
a
subset
of
type
script
called
assembly
script
which
compiles
to
wasm.
So
so
this
is
pretty
cool.
We
kind
of
looked
at
all
the
different
ways
that
you
could
build
for
wasm,
and
we
thought
that
this
was
like
the
easiest
to
learn.
Since
everybody
knows
JavaScript
or
typescript.
A
It
just
has
like
a
few
quirks,
but
we've
added
a
bunch
of
tooling
to
make
it
really
easy
to
build
on
top
of
this.
So
here
we're
handling
this
add
cut
profile
event
and
you
get
the
event
and
then
you
have
access
to
the
event
data,
the
transaction
data,
the
block
data.
You
can
get
smart
contract
state
as
of
this
block
and
we
basically
like
event
source.
So
we'll
start
at
the
first
block
and
we'll
run
through
everything
and
we'll
just
like
run
all
the
handlers
index.
A
All
the
data
and
it's
available
over
graph,
QL
and
what's
cool,
is
you
know
we
generate
all
of
these
types
for
you,
based
on,
like
the
schema
and
on
the
api's.
So
you
get
autocomplete
on
everything.
So
here
we
can
see
that
we've
got
like
these
cut
profiles
and
they
have
like
some
data,
but
they
don't
have
like
all
the
data
that
we
might
want
and
I
happen
to
know
that
this
contract
it
has
like
aroma
and
some
like
other
information
about,
like
these
cut
profiles
for
this
coffee.
A
That
I
think
would
be
cool
to
show
to
users.
So
I
could
easily
add
that
data
and
index
it
in
my
sub
graph.
So
basically
I
come
down
here
and
I,
say
I
want
to
add
some
data
to
this
cup
profile.
Say
I
want
to
add,
like
the
aroma
and
I
can
get
that
data.
The
event
so
I
get
like
autocomplete
here
and
I
know
that
that
data
is
available
on
the
event
parameter.
B
A
And
it
gave
me
the
red
squiggly,
so
I
knew
at
compile
time
cool
so
now,
I
can
jump
into
my
terminal
and
I
can
basically
deploy
and
that's
gonna
I
could
start
first
by
just
doing
a
build.
So
basically,
what
it's
doing
here
is
it's
compiling
the
assembly
script.
It's
uploading
the
waz
M
files
to
ipfs,
it's
hashing.
The
manifests
uploading
that
to
ipfs
so
everything's
on
ipfs,
and
then
I
get
back
this
sub
graph
ID,
which
is
that
ipfs
hash,
which
uniquely
identifies
this
version
of
this
sub
graph.
A
So
it's
like
content
addressed
and
then
I
can
deploy
that
to
the
hosted
service.
So
right
now
we're
running
a
bunch
of
nodes
for
you.
This
is
this
like
intermediate
step
on
the
way
to
the
fully
decentralized
network,
so
right
now,
I'm
just
going
to
deploy
this
to
the
hosted
service.
I
should
be
able
to
come
back
and
see
it
indexing
here.
So
we
support
making
like
zero
downtime
upgrades
so
that
current
version
is
still
running
and
if
you
know
my
app
is
hitting
that
end
point,
it
would
keep
running.
A
A
So
so
that's
the
graph.
Let
me
go
so
how
am
I
doing
on
time?
I?
Don't
when
did
I
start
perfect,
so
the
kind
of
data
that
you
know
I'm
excited
about
in
kind
of
the
short
term
I
mean.
Basically,
we
want
to
just
be
indexing.
All
of
the
data
from
all
different
networks
make
it
really
easy
to
to
access,
and
so
that
people
can
build
applications
on
top
of
fully
decentralized
protocols,
and
you
know
in
the
short
term,
you
know
the
stuff
that
really
excites
me
about.
A
This
is
the
opportunity
to
create
like
global,
open
markets,
for
everything
where
you
know,
people
don't
have
to
you
know
give
away
power
to
these
like
large,
centralized
entities
that
exert
their
market
power.
You
know
to
extract,
and
you
know
in
the
in
the
short
term.
Examples
of
that
would
be
just
you
know,
dows.
So
there's
a
bunch
of
like
Douw
protocols,
dow
stack
uses
us
and
we're
getting
started
in
engagement
with
like
Aragon
and
colony,
and
all
of
these
dowels
I
think
are
really
exciting.
A
I
think
you
know,
all
of
this
kind
of
stuff
should
be
on
web
3
and
when
it's
all
available,
like
those
people,
be
able
to
build
more
and
more
applications,
they'll
be
able
to
customize
them
and
you'll
know
that
all
of
this
software
can
continue
to
run
forever
and
you
can
build
on
it.
You
can
you
know,
trust
in
it.
It's
you
know,
kind
of
a
stable
foundation
for
large-scale
coordination.
So
if
you're
building
in
the
space,
if
you're,
building
on
aetherium
or
other
block
chains,
please
reach
out
we'd
love
to
help.
C
A
We're
specifically
going
to
be
adding
support
for
multiple
block
chains.
Did
someone
change
something
there
because
I
would
bring
closer
okay
so
as
part
of
that
effort,
we're
going
to
make
it
like
much
more
modular
specifically
so
that
it
uses
like
a
plug-in
architecture
where
we'll
build
like
the
first
few
plugins
to
add
support
for
multiple
chains,
we're
really
interested
in
like
cosmos
and
polka
dot,
for
example,
adding
support
for
those
and
then
eventually
anyone
should
be
able
to
build
their
own
plugin
for
their
own
data
source.
You.
D
Said
in
well,
thank
you
for
the
talk
and
also
great
project.
You
said
that
you
currently
use
support
theorem
and
ipfs
roms,
because
you
want,
like
cryptographically,
audible
input
right
to
have
it
be
reproducible.
Well,
what
do
you
mean
with
or
what
is
your
vision
or
roadmap
for
supporting
ipfs?
Can
I
push
index
data
into
ipfs?
Do
I
try
to
index
data
from
ipfs
right
now,
I
think
it's
used
to
like
initiate
the
node
with
instructions.
Oh
so.
A
Right
now
we
do
use
ipfs
just
ourselves
internally
as
a
protocol
for
basically
storing
all
the
metadata
for
the
subgraphs,
but
so
like
when
you
deploy
a
subgraph.
What
you're
doing
is
you're
uploading,
you
know
the
wiles
and
file
and
the
manifest
and
everything
onto
ipfs,
getting
back
a
hash,
and
so
a
node
anywhere
in
the
world
could
just
look
up
that
hash
on
ipfs
to
get
everything
they
need
to
index
that
data.
So
that's
just
how
we're
using
it
internally.
A
The
way
that
you
know,
projects
that
are
building
on
the
graph
can
use
IP
FS
today
is,
if
you
have
some
data,
that's
stored
on
ipfs,
and
you
have
a
hash
that
you
then
anchor
on
chain.
So
you
have
like
in
your
smart
contract
you
law,
for
example
the
ipfs
hash.
Then
in
your
mapping
script
you
can
cat
that
file,
you
can
get
the
data
and
you
can
index
it
in
your
mappings.
A
But
the
problem
is
you
don't
have
any
strong
consensus
with
like
IP
NS,
it's
like
eventually
consistent,
and
so
we
need
to
figure
out
how
we're
going
to
deal
with
that,
because
we
want
our
protocol
to
maintain
consensus.
One
of
the
important
requirements
we
had
from
day.
One
is
that
if
you
issue
issue
a
query,
for
example,
as
of
some
block,
then
there
should
be
one
and
only
one
correct
response
to
that
query.
D
So
so
you
on
the
three
points
like
the
first
point,
just
because
I
am
selfish
and
I
want
to
dig
deeper.
So
is
this
when
you
say
like,
we
want
to
make
sure
that
the
input
instructions
to
the
node
is
also
verifiable,
so
that
different
nodes
have
the
exact
same
instructions.
Is
this
sort
of
in
a
vision
towards
having
consensus
on
the
indexing
of
different
notes
as
well,
and
where
what
do
you
see
happening
there?
Yeah.
A
It's
it's
just
I
mean
we
think.
Ipfs
is
just
like
a
great
abstraction
for
like
file
storage,
and
so
we
have
this
problem
of
like
we
need
to
store
the
files,
and
so
we
weren't
going
to
reinvent
the
wheel,
and
so
ipfs
was
a
good
solution
to
that
problem.
We
do
want
the
protocol
itself
to
be
open
and
permissionless,
and
so
the
easier
it
is
for
any
node
to
kind
of
have
these
guarantees
where
they
know
that,
like
the
data
will
continue
to
be
available
to
them.