►
Description
Timestamps and Info:
Developer Highlights #2 | “Building ambitious subgraphs” Part 1
Sebastian Siemssen & Ivan Herger | Enzyme Finance
For the second Developer Highlights, we get to speak with Sebastian Siemssen & Ivan Herger.
Ivan and Sebastian are long time members and developers in our community and have been working on subgraphs for Enzyme Finance (formerly Melon Protocol) for more than 2 years. They are going to share the challenges they faced and the lessons they learned along the way. In this episode we’ll explore some of the more demanding event tracking, data aggregation and scaling requirements of a DeFi subgraph and the patterns and solutions they came up with to solve them.
This is the first of two parts. You can find the second part here:
https://www.youtube.com/watch?v=4V2o5YJooOM
00:00 Episode overview
02:54 Enzyme Finance - Protocol overview
09:43 Enzyme Finance - How subgraphs are used
17:06 Enzyme Finance - How the subgraph performance have increased
19:39 Smart Contract Design - Write events with data retrieval in mind
23:18 Smart Contract Design - Upgradable contracts (proxy pattern)
25:40 Schema Design - Build the schema close to the data Requirements
27:11 Schema Design - Limitations to filter and sort
30:21 Schema Design - Low/High level data
32:22 Schema Design - Upgradable Protocols
33:58 Pagination - Capabilities and limitations
38:23 Pagination - Exactly-once Guarantees
40:38 Pagination - Counting
42:01 Avoiding Fatal Errors - About
45:03 Avoiding Fatal Errors - Try/catch
49:25 Avoiding Fatal Errors - Don't throw exceptions
51:06 Avoiding Fatal Errors - nonFatalErrors
54:02 Avoiding Fatal Errors - Required properties in the schema
55:55 Mappings - Save/Load performance Impact
00:57:20 Interfaces - An often missed feature
00:58:40 Interfaces - Union Types
01:00:45 Interfaces - Type Field
01:02:41 Interfaces - Entity Utils
The Graph Webpage: https://thegraph.com/
The Graph Discord https://discord.gg/vtvv7FP
The Graph Forum: https://forum.thegraph.com/
A
C
B
And
then
we
will
go
a
little
bit
into
some
of
the
subgraph
design
patterns
and
subgroup
definition
tricks
that
we
use
to
to
simplify
our
development
for
local
development,
testnet
development
and
mainnet.
So
things
like
templating
in
the
subgraph
manifest
and
design
patterns
for
the
subgraph
around
pagination,
filtering
and
error,
handling
and
graph
graphic
schema
design,
and
also
some
of
the
performance
tips
that
we
learned
about
while
working
on
our
subgraph,
which
is
quite
big
and
has
grown
over
time
significantly.
C
All
right
shall
we
get
started
with
the
demo,
go
ahead,
okay,
so
so,
basically
yeah,
so
we're
we're
enzyme
finance.
The
enzyme
protocol
was
formerly
known
as
the
melon
protocol.
The
company
behind
it
was
previously
called
melonport.
Then
there
was.
It
was
a
renaming
into
enzyme.
A
few
months
ago
we
launched
version
two
of
enzyme
which
has
many
new
features
and
I'll
just
quickly
kind
of
walk.
You
through
some
of
the
features.
A
C
Tell
you
what
what
do
we
do
so,
basically,
enzyme
allows
anyone
to
set
up
a
vault.
A
world
contains
assets
that
you
can
manage,
so
you
can
trade.
You
can
invest
into
various
d5
protocols.
We
basically
link
together
many
and
even
more
in
the
future.
Defy
protocols
and
the
interesting
thing
is
you:
can
you
can
trade?
So
you
can
do
all
of
that
for
for
your
own
money,
but
you
can
also
do
it,
for
you
manage
money
for
other
people.
C
You,
you
kind
of
go
along
with
that,
and
that's
typically
for
people
who
don't
who
want
to
be
invested
in
in
these
kind
of
vehicles,
but
don't
have
the
time
or
they
know,
know
how
to
do
trades
themselves
so
like
in
typical
in
traditional
finance.
You
have
funds
where,
where
you
can
invest,
you
have
mutual
funds.
Where
you
can
deposit
your
money
and
then
there's
a
manager
who
supposedly
knows
more
than
you
and
they
create
a
profit
for
you
basically,
and
so
that's
very
similar
here.
C
C
It
always
starts
with
a
vault
manager.
Somebody
who
sets
up
a
vault
defines
parameters
of
the
vault,
and
I
can
quickly
show
you
some
details,
so
everybody
can
just
log
in
with
their
ethereum
wallet,
they
can
create
a
wallet,
a
vault
define
cert
parameters,
I'm
just
going
to
click
through
some
of
that.
C
C
C
You
can
look
through
the
different
funds,
see
what
performance
they
have
see,
what
assets
they
have
and
then
you
can
select.
The
fund
funds
can
also,
you
know,
describe
what
they
do
in
select
the
fund
you
can
deposit
into
the
fund.
You
can
deposit
ether.
Every
fund
has
a
denomination
currency.
You
can
deposit
that
into
the
fund
and
once
as
an
investor
as
a
depositor,
once
you
deposit
it,
you
don't
have
to
do
anything.
The
fund
manager
will
do
the
trading.
They
will
look
at
the
market,
see
what
what
opportunities
there
are.
C
C
The
fund
manager
can
so
the
assets
that
are
belong
to
the
vault
are
in
a
smart
contract.
Indeed,
the
fund
manager
can
do
certain
actions
with
them,
so
they
can
trade,
they
can
invest
into
lending
protocols,
they
can
stake,
they
can
take,
it
can
do
certain
actions,
but
they
cannot
just
take
away
the
assets,
so
basically
the
assets
are
safe
and
the
manager
just
manages
the
assets
and
typically
also
a
vault
has
fees.
C
C
C
But
yeah
that's
the
number.
Currently
a
fund,
a
volt
has,
can
have
20
assets,
20
different
assets
at
any
one
time,
but
of
of
all
those
assets
you
can
have,
you
can
have
millions
billions
of
dollars
in
each
of
those
assets,
so
the
the
volt
volts
can
be
as
big
as
as
ethereum
or
the
the
tokens
the
assets
on
ethereum
can
be.
C
Right
so
that's
the
general
overview
and
now
maybe
quickly
to
what,
how
we
use
the
graph
or
where,
where
the
graph
comes
in,
and
maybe
here
a
little
bit
of
history.
So
this
is,
we
call
it
version
two.
It's
actually
probably
version
three
or
even
version
four
of
of
the
front
end
to
the
protocol.
So
we
started
with
a
we
started
with
a
very
simple
front:
end
that
for
all
for
everything
that
was
shown
made
on
chain
calls.
C
But
you
were
not.
We
were
not
able
to
do
historical
to
display
historical
data
and
for
funds
for
vaults
being
able
to
display
historical
data
is
very
important,
so
you
want
to
see
what
what
the
vault
has
done.
For
example,
you
want
to
be
able
to
to
track
the
performance,
be
it
in
the
in
these
kind
of
graphs
charts.
I
should
say:
charts
not
graphs
here
or
in
terms
of
monthly
performance
of
a
vault
that
that
needs
more
data.
C
C
It's
basically
all
the
data
that
is
displayed
here
comes
from
a
sub
graph,
so
all
those
charts,
that's
data
that
is,
is
stored
in
this
upgraph.
Those
return
numbers
the
assets
daily
changes.
Let
me
show
you
a
few
other
things.
Each
volt
has
kind
of
financials
there.
They
all
come
from
the
subgraph
there's
various
depositors
list
list
of
depositors
when
they
you
know
when
they
deposited
their
money.
First
trades,
that
a
vault
has
done
all
all
of
that
is
captured
in
the
subgraph.
C
So
it's
not
as
simple
as
I
would
say,
as
as
a
as
an
exchange,
for
example,
that
trades
asset
a
for
asset
b
at
a
certain
price,
and
it's
always
the
same.
I
mean
we
do
that
the
trades
happen
here
and
we
we
monitor
that,
but
there's
a
lot
of
different
parts
to
the
protocol.
So
there's
there's
depositors,
there's
managers,
there's
trades
that
can
be
done.
C
There's
lending
there's
investments,
redemptions,
there's
policies,
all
of
that
flows
together
and
in
in
order
to
manage
all
of
that
and
to
display
and
to
have
an
interface
that
that
works,
and
that
is
that
is
functional
and
and
fast.
We.
We
really
rely
a
hundred
percent
on
sub
graphs,
there's
one
exception
where
we
don't
rely
on
the
subgraph.
Whenever
we
do
a
tr,
a
a
transaction
or
whenever
we,
the
user,
is
going
to
do
a
transaction.
C
We
fetch
on-chain
data
just
before
the
transaction,
to
make
sure
that
all
that
all
the
data
that
is
submitted
for
the
transaction
is
the
latest
on
chain
data,
so
that
we,
you
know,
sometimes
that
the
sub
graph
can
have
a
little
lag
in
in
syncing,
and
there
may
have
things
been
things
that
could
have
happened
in
the
last
block.
So
we
want
to
make
sure
that
we
are
kind
of
up
to
date
whenever
we,
whenever
we
submit
the
transaction.
B
B
C
B
C
C
C
B
B
B
Obviously
that
doesn't
scale,
because
if
you
have,
for
instance,
200
assets
and
all
of
them
can
update
at
various
times
over
over
the
period
of
a
day,
for
instance-
and
we
have
let's
say
500
volts,
and
then
you
have
to
iterate
200
times
over
500
volts
that
doesn't
stay
right.
So
what
even
meant
when
he
said
that
we
need
to
marry
two
two
series
of
data
or
two
streams
of
data
is
that
basically,
we
are
merging
the
time
series
data
for
prices
and
for
state
changes
on
the
volts
to
calculate
these
charts.
C
A
B
B
B
Changing
operation
on
any
contract
must
have
a
event
that
goes
with
it
and
that
carries
as
much
data
as
much
relevant
data
as
possible
in
such
a
manner
that
in
the
subgraph
mappings
first
of
all.
Obviously
we
can
react
to
all
of
these
things
granularly,
but
also
so
that
we
don't
have
to
then
fetch
data
in
addition
to
what's
sent
to
us
through
the
event
payload.
B
So
that's
the
number
one
rule
and
the
process
starts
really
early
on
now.
So
whenever
a
new
architecture
is
being
built
for
our
smart
contracts,
we
communicate
back
and
forth
between
the
developers
of
the
app
who
are
also
building
the
subgraph
and
the
smart
contract
developers
to
ensure
that
everything
that's
required
is
there
already
before
we
send
off
these
contracts
to
the
audit.
B
So
that's
that's.
That
was
a
really
important
lesson
for
us,
because
doing
this
has
made
it
so
much
easier
for
us
to
build
our
subgraphs,
and
it
has
made
it
even
more
obvious
that
this
is
important
when
we
were
integrating
with
external
protocols
and
also
starting
to
index
events
from
external
protocols
where
these
rules
were
not
followed
and
certain
events
were
either
lacking
data
or
weren't
existed
at
all.
I
will
talk
about
an
example
without
calling
out
any
names
here.
B
I
want
to
make
that
show
like
we're,
not
trying
to
shame
anyone
here.
It's
just,
I
think
that's.
The
graph
has
become
such
an
important
development
tool
in
on
ethereum
or
in
general,
on
blockchains,
for
smart
contract
development
in
general
that
it's
it's
now.
Actually,
it
has
transformed
the
way
that
we
should
build
our
smart
contracts,
or
maybe
it
has
amplified
that
the
need
for
these
considerations
when
building
smart
contracts,
because
events
should
be
there
anyways
right,
especially
for
any
state
changing
operations.
B
B
That's
especially
the
case
if
they
that
proxy
pattern
is
not
built
around
delegate
calls.
So
the
new
contract
that
is
actually
pointed
at
with
the
proxy
contract
is
is
stands
on
its
own.
Basically,
and
we
have
had
this
experience
when
tracking
our
price
data
so
because
our
price
prices
come
from
chain
link,
oracles
and
the
chainlink
oracles.
The
chaining
aggregator
contracts
are
proxies
that
point
at
the
actual
underlying
aggregator
contract,
and
they
don't
have
an
event.
B
B
B
Yes,
okay,
yeah
yeah,
so
yeah.
So
it's
what
I'm
trying
to
say.
I
guess
is
it's
really
important
that
you
prepare
all
of
the
data
all
of
the
entities
that
you're
indexing
in
your
subgraph
with
all
of
these
features
that
you
want
to
build
on
the
front
end
in
mind
you
have
to
you
already
have
to
be
aware
of
what
you're
trying
to
build
because
you
are.
B
You
are
a
bit
limited
in
in
in
comparison
to
a
handcrafted
graphql
api,
where
you
can
control
the
resolvers
with
logic
right
when
you're
building
a
graphql
endpoint
a
graphql
server
yourself.
You
have
control
not
only
over
the
data
it
accesses,
but
also
over
the
logic
that
accesses
it,
and
so
you
have
ability
to
write.
C
C
Can
I
maybe
what
I'd
like
to
add
one
one
thing
that
you
mentioned
in
the
beginning
to
to
kind
of
have
your
use
case
in
mind:
to
have
your
basically
your
front
end
in
mind
and
and
build
entities
for
that.
So
what
we
do
is
we?
Basically
we
we
monitor
all
events
and
we
track
all
the
events
we
track.
Basically,
everything
that
is
is
ever
emitted
and
we
kind
of
call
that
our
low
level
low
level
data
we
we
track
that
mostly
for
debugging
purposes.
C
So
if
something
goes
wrong
or
we
don't
understand
what
what's
happening,
we
can
we
can
look
at
that
data,
but
at
the
same
time
we
also
have
this.
These
high-level
data
so
like
evolved,
like
an
investor
like
a
trade
which
which
kind
of
combine
various
events
or
combine
over
time
combined
data
of
various
events.
So
we
have
this
kind
of
high
level,
those
high
level
entities
which
which
we're
ultimately
interested
in
which
we're
all
ultimately
displaying
so
many
it
is.
B
It's
important
because
the
users
of
your
application
do
not
care
about
how
your
your
underlying
data
is
structured.
They
do
not
care
about
also
if
this
was
a
traditional
app,
they
wouldn't
care
about
your
database
layout.
They
don't
care
care
about
rows
and
talents,
they
just
care
about
their
features
and
so
designing
it
with
the
feature
in
mind
and
not
with
the
data
representation
in
your
back
end
in
mind
makes
a
whole
lot
of
sense.
B
One
other
thing
that
comes
to
mind
here
actually,
is
you
know
how
you
mentioned.
We
have
these
low-level
data
structures
and
then
we
have
the
high-level
data
structures.
This
is
also
important
for
us,
because
our
protocol
is
upgradable,
and
so
new
versions
of
the
same
protocol
might
have
completely
different
data
structures
and
completely
different
event
signatures,
but
we
cannot
start
from
scratch
whenever
we
release
a
new
version,
because
our
vault
managers
they
care
about
their
track
record,
they
care
about
the
history
and
the
depositors
do
so
too.
B
B
So
even
if
these
lower
level
data
structures
change
the
more
high
level
aggregated
data
structures
need
to
stay
intact,
they
need
to
stay
compatible
with
several
versions.
At
a
time
it
might
mean
that
there
might
be
new
fields
and
some
of
these
entities,
some
new,
some
other
fields,
might
get
deprecated
over
time,
but
in
general
the
shape
stays
intact.
B
A
B
B
And
I'd
argue
that
in
a
normal
user
interface,
that
is
a
perfectly
fine
limitation
because
well,
you
do
not
regularly
paginate
through
6
000
records
manually
on
the
front
end,
but
you
might
have
a
use
case
where
you
need
to
pull
data
to
fetch
it
for
some
other,
like
data
warehouse
requirements
that
you
have
to
further
than
process
that
data
to
analyze
it
or
whatever,
and
in
that
case
you
might
want
to
find
a
way
to
scrape
the
entire
data
set.
That
might
be
millions
of
records.
B
B
B
B
B
But
this
enables
me
to
to
achieve
this
at
least
one
consideration
here.
Is
that
and
that's
really
important,
because
when
you
are
doing
polling
to
fetch
or
sorry
when
you're
doing
data
scraping
like
this,
you
want
to
have
something.
That's
called
exactly
once
guarantees
and
exactly
once
guarantee
means
that
every
data
record
that
you
receive
from
such
a
query
is
only
fetched
once,
but
exactly
once
at
least
once,
but
at
least
once,
but
maximum
also
only
once
right
exactly
what
and
with
the
example
that
you're
seeing
right
here,
where
I'm
fetching
based
on
the
timestamp.
B
Let's
assume
that
record
999
record
1000
and
record
1001
all
share
the
same
timestamp
now,
because
I'm
only
fetching
1000
items
here
record
1001
would
not
be
included
in
my.
In
my
current
result,
data
set
and
now
when
I'm
in
the
subsequent
query,
I'm
asking
for
every
item
with
a
timestamp
greater
than
the
last
one
that
I
previously
fetched.
I
would
basically
exclude
a
record
from
from
the
next
data
set
from
the
next
1000
items.
This
would
otherwise
be
perfectly
valid
and
would
belong
into
that
response.
B
In
this
case
it
would
mean,
for
instance,
if
you
are
tracking
raw
events,
that
you
use
a
identifier
here
that
is
made
up
not
only
of
the
block,
timestamp
and
maybe
or
the
block
number,
but
also
of
the
transaction
index
and
the
log
index
within
that
transaction.
If
this
is
for
a
raw
event,
so
it
would
be,
it
would
have
to
be
something
that
is
100,
unique
and
incremented
a
related
issue
here.
Is
you
don't
you
do
not
know
how
many
pages
you'll
actually
have,
because
there's
no
such
thing
as
counting.
B
The
only
way
to
do
that
is
to
already
count
at
the
time
of
indexing,
although
that
is
rather
challenging.
If
you
want
to
also
consider
cases
where
you
are
deleting
records,
or
maybe
where
you
are
overriding
existing
records,
so
counting
is
currently
a
pretty
tough
challenge.
If
you
want
to
get
it
right
and
hence
you
do
not
even
know
really
how
many
pages
there
are.
B
A
B
C
B
You
don't
want
that
because
that
will
cause
your
subgraph
to
terminate
it
will
not
shrink
anymore
unless
and
I'll
come
to
that
I'll.
Get
to
that
there's
a
new
feature
that
will
get
you
that
will
allow
you
to
continue
to
simply
subgraph,
but
basically
using
log.critical
or
any
other
way
for
holding
the
subgraph
in
case
of
an
unexpected
condition
is
an
anti-pattern
by
all
means.
If
you
want
to.
B
If
you
want
to
to
be
on
the
safe
side,
and
there
is
a
condition
that,
for
one
reason
or
another,
you
cannot
predictably
exhaustively
cover
with
all
of
the.
If
classes
in
the
world
then
add
a
default
fallback
case
and
maybe
a
warning
message
so
that
you
can
still
catch
it
in
your
logs,
but
so
that
at
least
the
subgraph
doesn't
fail.
B
In
our
case,
the
subgraph
currently
takes
a
couple
of
days.
I
think
actually
we're
now
on
a
little
bit
faster
infrastructure.
So
it
might
not
be
the
case
anymore,
but
it
used
to
take
a
couple
of
days.
I
know
that
the
unisworks
soft
graph
takes
several
weeks
to
synchronize,
so
a
fatal
error
on
that
subgraph
would
be
pretty
bad.
A
B
B
We
actually,
we
actually
using
helper
functions
for
interacting
with
erc20
contracts,
because
they
are
so
quirky.
Sometimes
you
know,
erc20
is
such
a
loose
spec,
really
only
the
transfer
functions
and
balance
off
and
total
supply
are
part
of
the
spec
and
all
of
the
other
things,
like
name
and
symbol,
and
even
the
decimals
are
not
strictly
in
the
spec,
and
even
if
some
of
these
esa
20
tokens
out
there
use
them,
some
of
them
have
a
slightly
different
abi
or
slash
different
interpretation.
B
So
it's
really
important
that
first
of
all,
you
use,
try
catch
so
use
this.
Try
underscore
prefix
for
the
generated
smart
contract
code
here
and
whenever
that
reverts
either
fall
back
to
a
default
value
or
consider
this
token,
as
an
invalid
token
or
yeah,
and
and
that's
also
really
important,
like
the
name
standard
in
some
some
cases,
you
also
then
get
bytes
as
a
return
value
for
the
name.
B
So
then
you'll
want
to
also
try
that
call
with
a
different
api
and
see
if
that
returns
something,
but
in
all
cases,
as
you
can
see
here,
we're
not
critically
logging.
This
out,
we
are
using
a
default
unknown
name
in
that
case,
we're
doing
the
same
for
the
symbol,
we're
doing
the
same
for
the
decimals
there's
actually
another
subgraph.
B
B
All
of
these
things
are
not
guaranteed
to
actually
be
there
and
in
our
protocol,
where
we
are
interacting
with
hundreds
of
different
esa
2010
tokens,
they're
all
hated
from
a
different
time
period
and
a
different
interpretation
of
usc
20.
Apparently
these
issues
might
happen,
so
it
would
suck
if
you
have
a
subgraph
that
takes
several
days
to
run
and
to
synchronize,
and
then
you
run
into
a
failure
like
this.
B
A
A
B
B
This
is
like
the
single
source
of
truth
on
the
blockchain
events.
They
happened.
They
they
are.
They
are
true,
no
matter
what
so
throwing
an
exception,
because
you're,
presumably
thinking
that
oh
yeah
you're,
presuming
presuming
that
there's
an
error
with
the
data
itself.
That's
not
that's
not
a
thing,
there's,
no
invalid
data,
so
every
possible
scenario
has
to
be
called,
especially
if
your
subgraph
is
slow
and
synchronizing.
C
A
C
B
Yeah,
so
I'll
show
you
maybe
what,
where
we,
where
we
did
this
incorrectly
in
the
past,
I
think
it's
here
in
division
selector.
Yes,
so
we
have
a
function
here.
That
has
a
lot
of
different
if
and
else
cases-
and
we
were
under
the
impression
that
this
list
is
an
exhaustive
list
and
we
can
predict
all
of
the
different
cases
ahead
of
time
and
that
wasn't
true.
That
assumption
was
incorrect.
B
So
what
we
had
here
in
the
last
line
was
actually
a
critical
error
that
we
were
logging
out
here
and
then,
when
we
deployed
a
new
feature
on
onto
our
protocol,
our
subgraph
instance
failed
because
none
of
the
previously
documented
cases
here
actually
recorded
also
because
there
was
a
typo.
But
the
point
is
there:
wouldn't
have
been
any
harm
by
just
returning
unknown
here:
logging,
a
warning
message,
maybe
and
yeah
then
just
continuously
syncing
the
subgraph
and
then
fixing
it
while
this
imperfect
data
set
was
out
in
the
wild.
B
B
This
would
have
saved
us
in
this
case.
So
what
this
feature
does
is
it
whenever
there
is
actually
a
critical
error
in
one
of
the
mappings
instead
of
outright
failing
the
subgraph
and
stopping
the
synchronization
process,
it
just
flags
the
subgraph
as
having
indexing
errors,
and
then
you
are
free
to
choose
in
your
queries.
B
B
C
B
B
B
B
So
in
this
case,
what
we
do-
and
this
is
a
common
practice
like
every
other
subgraph-
that
I
browse
on
github
and
they
all
have
this-
I'm
just
mentioning
it
anyways.
So
what
we
do
is,
instead
of
just
exposing
the
entity,
object
itself
and
directly
interacting
with
it
in
all
of
our
mapping
code.
We
are
creating
these
helper
functions,
other
teams
call
them
get
or
create.
B
B
This
is
really
important
because
it's
it
just
yeah
makes
it
so
that
you're
not
accidentally
interacting
with
an
entity
object
that
in
fact,
doesn't
really
exist
yet
or
it
doesn't.
It
prevents
you
from
simply
through,
like
error
by
repetition,
in
one
of
your
mappings,
to
forget
one
of
the
properties
that
are
actually
required
and
then
trying
to
save
the
entity
without
that
required
property,
yeah
yeah.
B
Actually,
in
doing
several
saves
in
the
same
in
the
same
mapping,
the
the
graph
node
has
a
caching
layer,
so
there's
no
performance
loss
for
synchronization
whenever,
like
you're
doing
save
several
times
in
the
same
transaction,
so
you
don't
have
to
optimize
around
that
same
with
loading.
If
you
can
avoid
loading
entirely,
it
does
actually
give
you
a
small
performance
benefit.
So,
for
instance,
if
you
do
not
need
previous
values
from
the
entity
to
construct
the
next
state
of
that
entity,
you
can
actually
skip
the
loading
process.
B
B
Those
are
the
most
common
ones
and
then
yeah
when
designing
your
subgraph
schema.
One
thing
that
seems
to
be
missed
a
lot
of
times
we
have.
We
have
actually
explored
quite
a
few
of
the
subgraphs
that
are
open
and
open
source
on
github,
and
we
are
at
this
point
making
a
lot
of
use
because
you
know
we
are
building
our
subgraph
high
level
features
also
in
mind.
We
are
using
a
lot
of
interfaces.
We
are
using
using
a
lot
of
union
types.
B
B
More
advanced,
primitive
types
like
big
end
and
big
decimal,
provided
by
graph
tiers
the
graph
syntax
is
it
offers
much
more
than
than
just
plain
types,
so
enums,
for
instance,
also
quite
interesting
and
useful.
We
are
making
quite
a
bit
of
use
of
interfaces,
and
these
and
these
types
so
check
them
out.
B
So
this
field
is
actually
not
in
the
introspection,
so
you
don't
really
see
it
directly
in
the
graphql
explorer,
but
you
can
query
it.
It's
the
type
name
right.
Actually,
let
me
fetch
something
that
has
an
interface
so
yeah,
let's
go
through
the
event
interfaces.
So,
let's
try
and
load
all
of
the
events.
B
So
you
see
all
of
these
different
types.
Those
are
the
concrete
implementation
types
of
whatever
entity
is
yeah.
This
is
or
lies
behind
that
that
and
that
interface
that
we
are
creating
here
and
then
what
you
can
do
is
you
can
actually
narrow
down
on
those.
So
if
this
is,
for
instance,
a
new
fund
created
event
or
actually,
let's
say
fee
enabled
for
function
down
here,
then
you
can
narrow
down
and
fetch
the
additional
values,
as
you
can
see
here
right.
So
interfaces
are
quite
interesting
and
yeah.
B
Then
this
is
really
useful,
but,
as
I
mentioned
like
the
underscore
underscore
type
name
field
is
not
exposed,
for
instance
in
filtering,
so
you
couldn't
do
like
a
fetch
for
only
certain
certain
types
of
these
right,
so
it
is
useful.
I
don't
know
if
we
do
it
actually
in
this
case
here,
because
we
don't
have
a
use
for
that.
C
A
B
A
B
If
you're
interested
in
further
understanding
like
what
we
do
with
these
different
entity
types,
then
we
actually
have
some
utility
functions
around
those
like
this
one.
Oh
yeah,
yeah
price
kind
of
look
better,
for
instance
yeah.
So
we
are
creating
custom
custom
entity
classes
here
that
are
not
automatically
generated
and
then
based
on
the
type,
as
you
can
see
here,
we're
actually
directly
interacting
with
the
store
interface
so
that
we
are
saving
into
the
right
entity
based
on
whatever
type
is
created
for
us
yeah.