Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
[E1] Sonic Builder's Hour with Marcus Rein from The Graph
Recorded: March 28, 2025 Duration: 0:42:05Space Recording
Short Summary
Sonic Builders Hour kicks off with a focus on The Graph's integration, showcasing new features like the Token API and emphasizing the growing trend of decentralized indexing solutions in the Web3 space.
Full Transcription
nice
hey everyone
welcome to welcome to sonic builders hour this is the inaugural episode with marcus rain from
the graph i'm seg from sonic and i'll be hosting this every week on Friday, variable times depending on our guests and our availability.
But every Friday you can watch for a tweet from my X account and we'll have this spotlight, if you will, of builders on the Sonic ecosystem.
Sonic ecosystem. And the idea is to basically allow for the infrastructure providers and different
projects that are building on Sonic to showcase their products and to showcase how they can
interoperate with other products on Sonic and that kind of thing. And then also, if you have any
questions throughout the episodes, you can submit them under under the the live stream post and then we might get to
those and we might get to those offline uh depending on on uh how things go so the flow
of these will be relatively casual but the idea is to sort of spotlight our builders and and give
them a platform to showcase what they're what they're up to so this week we have marcus from
the graph as I was saying.
Awesome. So thanks for being here, Marcus. Good to be here.
Amazing. So we just wanted to start off really quickly with most of you devs.
If you're if your builders tuning in, you'll know what the graph is.
And a lot of devs I know have voiced their preference for the graph over other indexing solutions and other, I guess, adjacent solutions as well.
And I wanted to start with that, really.
Why is it, do you think,
that the graph is selected by many, many builders?
What do you provide that other indexing solutions don't?
And maybe you could start that off
with what exactly indexing provides for developers
in case there's some junior ones
that don't know what it is
and why should I use indexing instead of an RPC?
Yeah, I mean, that's a lot of questions inside there.
Let's unpack that.
So essentially, indexing provides your front end
with a performant experience.
If you are building in Web3
and you want your DAP to feel performant on the front end, you can go ahead
and do RPC calls all the time, but eventually that's going to get bogged down. It doesn't scale
super well. So indexing that data really allows you to have organized databases that from there
you could send your queries to and then from there have a front end that's really, really,
really snappy. That's really nice just for user experience.
And so that's where the graph steps in.
Now, in terms of where this sits within the greater scope of Web3 is the decentralized
indexing part of this, where, sure, there's many competitors out there that are all building
quality products and they are centralized.
And so what you're doing is if you choose a competitor,
you are choosing a centralized option that has all of the same problems that a centralized option
has. Vendor lock-in, you're able to have, if you have a certain feature that only they have,
and that's it, and then you're locked in. And so we are doing our very best on Web3 to move away
from that. And that's where the graph really steps in so in terms of what the
graph can do for daps out there it really provides another way that is super performant affordable
and very flexible for your dap to scale and to move away from calls to an rpc and actually move
to a more thought through and database driven solution.
Very nice. Yeah, I feel like efficiency of your calls
is one major aspect of indexes like the graph.
And then also, I know that a lot of developers say
that the feedback that I've gotten
is that they're just used to the language,
the query language and all that kind of stuff
that the graph provides.
So that's really good.
I guess one question I have is,
what is the state of the graph's integration with Sonic?
And what can builders do to start leveraging it on Sonic?
Yeah, well, if we go ahead and want to go ahead and build with Sonic and say,
hey, are we actually able to check out, you know, supported chains and see the integration?
Yes, Sonic right now is available to be indexed by the graph.
And so it is Sonic mainnet.
And so we can actually go ahead and play around with that today and just index a smart contract and see what that's like in terms of the workflow today right on screen.
Amazing. Perfect. So yeah, I think let's, if you want to start off and share your screen,
we can, we can get into that. Yeah. Awesome. Let's go ahead and yeah. Also,
if there's any questions, feel free to drop questions in chat. I'm happy to just discuss
essentially the, any questions anyone has, feel free to drop it in there. So I'm happy to just discuss essentially the,
any questions anyone has, feel free to drop it in there.
So I'm gonna go ahead and share my screen.
Let's see.
Okay, and sharing the screen.
So let's get DND on and we are off.
So let's talk about the graph.
And so one thing I want to announce real quick is we have a new feature called Token API,
where if you not only want to get indexed smart contract event data, but you actually want to get token balances, token transfers, wallet information, that is a brand new beta
that we have right now.
So not only decentralized indexing we have but we also have
the ability to get lots and lots of data on tokens so feel free to check that out let's go into
uh the graph as a whole and really what that means for sonic and as well as other chains out there
but really just going to focus on sonic the bottom line is y'all got, let's go to Sonic right here.
Y'all got a lot of things going on.
There's a lot of blocks.
There is a lot of transactions.
There's a lot of smart contracts.
And so feel free to dive into the data like this,
and you can go ahead and find everything you'd like through the Explorer.
It is cumbersome, and that's really where the graph comes in,
where wouldn't it be nice if this was organized
in a customized way,
as opposed to just in a search bar kind of way?
This is fine, but we need a little bit more.
So what I typically like to do
is when I go into a Explorer and say,
hey, well, what more information would we like to get?
Let's go ahead, excuse me,
and look at some of the top accounts in Sonic right here
and say, all right, well, we've got some of these.
And what we want to do is take a look at contracts.
Make this bigger for everybody here.
This contract has a lot of transactions.
And typically with a lot of transactions,
we're going to get a lot of data
that we can index and organize.
And that's something that's typically pretty good.
So token is good to check out right there.
That's a good one.
There's a lot of different ways that we could look at token.
We could look at, you know, we could look at a DEX.
We could look at so many different things.
And so just for the sake of demonstrating today, let's see if we can go to verified contracts.
One thing when you're indexing is you do want to make sure that you have verified smart contracts
because you could actually have the subgraph, which is the customized API, point to data that I could actually index.
If it's just bytecode, if it's not verified, it's going to have some difficulty with that.
So let's go ahead and see what the top accounts are right now on sonic and seg if you have any suggestions of smart contract that you'd like
to dive into uh feel free to throw it out right now live i'm fine to go with that but we're just
going to look at this right here the ws token and i believe there would be some good information here
just to demonstrate great choice good and a few things I like to check here are the contract itself.
That checkmark means it's verified.
That means the subgraph is going to be optimized for it.
And then just become aware of the smart contract.
If you're looking for events, look for emit, at least on the older Solidity.
Newer Solidity doesn't need that.
But yeah, these are the events that we're indexing.
Smart contracts, events, if you ever see,
come on, events.
There we go.
Like this approval event or a transfer event.
This is the good information that a subgraph can index.
Now, if you need more than event data,
subgraphs can do that.
They're a little bit limited in terms of that.
They can do calls.
They do, of course, use a node. And for that,
that just slows things down a little bit. Ideally, you're just getting your stuff from the events
that really make sure your subgraph is optimized and fast. You want to have your indexing be fast,
your querying be fast. We'll talk more about that in a little bit. But yeah, make sure as much as
possible events. And if you really need to push into other bits of data on the smart contract, look at
substrains.
It's another product that we offer that allows you to get all of the data from the smart
contract, not just the events, but you're looking at mempool data, you're looking at
internal transactions, basically everything.
So that's a different way of building.
But just know smart contract events, that's what we want.
So we've got the smart contract. We've some events and let's zoom out and let's go ahead and build this thing live
uh let's go to thegraph.com
and seg i can't see you but if you want to talk feel free i'm just looking at my screen here but
if there's anything going on feel free yeah no i took myself off to give you more real estate but
yeah this is great.
Like great info for the builders.
I think our team is really excited about this as well.
Awesome.
So yeah, we'll get started with Subgraph Studio.
Now Subgraph Studio, almost like YouTube Studio.
It's kind of where you could build privately
and make sure that things are how you like them.
And it's a rate-limited environment
meant for iteration and testing.
If you want to make it public and open data, it takes away the rate limiting. So that's one thing to know
when you go ahead and get started. That is a thing. So we'll sign in here.
And we're going to make a baby subgraph. And we're going to use the CLI to do it. So we'll call it SEGS subgraph.
All right, this is yours, buddy.
I feel special.
Yes.
And so here's really the studio team did a very good job of going through this.
But essentially what we have here is the dashboard,
and we're preparing our subgraph to be open data.
This is open public marketplace.
And we could put in description if we want.
We don't have to because we're developing the source code.
Essentially our GitHub repo of this subgraph because this is a very customizable project.
And then the website in which the data is being pushed into.
You know, if you're sending queries to this subgraph,
where are they coming from?
And this is all helpful for people in the marketplace
to take a look at.
And if we want to put that in, we can,
but we will not because we're just simply
going to scroll down to Sonic.
There we are.
Okay.
So if you have not yet installed the graph CLI, Yarn, NPM, PNPM, or Bun, the logo.
Just quickly, Marcus, make sure that's the right Sonic because there's another Sonic that is using our name.
Oh, no.
Yeah.
I don't know if that's the logo.
That's correct.
Yeah, that's your logo.
There's one on Solana.
I just didn't know if it was the correct one.
Okay.
Great, great.
Perfect.
Yeah.
No, that's a great ping right there.
And let's see, Manta.
It might be under EVM if you have an EVM section.
Let's see.
Yeah, this is good for our builders to know as well.
There is a, you should make sure you select the right chain.
Yeah, I did not know that.
That's funny.
Solana accounts.
It does look like a logo.
Yeah, that is the logo.
Yeah, we're just going to go with it.
Great, great, great.
Thanks.
And let's go ahead and copy paste right into the terminal.
So what I'm going to do here,
let's go ahead and CD into project,
desktop and projects and make dir,
segs, sub subgraph cd subgraph and clear and let's make this big big
big big big so everyone can see okay so we're in this new folders nothing in here seg subgraph
and we're going to graph init now graph cli is the tool where we can create a subgraph locally
on our machine and we're going to go
ahead and do Sonic mainnet. So cool. Now, if you are trying to index a smart contract, that's
possible. If you want to go ahead and index a sub streams, which is another product, essentially
they're doing the indexing, the sub streams is doing the indexing, and we can actually have that
data organized in a subgraph. Essentially, it's a pipe. It's a workflow. That's totally possible, too. And then also,
we can take a subgraph and push that data into another subgraph, and that's possible. We're
actually working on that feature right now. So it's pretty cool. We're only going to be doing a
smart contract. So let's take a look at that. We'll go ahead and use the regular slug and the
same directory. Totally fine. And now let's go ahead and find that contract address that we wanted. Okay. Here it is. This contract and
there it is. Okay. So let's go ahead and drop it in. And right here, this is cool. The ABI is
required. Essentially, if you don't. The ABI is required.
Essentially, if you don't know what ABI is,
essentially that takes English, like numbers and letters,
and translates that to low-level languages,
basically zeros and ones that the computer can understand.
So we need that ABI to translate our words into computer words.
It pulls that in from the scanner, from the Sonic Block Explorer.
It also gets the contract start
block wherever it was deployed, because if you index from the Genesis block all the way till now,
the smart contract likely wasn't deployed at the Genesis block. It was deployed somewhere in the
middle. And so this is where it was deployed. And then also just for good experience, it brings in
the contract's name itself. So it automatically does that. If it ever doesn't do that,
sometimes that's the Explorer
maybe hitting a rate limit.
We work with lots of different block explorers
and sometimes they have different API rules.
Just go ahead and go into the Explorer itself
and you can get this information very well.
Also a little shout out
to something that I've been building as well.
Let's see, it's the NPM Canna, the contract analyzer. So this is a little tool
that I recommend for builders out there. Any EVM compatible chain essentially is able to
work with this and you just drop in your Block Explorer API key and the Block Explorer endpoint
and you can go ahead and get a lot of data about the smart contract at first without actually indexing it.
And that really does help.
You can get the deployment start block if for whatever reason things aren't working.
You can get the ABI, event signature, proxy detection, a lot of cool stuff with this.
It's a little CLI tool that I've been working on.
So anyways, contract name pulls it in. And this is a cool part. Index contract events as entities. Any event
that has been emitted by that smart contract from the very beginning of its deployment all the way
to this very second will be converted into entities in our database. So the events are like logs,
and they're just kind of hanging around on the blockchain, just keeping track of what's going on. And then the entities exist as entities in our database,
in the subgraphs database. And so this is where we have that database-driven kind of thinking,
where we're not going ahead and find specific locations on the blockchain to get data.
This does it for us, and it brings it all into one location, and then that makes things very performant.
So do we want to add another contract?
No, we'll say false.
And we can run through this.
You could run through GraphAuth
to authenticate your local system
and make sure it can communicate
with the graph itself.
I've already authenticated my computer,
so I'm not going to do that.
And then we just CD into the subgraph.
And we just do yarn deploy
and actually just deploy this dang thing.
So this is already a subgraph.
It's already spun everything up for us.
We're going to go into that code in just a second
just to see what it's actually doing.
But I wanted to get this working on the backend
while we do that.
Very nice.
So this subgraph has been deployed.
The API is ready to go.
We already have an endpoint and we're ready to go.
So we could just start building from here
if we know subgraph development very well,
but I like to actually look at the code a little bit more
and kind of go through what is actually happening.
That's kind of important.
And so let's go ahead and do that right now.
So what we did is we did the graph init command
and that spins up this code right here.
This is the CLI spinning up this code.
The main files I'm going to pull up right now
and we're going to go through them one by one,
essentially looking at the path of how the data
starts from chain and goes into the Subgraphs database.
And then from the Subgraphs database,
we're going to be able to send queries to it
and get that to our front end.
And we're going to go through that full pathway right now.
So any questions, Seg?
Are we doing good?
This is amazing.
A large amount of information, but very digestible.
I think our builders are going to love it.
Keep going.
Cool.
Cool.
I'm very happy.
If anything, feel free to interrupt too.
Like I said, I can't see you.
So if you're flagging me down.
Definitely will pop up and interrupt you.
Perfect.
Awesome.
Perfect.
So these are the three most important files in any subgraph.
The subgraph.yaml, the file inside of the SRC folder.
We typically just call it the mappings file.
It will change its name based on the contract name.
If you put in the contract name in the CLI,
it'll change its name.
If you don't put in the contract name,
it'll just say mappings or contract.
That's what it'll say.
But this is the mappings file.
And then from there, the schema.graphql.
Let's go over essentially how the data flows from chain to our database.
All right, so this is looking at the chain.
It does some magic here, and it goes into our database.
That's all we're going to go over today from a high level.
So we have this information that is brought together mostly by the magic of the CLI.
The only thing that we really need to think of the subgraph.yaml for,
I like to think of it as like a bullseye
to find a smart contract
and tell our subgraph where to go.
It tells us what chain.
It says Sonic.
It says that this is a data source, first of all.
This is the network.
It's Sonic.
It tells us the source.
The actual source is the actual smart contract address.
It names the ABI that's there.
It names the start block.
Once again, we're getting a bullseye
onto where we want to go.
And then we, let's skip the mapping just briefly right now.
It gets the ABI.
Remember I told you that ABI is what translate English,
what we're looking at here,
to zeros and ones that a blockchain
or any computer can really understand.
We need that ABI
because that's going to translate the smart contracts, zeros and ones to our language and
our language back to zeros and ones. So that's very important. And then now let's go ahead and
look at the mappings and event handlers. So let's say we're indexing the smart contract. And in this
smart contract, we did see a transfer event. And so we see a transfer event here and we see a
transfer here. Let's go ahead and break this down what we're naming here. In this CLI, in this graph
CLI, it has spun up event handlers. Essentially, when you have an event coming from the chain,
we'll call this the transfer event, comes from the train. Anytime a transfer event triggers, it triggers this little
thing to fire and the handle transfer handler is fired. Boom. So it says, hey, if this event comes
in, it passes it into the handle transfer. And we're not saying what the handle transfer will
do. It just simply says, they're just naming it here. This is once again, the bullseye, it triggers this. And once it resolves, it will push this
into our entity, into our transfer entity in the database. So to review that again,
an event comes off chain, it triggers the handler in our subgraph, and then it deposits the data
into our database. So, and it just simply names it exactly
as it should be named one-to-one.
We have an approval event coming from the chain.
It triggers the handler inside of our subgraph
to do logic, to do whatever it wants to do.
And then it handles that data
and then it pushes it into, uh-oh,
into the approval in our database.
And this has already been built for us.
So let's go ahead and see with this transfer event,
how is it triggered?
How does it handle the data?
And then what data is actually being pushed
into this database, into the transfer database?
And to do that-
Mark, one quick question.
Just for devs to understand,
I guess from the source of this flow
that you're describing.
So is this data being populated then from an RPC initially
and then afterwards it's being used
to be able to use the graphs products
or is that how you get the initial data?
Yes, the initial data is an RPC.
And then once it's gathered, it's all in the subgraph.
We have to use an RPC.
We are doing our best to abstract that away over time simply because an RPC is relying
on infrastructure that is, you know, once again, potentially might go up, might go down.
We're not sure.
So we're working on a technology called Firehose that's already in production that abstracts
it away.
So we have a much more stable location.
But once that data is indexed, we have it in there and we're ready to go.
Amazing.
Yep. So great question. So now let's go ahead and dive into, let's just zone in on the transfer. There's something from the chain, it triggers this, and it goes into our transfer
entity. So how do we do that? We've got the bullseye in the subgraph.emo. We'll go to the
wrapped sonic. These are the mappings and how it does some logic. And so we'll go to the Rapsonic. These are the mappings and how it does some logic. And so we'll go into
the transfer. So here we are. We have an event and it's of the type, the transfer event. So we pass
that in and that is coming from chain. Boom. We got that event data and cool. And then it passes
into the handle transfer function. We're already triggering it. It comes right in. It's not actually
returning any information. It's just void. We're not bringing anything back.
This is simply just running through code and passing it into a database.
And so we see right here, we have a new entity in our database.
And basically here's the same pattern.
If you click on entity, you'll see how much this database is referenced right here.
Entity, entity, entity. We're just touching the database everywhere.
And then from here, you could see how much the event is actually listed. Event, event, event, event, event, event.
So we're taking essentially this event data and we're just passing it right into the database.
And we have the event from, and we have the event to, we have the event value. And in our database,
we have the from, the to, and the value. And this is the handler. All it's doing is passing the data in directly from chain.
This is also where people get super, super creative.
Because what you have in this location is a way to be quite creative with smart contract
data to process it ahead of time.
So your front end essentially has more valuable data on the very first query.
So there's a lot of things that you could do
in these handlers.
Let's say you have a withdrawal event
that has some interesting data
and a transfer event that has some interesting data.
And you want to create a new handler
that actually pushes to more different locations
in the database.
You can do that.
You could say export function handle new.
We're going to call it a new entity idea.
And so we can bring in different events.
We can bring in different pieces of data.
We could say different events and different pieces of data
and actually do the logic here.
We could actually have enums the logic here. We could
actually have enums at the top. We could enumerate things. We can go ahead and do calculations in
here. It's a really fun area that you can start to see where data is and actually bring it into
one location. If you want to bring in off-chain data, you could do off-chain. If you want to
bring in data, let's say you have an upgradable contract and you have many different smart
contracts and you want one subgraph to do all of them.
You can do that here where essentially you're just simply linking to all the different smart contracts.
There's a ton of logic that you can do right in this area.
And there's tons of. Yeah.
Question markets about about this and a little bit of Sonic's philosophy as well.
Like we're trying to be because we're such a fast chain.
We have pieces of ux experience
sort of locked down from the network uh perspective but then we also want builders to be
uh leveraging tools that will enhance user experience in terms of snappiness in terms of
uh data availability and all that kind of stuff so like how does this uh how can builders that
are currently using rpcs for example to do of this stuff, and maybe the front ends are super slow in terms of loading all this disparate data from different places,
how can they use this kind of thing to enhance their user's experience?
Great question.
I'm going to answer that at the end that I'll talk all about optimization.
And I'll just put a point on that where we're not building static code here.
This is code that has data passing through it super fast.
And if any code is unoptimized, it completely slows down the whole process.
So there are, excuse me, there are optimizations that are super critical that are, if you just
do like two or three of these optimizations, or at least keep them in mind as you build,
it's going to completely change the way that actually you interact with these smart contracts.
So, but yeah, we'll get to that.
All the different optimizations right now,
just think right here,
this is a lot of creativity in this area.
And I could show you some example code
of all the different stuff that can be done.
So once we have the transfer,
remember we had the transfer here, we just simply passed it into a single entity into our database.
This is just one transfer event.
One transfer is a from, to, and value.
Who's a from, who's a to, and how much?
And also, when was it?
The timestamp, the block number, the transaction hash.
We got some metadata.
We pass all of that into this single transfer that happened on Sonic, and then we have it in our database. So with all of that being said,
let's go back to Subgraph Studio and say,
Hey, let's take a look at our subgraph. Very nice.
So it's indexing right now and we're getting lots and lots of data and we've got some progress.
So we'll go to playground and here we can create some GraphQL queries
and send some queries and get some data back. Let's go ahead and just look at our transfer event.
I do like this point and click interface.
Transfers, if we want a single transfer,
this is our database basically.
The Explorer explores our database in our subgraph.
We want a lot of transfers.
Let's look at the first 100 transfers.
We'll get the ID of the entities in our database and we'll look at the first 100 transfers and look at the ID of the entities in our database.
And we'll look at the from, the to, and the value of these first 100 in the database.
And there we go.
So we have from 0000, and then we go to this address and we have this value.
And so this is how we begin.
We could do some filtering, we could do some logical operators, and we could dive into our database in this way. So this is a fun way to kind of get to know the workflow. You go ahead and point the subgraph where you want it to go. You go ahead and do some logic. You go ahead and from here, arrange the database. There's lots of relationships you could do here. There's more techniques. You can even do calculations here. You want to do aggregations.
There's so many techniques. It's bananas. That's how customizable this is. Basically,
there's a zillion features in here and a zillion features in here. If you have any questions,
reach out to me and I can see, I can kind of coax you and get you into the right features
that you're needing because there's a zillion check out the docs.
And then from there, you're in the playground and you could create the queries.
Let's say you have a query that you like.
You take that query and then you will go ahead and send it to an endpoint and say, hey, here is the endpoint right here that I could send a query to.
And if I use React and XJS,
we already just basically get it ready for you.
Now, this is all the development environment,
version 0.0.1.
Let's say I make a change to the subgraph.yaml,
or let's say I add a new feature.
Instead of do start block here,
I do start block, let's change it to three.
Let's just change this.
Let's say that's a new feature or something like that.
Well, that's cool. Let's go ahead and three. All right, let's just change this. Let's say that's a new feature or something like that. Well, that's cool.
Let's go ahead and go back to here,
and we'll do not code, but we'll do yarn deploy.
It'll compile this again, version 0.0.2,
and we have a new version.
And this is how developers can work with subgraphs. It's just kind of this tinkering kind of mentality
and saying, hey, there it is, 0.0.2.
It's going to start over indexing.
And from there, the entities are going to populate in the database.
And from there, we can just see, hey, did our things work?
Do we have some logs?
And how are we getting our data from our smart contract?
Let's say it's getting thousands of pings every minute and lots of different interactions
with it.
We need to make sure that we're thinking of edge cases,
thinking how can we get that data to our front end?
Maybe we wrote the smart contract
and didn't think of one thing,
but we need that data from a different...
This is where we can have a lot of creativity
and a lot of play time with smart contracts.
So I'm going to stop right there
and see if there's any questions before I go into some optimizations talk and some other features talk. Would that make sense?
their front ends are taking 10 plus seconds to load various pieces of data using raw RPC calls
that they're processing afterwards. And then I feel like this could benefit them quite a lot.
So I think that part would be really interesting. And then, yeah, whatever else you have to share,
we'd love to. Sure. We'll go right into it. Best practices. So these are all designed for optimization. Like I said, this is not static code. It is any bit of lack of optimization will slow things down. So Sonic developers should definitely know these best practices. saying, hey, do you really need all of the data from the initial start block of the smart contract
all the way up until now?
What that's doing is making the database size huge
and it just takes longer to get data.
If you send a query, it's going to take, you know,
extra second or two potentially to get that.
If you only need the last, let's say, 100,000 blocks
and that's all your users are really interested in,
and let's say you want to create a cache
for any specific data that you really wanted.
You can do that.
But pruning allows you to keep the index and keeps the database small.
So I'd recommend using pruning if you're able to and keep things tidy.
Another thing here is really focused on database size is using derived from essentially in your database.
on database size is using derived from,
essentially in your database,
if you have two different entities
and you're creating relationships between those
and you do those in a non-performant way,
you might be duplicating data.
And everyone knows if we duplicate data,
that's not performant.
And that once again creates database bloat
and slows everything down
in terms of query responsiveness.
So that's a really, really big one for speed.
This is a huge one.
We have one of our senior engineers test this one a few years back.
He's the one that worked on this.
Shout out to Lutter.
He created this, and essentially this brings as much data possible to the bytes type, and
that's using IDs as bytes and going ahead and using immutable entities, which eventually will convert also into bytes.
Basically, we're trying to convert everything
into the lowest level language possible
so computers can process them faster.
And so if you can use immutable entities,
which means you're not going to change
the database's entities,
that's good for like logs or just any data,
use them, and then bytes as IDs. The more
bytes you use, basically, the faster it'll go, just in general. But if you are going to use them,
IDs are great as bytes. And just the entities, if you're not going to change them, bytes,
that's great. Another one, avoid ETH calls. So if you're going to be making a call to a Sonic node or any node that's relying on them,
you're not relying on your database anymore. You're relying on a Ethereum node to get that data.
And that might take half a second, two seconds. And it's not from a database that is optimized.
It's literally you're making a call to a specific location on that smart contract,
you're making a call to a specific location on that smart contract, and it's relying on external
hardware. And so try to limit that. If you have to do them, there is a thing called declared ETH
calls, where essentially once you do them once, you get that data and you store it in a cache,
it can help performance, but ideally you don't use them. So next one, time series and aggregations.
This is not only just a feature, but it's also
a performance enhancer where if you're wanting to do compute over a set amount of time, every hour,
every day, this is time series and aggregations, and it's been found to actually improve performance.
Now, I'm not exactly, I wasn't part of the testing on this one, but I do know that it was
a solid chunk of performance improvements. So take a look at this, you get calculations and also things go faster.
So this is a twofer here.
And this one is not really for performance.
This is just a good tip.
If you have a lot of data indexed already,
and you need to make a change to the subgraph,
and you don't want to lose all that data because you might
have to start all the way over if you're thinking you do,
you don't have to start all the way over.
You could do what's called grafting.
And essentially what that does is takes that database that you've created and
indexed and allows you to graph the subgraph on top of that and keep it going. So you keep all
that data safe as you continue developing. So that's going to be something good for a fast
chain. If this is all not fast enough, you're just scaling like crazy and you need more speed,
I'd check out Substreams. Substreams is another technology that follows a very similar type of pattern to this, where we
point at a smart contract, we do some logic, and we put it in a database. I would check out
substreams. It's a little bit more advanced, but it is fast. It is faster than a subgraph.
So Sonic, I would say, look at substreams and even
substreams-powered subgraphs, where you can take very fast indexing and take that substream and
push that data into a subgraph. And that's a possibility. Substreams can also go into
a SQL database. They can go to a lot of different locations. They're quite flexible.
So Marcus, real quick on substreams. So we've actually had some developers on Sonic who've
been interested in the concept of Substreams. Do you mind just very briefly explaining how
they're different from Subgraphs or how they interplay with Subgraphs or what improvements
they have? Sure, absolutely. And just real quick, if you want to get started with Substream's
development, I would go to this repository, and it is very well done. I will drop this in chat with
you. Seg, where are you? There you are, StreamYard, and I'll drop this in chat. This is the substream starter. This is a great resource to get going with them.
And essentially what substreams are
is parallel indexing where subgraphs are linear.
So that's just the biggest difference
where substreams can do many locations at one time
where subgraphs cannot.
I'm not sure if Sonic is supported right now with substreams.
I'm not really working with substreams a ton.
So I'm sorry if this is like getting devs excited to try with substreams. I'm not really working with substreams a ton. So I'm sorry if this is like getting devs excited
to try out substreams.
Let's just put a big asterisk here
and I'm not sure if that's fully supported,
but we are working hard to support
as many changes as possible with substreams.
So check that out.
And essentially substreams are faster
and get lower level data possible on the blockchain and get all the way, like I said, down to internal transactions.
And some developers need that, which is great.
And then from there, if you want to push that data into a subgraph, you can.
Or if you want to put it into a SQL database, you can.
It's more flexible. So we look at substreams, I mean, this metaphorically,
but it's more for like enterprise kind of solutions
that are needed.
Funny enough, Sonic might just be,
just because it's so fast,
might be on that edge of a regular developer
needing a subgraph if it's a relatively simple smart contract.
But once it gets a little bit more complex,
they might just need to go over sub streams.
This is something that I would like to get some feedback from you guys
and be like, hey, try subgraphs.
If they just can't keep up, regardless of how optimized they are,
that's good information for me to have.
Definitely, yeah.
I'll definitely get that and talk to some builders
about what their experience has been.
Cool. Awesome.
So that's essentially it.
We've got our uh segs sub
graph we are able to send some queries in and we're able to get the data back and we have this
nice json object and from there we can take that and uh put that into our front end however we want
so there's a zillion ways to go about this and just because of the variability, I'm just going to try to keep it simple
and just say, hey, go to the docs,
see what you can do, have some fun.
It is free to develop in Subgraph Studio.
So develop to your heart's content,
figure it out and see what you like.
And then from there,
let's go ahead and keep on talking.
You can find me on Twitter
and I'm always happy to talk with developers,
phone call more than happy to chat with teams,
get them started, answer their questions.
Just because the amount of customizability
in everything here,
it's like, just think very customizable pipes
to help your front end be very responsive.
That's exactly what the graph is doing.
Yeah, and responsiveness is sort of
the thing I was harping on earlier.
So devs, if you're not using tools like this
to enhance your users experience,
you should probably look into using tools like the graph
because it just makes things snappier.
I feel like we need a, we always say this,
we need a web two like experience in a web three world
in order to get a bunch of
conversion from uh from i guess the the more non-crypto crowd if you want to call it that and
to sort of distribute to the next quarter this is over overused but the next billion people and to
do that you need good ux snappy ux and uh sub graphs and and the graph is doing a great job promoting that for our devs.
So thank you.
Cool.
Yeah, happy to help.
And if there's any devs out there
that want to reach out to me, feel free to reach out.
Happy to come into wherever you guys are hanging out
in Discord and just have a Q&A,
just anyone out there that's building.
We want to be involved with your process.
So let us know. And from there,
we can get you guys accelerating in the right direction.
Amazing. So Marcus, do you, thank you so much for that.
I think if there's any questions that anybody else has, we can,
we can address them offline there. I think for now, what we'll do is we will
conclude with whatever you want to, you said a few things, but if you want to plug anything,
and then we'll end here. And then also with respect to the actual onboarding, you mentioned,
just to recap, people can go to the docs uh it's free to start and um you
have two products right now subgraphs and substreams uh and uh and yeah if you want to
shout out anything plug anything and then thank you so much for being here yeah yeah awesome and
yeah and the token api is the last thing it's a beta that we have out right now so if you know
subgraphs do very well with smart contract data.
They're not the best for specific token data and then also for wallet data.
And so we have that API right now.
So go ahead and check out our website
and look for the token API beta
and go ahead and sign up
and see how the graph can really provide
smart contract data, wallet data,
where we're really pushing hard on all this.
Amazing. Thanks, Marcus.
So just to recap for our builders who are watching right now,
we will host this every week on Friday.
It's going to be a spotlight from an infrastructure provider
or a builder on the Sonic network
that has interesting products
that you might want to interoperate with or use.
And so please tune in every Friday.
It'll be on x.com slash 0xseg, my Twitter account.
And yeah, watch out for the Builder's Hour.
It's going to be a recurring thing from now on.
And thank you, Marcus, for being on our inaugural episode.
Really appreciate all the info.
And these are, yeah, nuggets of gold.
Our team was watching the whole thing and a bunch of our,
even internally, they're super excited about the info you delivered.
And I'm sure a lot of them are like itching to build now with the graph.
So this is cool.
Thank you so much.
Awesome.
Happy to help out.
And as always, I'm on Twitter and Telegram.
Feel free to reach out.
Happy to help.
