►
From YouTube: The Graph - MIPs Workshop - AutoAgora
Description
The Graph is an indexing protocol for querying networks like Ethereum and IPFS. Anyone can build and publish open APIs, called subgraphs, making data easily accessible.
Follow The Graph on social media
Twitter: https://twitter.com/graphprotocol?s=20
Instagram: https://instagram.com/graphprotocol
LinkedIn: https://www.linkedin.com/company/thegraph/
GitHub: https://github.com/graphprotocol
Website: https://thegraph.com
Find more about the MIPs program here: https://thegraph.com/migration-incentive-program/ and follow all details of the program here: https://www.notion.so/MIPs-Home-911e1187f1d94d12b247317265f81059
A
Yes,
we're
recording
hello
everyone
and
welcome
back
to
another
mips
Workshop.
Thank
you
all
for
attending
today.
I
am
very
excited
to
have
Alexi
who
is
going
to
talk
to
us
all
about
ogura
and
also
Gora,
as
you
can
see,
from
the
presentation,
slides
and
with
that
I
will
hand
it
straight
to
him
to
take
us
into
the
workshop
hi.
B
B
Okay,
so
I'm
gonna
introduce
Agora.
First,
it's
gonna
be
a
short
introduction.
I'm
not
gonna,
go
too
much
in
detail
here,
because
there's
already
some
material
out
there,
notably
a
workshop
from
Zach,
who
is
the
the
main
developer
of
Agora,
so
yeah
I
hope
you'll
get
a
chance
to
to
check
that
Workshop
out.
B
B
B
Another
thing
also
is
that
we're
seeing
that
queries
are
quite
repetitive,
so
that
means
that
for
most
of
the
queries
you're
receiving,
you
can
take
action
and
you
know
determine
if
you
wanna
kick
them
out,
or
you
know,
price
them
according
to
their
difficulty.
Right
I
do
hope
by
the
way
that
you
already
know
about
graphql
I'm,
not
gonna,
I'm,
gonna
I'm,
not
gonna,
teach
you
about
graphql
in
here,
but
there
is
a
lot
of
material
out
there
right
in
any
case,
in
the
context
of
the
decentralized
service.
B
Queries
right.
The
Gateway
will
select
an
indexer
for
each
query
once
again,
I'm
not
going
to
go
into
detail,
but
basically
the
selection
is
a
function
of
the
economic
security,
which
is
how
much
the
indexer
has
staked
I
mean
how
much
the
indexer
has
in
delegations
take
and
also
how
much
is
located
to
the
particular
subgraph
that
is
being
served
and
other.
You
know,
quality
aspects
like
how
many
felt
queries
there
were
in
the
past
and
latency
right
and
and
also
the
price
of
the
query.
B
So
that's
where
it
gets
interesting.
If
you
press
the
particular
query
that
the
end
user
sent
too
high,
then
there
is
there's
going
to
be
a
higher
chance
that
another
indexer
is
going
to
be
picked
in
any
case.
So
we've
got
the
end
user,
send
the
graphql
query
to
the
Gateway
and
the
Gateway
selects
us.
Let's
say
that
query
is
gonna.
B
Etc
if
and
the
indexer
service
then
proxies
that
graphql
query
to
to
the
query
node,
which
the
software
is
called
graph
node
to
to
to
actually
process
that
query
and
the
graph
node
itself
of
course
gets
its
data
from
from
a
postgres
database
that
contains
all
the
data
from
the
subgraph.
That's
been
indexed
by
the
index,
node
Etc,
so
here
I'm
only
showing
the
flow
of
queries,
I'm,
not
showing
all
the
rest
of
the
components,
index,
reagent
and
the
index
nodes
and
and
your
you
know,
ethereum
nodes
Etc.
B
B
So
before
you
can
receive
a
query
and
before
you
can,
the
Gateway
can
decide
for
a
price.
You
have
to
supply
a
cost
model,
so
those
cost
models
are
written
in
the
Agora
DSL,
and
here
we
have
a
little
example
of
a
nagora
entry,
and
it
looks
very
much
like
a
graphql
query,
except
that
you
define
a
price
for
that
query
shape
basically
right.
So
in
particular
here
we
say
that
the
base
cost
of
that
query
is
0.0042.
Grt
plus
point
zero:
zero,
zero,
zero
38
times
first.
B
So
if
you
in
that
particular
case,
if
the
client
asks
for
many
Many
Many
Items
from
the
from
the
query
response,
we
would
charge
more
right,
and
so
that
would
apply
for
the
com
to
an
incoming
query
like
like
such
such
a
query
and
the
charge
price
in
that
particular
case
would
be
0.004314
GRT
right.
So
that's
pretty
much
how
it
works
and
that
pricing
is
computed
on
the
Gateway
prior
to
receiving
the
query.
B
B
So
the
the
overall
flow
once
again,
I'm
not
going
to
go
in
details,
but
you
can
find
some
information
in
the
readme's
of
different
pieces
of
software
I'm
going
to
mention
here
with
the
manual
flow
to
create
your
Agora
models.
Is
that
first,
you
run
your
query
node
with
a
graphlock
query:
timing
equals
gql,
and
that
will
make
the
query
node
spit
out.
Query
the
query
contents
and
the
query
execution
times
to
STD
out
and
then
it's
your
job
to
capture
the
logs
Second
Step.
B
B
B
C
B
Know
if,
if
the
queries
you're
receiving,
are
not
matching
those
first
two,
then
it
will
be
applied
that
default
price.
Once
again,
if
you
want
to
know
more
details,
you
can
do
way,
fancier
things
with
Agora
check
out
the
Agora
language
Workshop
that
I
mentioned
earlier,
and
in
any
case
after
this,
so
you
you've
got
your
Agora
file.
You
can
load
it
into
your
indexer
stack
to
be
served
to
the
Gateway
using
that
command,
so
that
command
comes
from
the
indexer
CLI
and
you
run
graph
index
for
cost
set
model.
B
B
So
it's
all
nice,
it's
very
powerful,
but
the
problem
is
that
it's
hard
to
do
and
it's
repetitive,
you
would
have
to
run
that
loop
I
described
here
for
every
new
subgraph
to
do
your
indexing
and
ideally
you
would
even
redo
the
models
for
the
subgraphs.
You
were
serving
because
the
statistics
of
the
queries
you're
receiving,
might
change
Etc,
so
some
indexers
just
elect
to
put
a
default
price
guesstimate
and
then
roll
with
it.
But
we're
not
very
happy
with
this,
and
especially
for
mips.
B
B
Automating
pretty
much
every
step
of
that
process
and
it's
functionally
split
in
two
parts:
it's
split
into
a
relative
disc
cost
Discovery
part
which
helps
you
determine
for
each
subgraph.
How
different
core
queries
are
are
cost
in
terms
of
your
Hardware
relative
to
each
other
and
then
in
the
second
part,
we're
going
to
discuss
how
all
of
those
prices
are
adjusted
in
real
time
to
the
current
market
conditions,
foreign.
B
So
we've
still
got
our
Gateway
Etc.
The
indexer
service
is
wrapped
in
a
container
called
Auto
agor
index
or
service,
and
its
job
is
to
automatically
filter
out
the
query
timing
logs.
So
the
very
ones
that
we
were
mentioning
earlier,
such
that
those
are
sent
to
a
queue
that
and
and
then
those
log
lines
are
processed
through
the
auto
Agora
processor.
B
That
data
is
then
saved
into
a
new
postgres
database
that
that
saves
the
query
logs
and
the
query
skeletons
I'm
going
to
come
back
to
what
that
means.
It's
pretty
much
a
log
of
all
the
queries.
You've
served
with
how
long
that
you
know
with
their
execution,
latencies
and
Otto.
Agora
then
runs
statistics
from
that
database
to
determine
which
are
the
most
frequent
queries
and
builds
and
updates
the
relative.
B
The
the
Agora
cost
models
automatically
those
cost
models
are
pushed
to
the
index
reagent,
just
as
the
indexer
CLI
would
do,
and
the
index
region
takes
care
of,
pushing
that
to
the
database
that
the
indexer
service
uses
and
then
the
index
or
service
serves
those
autologoric
generated,
cost
models
continuously
to
the
Gateway
yeah.
That's
pretty
much
so
in
green.
B
D
B
So
that
data
goes
into
the
auto
Agora
processor,
such
that
the
the
so
the
the
query
itself
is
extracted
the
so
that's
where
it
comes
from
yeah
from
the
queue
the
the
queries
extracted.
The
schema
of
the
subgraph
is
retrieved
from
the
indexer
service
and
that
helps
us
normalize
the
query,
because
in
graphql
there
is
many
ways
of
basically
asking
the
same
question,
but
at
the
end
it's
the
same
price
for
us,
so
we
want
to
normalize
all
of
that
in
our
statistical
data.
B
A
B
B
Here's
your
supporting
data
to
prove
that
we
do
need
to
normalize
our
our
queries,
and
here
we
have
the
frequency
of
the
most
queries
and
before
normalization,
you
can
see
that
the
the
the
frequencies
are
dropping
much
quicker
than
after
normalization,
because
queries
get
grouped
much
more
efficiently
and
much
more
tightly,
so
it
does
make
a
huge
difference
to
normalize
the
queries.
It's
a
very
important
step,
and
here
it's
just
an
example,
data
that
we
got
in
our
in
our
tables,
so
the
logs
table
we
can
see.
B
It
refers
to
a
subgraph
query
hash,
which
refers
to
a
particular
query:
skeleton
timestamp
when
we
receive
that
query
the
execution
time
and
the
variables
to
fill
into
the
to
the
skeleton
such
that
we
can
completely
rebuild
the
original
query
and,
in
the
course
skeletons
table
we
can
see
so
here.
Actually,
the
first
hash
here
corresponds
to
the
first
hash
here,
which
is
lucky
and
you
can
see
the
the
normalized
query,
which
is
also
very
much
compressed,
all
Extra,
Spaces
and
and
new
lines
Etc
are
removed.
B
B
B
B
It
will
not
generate
models
for
subgraphs
that
we
are
indexing
off
chain
or
or
something
else
on
the
subgraphs
that
we're
currently
allocated
on
and
thus
serving
right
now
so
using
the
index
or
CLI.
If
you
you
know,
while
togor
is
running,
if
you
ask
the
the
index
or
C
like
what
are
the
current
cost
models,
that's
what
it
would
tell
you.
So
that
gives
you
an
idea
of
what
autogora
generated,
and
you
can
see
that
you
get
some
comments
here.
B
That
just
gives
you
a
little
bit
of
context
data
for
you
to
double
check.
You
know
that
those
models
are
satisfactory.
So
it
gives
you
the
minimum
maximum
time
of
execution.
That's
been
observed
the
average
and
the
standard
deviation
actually
here.
The
standard
deviation
is
quite
large
somehow,
and
you
got
your
query
skeleton
and
the
price
that
was
computed
so
really
the
what
we
call
relative
cost
is
that
value
here
right.
B
So
here
we
have
a
second
entry
and
it's
a
cheaper,
statistically
cheaper,
query
to
execute,
and
we
can
see
here
that
the
relative
cost
is
44..
So
we
got
almost.
We
got
a
good
two
orders
of
magnitude,
difference
of
cost
between
those
two
queries,
yeah
and
we've
got
our
default
here
still
because
we
still
need
to
catch-all
right.
B
And
yeah
the
interesting
thing
here
is
that
we
got
a
global
cost
multiplier,
so
all
of
those
relative
costs
are
multiplied
by
global
cost
multiplier
that
is
determined
per
subgraph
and
that
is
fed
as
a
variable
to
to
Agora
and
so
to
determine
what
value
should
be
fed
in
this
we
have
to
compute
absolute
prices.
So
before
we
were
caring
about
the
cost
of
a
query,
and
now
we
have
to
determine
a
price
that
is
a
function
of
that
cost
and
and
the
current
market
conditions
Etc.
B
B
If,
if
you
press,
you
know
if
your
prices
are
too
expensive
compared
to
the
the
current
market
conditions,
how
it
looks
like
in
terms
of
Revenue
per
second
is
like
this.
So,
of
course,
if
you
set
your
price
to
zero,
you're
gonna
get
quite
a
bit
of
queries,
but
you
multiply
Whatever
by
zero.
You
get
zeros,
you
get
no
money.
B
As
you
increase
your
price,
your
Revenue
will
go
up
and
it
will
reach
a
tipping,
a
maximum
Tipping
Point
after
which,
because
you're
pressing
too
high
you
you
get
less
competitive
and
you
receive
less
queries.
So
you
sharply
your
your
query
rate
will
sharply
Decline
and
that's
your
Revenue
also
so
once
again
right.
If
your
price
is
extremely
high
and
you
get
no
queries
once
again
right,
you
multiply
by
zero,
you
get
zero,
and
so
the
game
here
is
to
maximize
our
Revenue,
which
is
the
average
query
price
times.
B
That's
just
determining
the
the
probability
density
for
us
to
to
pick
a
a
particular
price,
and
so
we're
sampling
that
gaussian
and
changing
our
price
multipliers
constantly,
and
with
this
we
determine
a
reward
function.
That
reward
function
is
just
our
Revenue
and
sorry,
and
the
reinforcement,
learning
algorithm
will
tweak
the
standard
deviation
and
the
mean
of
that
gaussian
such
that
we
optimize
the
revenue
I'm
going
to
show
you
after
that,
A
visual
representation
of
what
that
means.
B
It
might
seem
a
little
bit
abstract
in
any
case,
the
loop
of
the
algorithm
is
we
sample
a
press
multiplier
from
the
policy,
so
the
policies
that
gaussian
distribution
over
prices
we
apply
that
price
multiplier
to
Agora.
We
wait
one
minute
we
measure,
so
one
minute
is
because
we
have
to
wait
for
the
gateway
to
apply
that
new
price.
B
So
we
just
want
to
move.
We
want
to
follow
this
guy
whenever
it
moves,
I
invite
you
to
watch
that
Defcon
presentation
from
Thomas
cornuta,
a
colleague
of
mine
he
actually
presented
yesterday
at
Defcon,
and
it's
all
about
that
algorithm.
So
yeah
check
it
out
any
case.
Here's
a
visual
representation
of
what
goes
on.
So
what
you
can
see
at
the
top
here
is
the
red
line.
Is
that
gaussian
that
we
use
to
sample
the
prices
the
x-axis
are?
B
So
I'm
gonna
play
it
again,
as
we
can
see
that
that
gaussian
widens
to
figure
out
faster
where
that
limit
is,
and
then
it
converges
down
such
that
we
can
sample.
Mainly,
you
know
more
tightly
around
the
higher
prices
right,
so
you
can
see
the
the
Red
Dot
here
is,
just
being
it
samples
quite
right,
a
quite
a
wide
range
of
prices,
and
then
it's
getting
Tighter
and
Tighter
and
Tighter
as
it
trains
foreign.
B
B
So
here
are
the
components
that
are
involved
with
absolute
price
Discovery.
So
there's
a
bit
less
components,
because
we
don't
for
the
for
that
price
multiplier.
We
don't
really
care
about
what
the
contents
of
those
queries
of
of
the
I
mean.
We
don't
really
care
about.
The
relative
prices
of
queries
costs
sorry,
but
we
care
about
basically
shifting
those
those
prices
to
to
follow
the
market
price.
B
So
the
way
we're
doing
it
is
by
looking
at
the
query,
metrics
that
are
exposed
by
the
indexer
service.
That's
how
we
know
how
many
queries
were
served
in
a
in
a
chunk
of
time,
and
so
yes,
we
do.
This
to
Agora
will
address
that
price.
Multiplayer
variable
in
the
gore
models
and
push
it
to
an
extra
agent
into
the
indexer
services.
Db
and
an
indexer
service
will
serve
that
to
the
Gateway
and
it
just
repeats
repeats
repeats
in
a
much
tighter
Loop
by
the
way
than
the
the
relative
cost
discovery.
B
So
here
are
the
metrics
that
we
extract
from
Auto
Agora,
so
togor
sends
some
metrics
to
you
to
the
indexer's
Prometheus,
and
we
can
see
that
so
here
that
particular
sub
graph
I
think
is
is
Uma
on
ethereum,
and
so
we
can
see
that
the
number
of
queries
per
second
that
we're
serving
is
is
somewhat
flat.
You
got
to
remember
that
the
the
market
and
the
number
of
queries
that
we're
receiving
varies
right,
so
it's
not
only
a
function
of
our
prices,
but
it's
also
a
function
of
Demand
right.
B
So
that's
why
there's
not
a
very
much
visible
correlation
between
the
the
course
per
second
and
the
the
prices
were
sampling.
In
any
case,
we
can
see
that
the
mean
of
the
gaussian
fluctuates.
So
it
starts
pretty
it's
pretty
high
and
then
goes
down
a
little
bit
to
to
find
that
optimal
Point.
We
also
see
the
standard
deviation
going
down
over
time.
As
confidence
goes
up
about
the
the
market
environment.
B
We
can
see
that
also
the
consequence
in
terms
of
the
sampled
prices
that
we're
applying
over
time.
You
could
see
that
it's
extremely
wide
to
start
with,
as
it's
exploring
and
you
know
poking
around,
to
see
what
happens
and
then
it
converges
quite
tightly.
We
can
see
our
reward
going
up
as
expected.
So
that's
the
the
reward
in
that
particular
case
is
the
price
multiplier
times
queries
per
second,
and
we
can
also
see
that
the
the
GRT
per
second
that
we're
making
is
is
going
up
over
time.
B
So
it's
a
pretty
pretty
good
run
here,
so
putting
it
all
together.
Here
are
all
the
components.
So
you
see,
the
flow
for
the
relative
casting,
which
is
going
from
Gateway,
receive
query,
goes
through
index
or
service
Lexus,
Service
computes.
The
execution
time
goes
into
the
logs
into
the
queue
that
Q
is
consumed
by
the
auto
Agora
processors
that
gets
fed
into
the
database.
B
That
keeps
a
historical
trace
of
of
all
the
queries
we've
served
and
and
what
were
their
latencies,
and
that
goes
into
Agora
to
compute
its
statistics
to
generate
the
relative
cost
models.
It
also
gets
the
number
of
queries
that
are
served
from
the
the
query
metrics
and
generate
those
models.
The
October,
the
Agora
model,
sorry
fits
them
into
the
index
reagent,
which
fits
them
into
the
index
for
service
DB,
and
then
the
indexer
service
serves
those
models
to
the
Gateway.
So
you
got
the
the
full
cycle
here.
B
B
B
B
B
A
B
E
E
B
Thing
yes,
so,
first
of
all,
so
yes,
there
is
that
flow
right
that
sorry
yeah.
So
you
may
think
that
there
could
be
bad
pressure.
If,
let's
say
our
talk
or
processor
is
too
slow.
It
would
back
up
the
indexer
service,
standard
output
and
could
slow
things
down,
but
that's
not
the
case.
We
have
two
levels
of
pressure
reliefs.
B
B
E
B
E
B
Yeah
so
the
model
itself.
It
is
very
compact
right
because
the
only
the
only
variables
we're
training
are
the
standard
deviation
and
the
mean
right.
So
it's
basically
just
two
numbers,
and
then
you
multiply
that
by
the
number
of
subgraphs,
but
in
terms
of
memory,
it's
very
small.
It's
a
few
hundred
megabytes
for
auto
Agora,
a
few
hundred
megabytes
for
autograph
processor.
B
Yeah,
it's
very
small,
it's
much
less
than
the
indexer
service
or
even
the
indexer
agent.
As
a
matter
of
fact,
much
much
smaller
we've
developed
everything
in
Python,
so
it's
both.
You
know
easier
to
easier
to
comprehend
and
it's
much
much
lighter
than
the
node.js
parts
of
the
of
the
infrastructure.
E
B
B
It's
because
we're
sampling
prices
that
are
too
high,
and
that
means
that
we
don't
get
queries
for
that
amount
of
time
and
that's
because
we're
exploring
the
the
space,
and
so
that
is
that
information
is,
is
basically
a
strong
disincentive
right.
It's
a
negative
reward
for
the
for
the
the
optimization
algorithm
so.
B
B
B
It's
because
we're
sampling
over
the
price
limit
that
the
consumer
set
see
when
that
point
the
the
round,
the
the
red
disk
flashes
down
there,
it's
right
after
the
right
after
the
the
the
price
limit
that
the
consumer
set
and
so
effectively
here
we're
not
serving
queries
at
all
in
this
particular
simulation,
because
we
have
a
single
agent
for
the
subgraph
it.
It
looks
as
if,
basically,
the
the
core
is
never
served
right.
B
It's
a
mix
of
the
fact
that
both
agents
are
competing
so
that
limits
basically
how
far
up
the
agent
will
go,
and
also
because
they're
sampling
randomly
there's
very
little
chance
that
they
will
both
select
a
price
that
is
over
the
Consumer
Price.
So,
if
you're
over,
then
the
other
guy
takes
the
query
right.
So
that's
the
idea
in
general,
it's
known
that
quality
of
service
is
poor
when
there
is
a
single
indexer
on
a
subgraph.
Ideally,
you
would
get
three
indexers.
B
Okay,
so
will
the
recording
and
presentation
be
shared
after
the
workshop?
Yes,
yeah?
Okay?
Is
there
much
of
a
response
time
penalty
when
attaching
a
to
Agora
to
our
indexer
stack?
Has
this
been
measured
so,
as
I
said,
zero
penalty,
because
it
is
there's
multiple
buffers
right
so
first
there
is
the
standard
output
buffer
from
the
indexer
service,
because
we're
taking
everything
from
the
standard
output
of
the
the
logs
right
of
index
of
service,
then
we
got
a
programming
go
that
is
filtering
the
logs.
B
It
is
using
internal,
a
buffers
and
cues
and
it
also
has
a
pressure
relief
valve.
So
if,
if
the
queues
fill
up
then
entries
are
thrown
away,
then
the
rabbitmq
is
also
also
has
a
pressure.
Relief
also
will
throw
away
entries,
so
the
penalty
should
be
exactly
zero
and
if
it's
not
zero,
then
write
an
issue
and
we'll
try
and
fix
it,
but
we
have
three
layers
of
protection,
so
it
should
not
impact
at
all.
B
D
B
B
If
there
is
multiple
competing
indexers,
if
it
was
a
a
purely
let's
call
it
linear
Market,
you
would
expect
indeed
that,
as
soon
as
you
have
more
than
one
agent,
they
would
just
like
you
know,
try
and
get
the
queries
and
be
cheaper
than
the
other
guy
and
then
go
down
to
zero.
But
that's
not
the
case.
B
Oh,
the
chat,
oh
sorry,
I
wasn't,
monitoring
the
chat.
I'm
gonna,
switch
from
presentation
to
chat
and
I
yeah
feels
like
will
be
a
disadvantage
if
we're
not
running
Auto
Agora.
Yes-
and
that's
because
from
my
past
experience,
if
you
want
to
find
the
market
price,
if
you
want
to
do
it
by
hand,
you
have
to
sit
there
for
hours
and
then
it
moves
all
the
time.
B
B
Silly
question:
what
if
Robert
mq
goes
down
if
it
goes
down
what's
expected,
is
that
the
the
auto
Agora
indexer
service
that
rapper
should
just
throw
away
the
throw
away
the
data?
Maybe
I
should
test
it
just
to
be
sure,
but
because
I
implemented
this
quite
a
while
ago,
but
it
should
throw
away
the
data
we
can
try.
All
this
mentioned
on
ongoing
test
net
or
you're
encouraged
to
use
it.
Actually,
if
you
want
to,
you
know,
show
that
you
can
generate
revenue
on
the
test
net
the
better.
B
E
B
So
that
makes
sense.
The
problem,
though,
is
that
we
don't
get
to
choose
which
press
model
is
applied
because
it's
the
Gateway,
so
you
would
have
to
change
your
your
the
price
Model
that
you've
declared
for
the
subgraph
to
the
to
Agora,
to
the
Gateway,
sorry
and
and
then
it
would
just
switch
all
traffic
to
to
that
model
it.
B
Basically
all
traffic
goes
through
the
model
right,
that's
the
problem,
so
only
solutions
I
could
see
is
running
two
indexers,
though
it
seems
that
it's
in
the
rules
of
mips,
that's
not
good
or
manually,
turn
it
off
and
on,
but
yeah
there's
not
really
a
solution
right
now,
because
the
Gateway
is
doing
the
pricing.
It's
not
us.
E
B
B
C
C
But
now,
as
we
saw
in
the
announcement,
it
was
like
for
graph
note
or
graph
queries
for
queries
now,
so
we're
now
wondering
if
we
opened
their
exact
port
for
that
for
this
phase.
Zero
of
this
Meep
test
net.
So
there's
still
a
question
and
it
depends
tomorrow
so
that
I
believe
that
was
didn't
was
asking
about,
because
the
first
there
were
instructions
to
open
the
graph
node
on
Port
8000
and
later
we
found
out
that
probably
a
query
node
was
has
to
be
open.
Yeah.
B
B
B
But
it's
still
group
the
graph
node
software
and
the
query
node,
which
is
also
the
graph
node
software,
is,
is
turned
into
just
a
query
serving
mode
and
they
both
talk
to
the
same
database
as
to
opening
the
query
node,
that's
probably
for
debugging
purposes,
because
in
the
in
production
you
don't
want
to
open
this
because
you're
not
going
to
get
paid
for
queries
that
go
directly
to
the
graph
node
queries
have
to
go
through
the
indexer
service
for
them
to
for
you
to
be
paid
right.
So.
C
Yes,
that's
absolutely
clear
for
us
that
one
endpoint
is
for
serving
page
queries
and
another
for
debugging
purposes
and
accessing
queries
directly,
but
the
question
I
think
we
still
that
is
about
this
place:
zero,
which
endpoint
we
are
at
the
open
because
it
wasn't.
It
was
very
clear
if
we
want
if
we
need
to
open
the
debugging
endpoint
or
the
paid
one.
B
So
basically,
Auto
Agora
will
only
care
about
the
indexer
service.
If
that's
also
the
question,
because
that's
the
payment
layer,
whatever
goes
through
graph,
node
we're
ignoring
completely,
and
that
has
also
advantages
the
advantages
that
we
can
rerun
queries
if
we
wanted
to
and
they're
not
going
to
affect
our
data
sets
because
we're
gonna
We
would
bypass
the
indexer
service.
So
that's
the
very
reason
why
we're
getting
that
data
from
the
indexer
service
but
yeah
in
terms
of
what
should
be
open
or
not.
I'm,
not
quite
aware.
B
So,
under
stress
with
enormous
amount
of
queries,
would
Agora
help
to
serve
them
better
or
on
the
opposite,
make
things
worse
due
to
additional
computations
I
mean
it
depends.
What
machine
you're
running
on
I
guess
in
deck,
the
autograph
processor
could
end
up
using
quite
a
bit
of
resources,
but
you
would
need
a
huge
amount
of
queries.
We've
tested,
a
single
autograph
processor
can
go
through
10
15
queries
per
second,
no
problem,
I,
don't
remember
which
limits
we
said
in
our
kubernetes
cluster,
but
they're.
B
Very
small
I
think
it's
one
CPU,
each
and
and
500
Megs
of
ram,
but
even
that
that
amount
of
ram
was
Overkill
we
can.
We
can
lower
it
so
yeah,
yeah,
I,
hope
that
tells
us
that
answers
the
question
but
in
our
particular
case
we're
running
in
Google
Cloud.
So
actually
you
can
see
in
the
diagram
that
here
the
reason
why
I
put
you
know
those
stacked
rectangles
is
that
you
can
Mo.
You
can
run
as
many
autograph
processors
as
you
want.
B
So
if
it's
not
going
fast
enough,
so
first
of
all,
if
you
don't
want
to
have
impact
on
your
system,
just
run
the
one.
If
it
can't
take
all
the
queries,
then
some
are
going
to
be
thrown
away,
and
that
way
you
limit
your
impact
to
500
Megs
of
RAM
and
and
one
CPU
right.
If
you
wanna,
if
you
don't
wanna,
throw
away
data
for
the
training,
then
run
multiple
autograph
processors.
B
If
you
can,
if
you
can
scale
if
you
can
afford
to
scale
in
our
case
for
our
setup,
we
can
afford
to
scale.
It's
just
gonna
ask
for
more
VMS
from
Google
cloud
and
it's
okay.
But
it's
up
to
you,
though,
but
once
again
the
the
impact
of
all
the
auto
Gore
stack
is
small
compared
to
the
query,
node
and
the
indexer
service,
and
all
that.
So
it's
about
maybe
an
order
of
magnitude,
less
right.
B
B
But
eventually
the
the
load
is
going
to
go
through
the
indexer
service
right
You
Gotta
test
this,
because
there
is
a
lot
more
involved
with
the
indexer
service.
Basically,
whenever
you
have
the
indexer
service
on,
then
you
also
have
the
proper.
You
know
the
actual
Gateway
code
running
on
the
other
side
and
there's
like
payment
channels
and
Etc
so
yeah.
Eventually,
that's
going
to
be
turned
on
because
there's
a
lot
of
components
there
that
have
to
be
tested,
Etc
at
least
I-
would
expect.
F
B
A
All
right:
well,
if
there
aren't
any
more
questions,
then
I'll
take
this
opportunity
to
wrap
up
today's
conversation.
Thank
you.
Alexi
for
presenting
this
was
highly
informative
and
I
hope
it
wasn't
the
same
for
everyone
here
too,
as
we've
established
throughout
the
the
presentation.
This
will
be
recorded
and
put
onto
YouTube
it'll,
be
there'll,
be
a
link
to
the
mips
playlist
where
it
will
be
posted
and
also
there
is
a
link
to
the
presentation,
then
a
chat
and
that
will
also
be
shared
after
as
well.