The Graph 🛠 Full Stack Web3 Development with The Graph - Simon Emanuel Schmid

Hello everyone. Quick question for the audience. Who among you knows what The Graph is? Okay, then we'll do the introduction . Who has already written a subgraph?

OK. And who has already written a smart contract? Okay, that's better. And who plans to write a smart contract? Cool smart contract?

Cool . Great, that's good. Okay, that's good. So, my name is Simon. I am a solutions engineer at Edge Node.

This is one of the main development teams working on The Graph protocol. Today or tonight I will show you how to use The Graph. This time I decided to start the presentation with what you can get you can get if you use The Graph, we have two directions. The first one is the best new subgraph. This is the first thing we will look at.

The best one will get $2200, or up to $800. And you can also use existing subgraphs. There are many of them. I'll show you where to find them. And because it's much easier, the reward is a little less.

So I would say the strategy here is: if you are a good developer and want to get a bigger reward, then you will choose that, but it takes more time. Whereas when using an existing subgraph, competition may be higher, but we'll see. The thing is , many hackers usually start with Remix. Who uses Remix to develop smart develop smart contracts? Yes.

Especially beginners use Remix first before moving on to more complex tools like Foundry, Hardhat, etc. So I'll quickly show you how to do it in Remix you how to do it in Remix . So when you're in Remix, you usually create a new workspace, and let's say we're creating an NFT. NFTs are cool. It may be a little outdated now, but we can still make one, and it's cool.

You can just start with a template and then say, "Okay, I want mintable, burnable, pausible, well, whatever." And we don't need the ability to update. I believe that smart contracts should, if possible, be atomic and immutable. Well, cool. That's all.

Next, you just click " just click " OK" and it generates this token for you. You have this feature, so you can pause it or mint it, and because it uses the OpenZeppelin standard, I can say, "Yes, this is now Simon's token, ST," and when I save, it compiles in the background, creates all this, but eventually you finish and you want to deploy it. So, let's move on to the Goerli network. You simply indicate that you want to use the built-in provider, click “deploy”, sign the transaction, and the contract is deployed. So, the contract is already deployed, almost ready, right?

It's Sunday morning and you're thinking, "Okay, I want to build an interface on top of this." I don't know who tried to get data from a smart data from a smart contract via JSON RPC providers, but in my opinion it's a bit messy. I can show you what it looks like. That's it. You write code where you create loops, make these callbacks back and forth, and try to retrieve data.

And if someone has 10 NFTs with this code—and I've seen this code in real life—and each of those requests to the JSON RPC endpoints takes 200–300 milliseconds, you're easily gaining 3, 4, or 5 seconds of load time for your site, right? This is not cool at all. So, we have a detailed contract. This is very cool. Now you need to verify the contract; This is very important.

I never interact with contracts that are not verified. I mean, you never know what's out there, right? So how can we use this in Remix? There is a plugin called "flattener". If you don't see it here , just search for "flattener."

Click "activate", then go here and simply select " and simply select " flatten my contract". And now, all the collapsed source code, that is, all the imports in one file, appears on your clipboard. Now I can just go here, it works pretty much the same on any network. This can be done on Polygon, Mainnet, or Mumbai. You just click "verify and publish."

Next, you paste the contract address here. Compiler type—Solidity ( Compiler type—Solidity ( single file). The compiler version is usually 0.8.0.

You can check here which version you need and specify the MIT license. And then we go ahead and just insert the code that we have in this object. You confirm that you are not a robot. Oh, shoes. OK.

Check and publish. And then your, um, your smart your, um, your smart contract will be verified. Perfectly. Hmm, cool. And now you are really ready.

Oh, cheat sheets. Can I cheat sheets. Can I ? So, she has cheat sheets that help you, uh, with these steps to remember. So please raise your hand please raise your hand if you want one.

And now the next step: you actually want to have a subgraph. So, we have a smart contract. It is verified. And we now want to have a subgraph that I can use. You want to have a cool and beautiful graphics API.

I want to have something like that . I want to have a GraphQL API to retrieve my data. This is very wonderful. All front-end developers know this is the right way to go. OK.

So, what should I do? I'm going to thegraph.com. Oh, wait. Another browser, thegraph.

com Another browser, thegraph.com . When you are on the Goerli network or Ethereum mainnet, you select Subgraph Studio here select Subgraph Studio here . If you're on any other network: Polygon, Mumbai, Celo, or Optimism, you're going to a hosting going to a hosting service. But since we're in Goerli, we're taking Subgraph Studio.

So, I'm going here. Um, usually you connect first. I want to show you all these steps. So, you connect, you select Metamask, a pop-up appears, you log in, you sign up. That's all.

You are here now. You create and then say that you actually want to create a subgraph. So, you click "Create Subgraph". Um, you say what network you are indexing. It was Goerli.

So, Goerli. What should I call it? I call it, um, NFT. Nothing special. OK.

Continue. That's all. Now that you are here, there are instructions on what you can or should do. It's the same as in a cheat sheet. So in a cheat sheet.

So , you should install the Graph Protocol CLI globally, and then, yeah, and then you can say ` graph init--studio Simon's NFT `. That sounds interesting. So let's do this. Now here's the secret. I also wrote this in the cheat sheet, but the secret to a quick start here is in the `--index-events` command.

OK. This is a magical thing that helps you get started quickly. OK. Now come on, let's do this. Now we have a great dialogue, so let's walk through it: what protocol are we using?

Um, The Graph supports Arweave, NEAR, Ethereum, well, or something EVM- Ethereum, well, or something EVM- compatible, and also Cosmos. But we are here for Ethereum, this is an ecosystem hackathon ecosystem hackathon , so—Ethereum. Um, the subgraph name is already here, we don't need to invent anything, we just take it. Then the directory, that sounds good. Next I choose a network, I take Goerli, right?

Now I need the contract address, the contract address—here it is, you can just copy and paste it. And I hope it works. We are checking. Okay, I'll try again. Yes.

OK. Sometimes you just have to try twice. It will take some time for the API to become available on Etherscan. But yeah, if it doesn't work, there's this rule: if it doesn't work—turn it off and turn it on again, right turn it on again, right ? Okay.

So, this is Simon's NFT. Just give it a name and—boom, the subgraph is automatically created in the background. Now we don't really need to do much. We don't need to understand how to write a subgraph, how it works, what the scheme is, or anything what the scheme is, or anything else to get started. We can just follow the instructions here.

Go to the directory, you can do this in a new window while the installation is in progress. Then we... actually, we authenticate. We need to upload the API key so we can deploy. So I do that—and now the deployment key is installed, and in the background everything is already installed.

He asks if I want to add another contract, but that's enough for us, let's just continue. That's all. And now I can just say: graph deploy. Actually, I need to change something here, and I can just do a graph deploy to the studio. I simply followed the steps that are written here and which are also in the "cheat sheet".

I press Enter. I need to give a version name. Let's say one. And—boom, it's deployed. That's all.

Now I can go here and open this here and open this URL, and here I have a graphical interface. Unfortunately, there is a small problem now: if you just follow the steps I took, one small element is missing, and we can fix it together. So, eventually, the subgraph will start indexing, but we can speed up the process with this little trick that I'm going to show you now. So, we can just look at the code and the subgraph; Essentially, the main thing you're interested in is the manifest interested in is the manifest , i.e.

subgraph.yaml. The trick here is that everything is already set up for us, but we need to add a start block so that the graphics node in the studio knows where to start indexing. So how do you find the starting block? We look at the transaction where the contract was deployed contract was deployed , check the block, and simply copy it.

OK. Boom. Save. And re- deploy. Now this is version two.

Well, let's see what the studio thinks about it now. Hooray, it's fully indexed. So, that was better. Now we can also go here, there is also a " here, there is also a " playground" here. Perhaps the most interesting thing about NFTs is the transfer events, right?

So the platform is cool because it helps you, there's a graphic guide here. We don't have to understand everything in detail. You can just click here and say I'm interested in transfers, maybe I want to get the sender ID, recipient ID, and token ID, and it will build a GraphQL query itself. You don't even need to know GraphQL in detail, but if you have frontend have frontend developers on your team, they know how to do it, and then you can send a request, and oh, we don't have transfers we don't have transfers , but this is a new contract. If you're in Remix, it's very simple.

You can just leave...where is he? Here. This. Thank you.

I don't usually use Remix. I need help. So what I can do here is press mint. I'll just say: okay, I'll mint an NFT. I'll copy the address, take the token ID and send it.

Boom. I'll check on Etherscan to see if the transaction went through. It will probably take some time. Steeply. This is the easiest way.

You can quickly get started with a subgraph. You don't need to know very much about it. You can simply follow these steps. I repeat: you go to Remix, deploy the contract deploy the contract , verify it, then go to The Graph Studio or a hosting Graph Studio or a hosting service, log in , create a subgraph, and go to the terminal. And it's very important here, where this...

important here, where this... Here it is: graph init--index-events. And this will create a subgraph framework that has an entity and automatically generated mappings for each event in your smart contract . and you can just get started. Me, I think the transaction should be included.

So, we return to Subgraph Studio. We send the request again and see our transfer event here . It's very easy. Now you can start. You have a detailed contract.

You have a subgraph. You have a GraphQL interface. Now you just need to write a little frontend and you're basically done. You can go home and enjoy the partying in San the partying in San Francisco, maybe on Saturday night. But yeah, there's probably a lot more to it, and we can delve into that.

So, for those who don't know what The Graph is, I'll quickly explain the theory, now that we've seen the practice. When you think about data on the blockchain, we now have state, for example, NFTs; you can think of it as a Google spreadsheet where there is a token ID and an owner. So, the blockchain always knows who owns which NFT. What about the origin story? Who owned this NFT before?

We know that blockchain is a system with transactions that are superimposed on each other. We should know this, but getting old data is not easy, you have to "dig" into it. It would be nice to have a kind of time machine where you could just go back in time and see how the owners changed the owners changed . This is where The Graph helps. Originally, the idea for dApps, decentralized applications, was that you have a frontend in JavaScript, HTML, and CSS, deployed on IPFS or another decentralized storage that communicates directly with the blockchain.

The problem here is that the blockchain is optimized for writing. You pay miners to add your transaction, but how does reading from the blockchain actually work? Theoretically, you could communicate with a node you run at home. But the question is, who runs an Ethereum node at home? Oh, yes, some...

Yes, you can communicate with this node, but the JSON-RPC interface through which you do it is not really designed for building a frontend. It is designed to manage a node, possibly sending transactions and performing validations performing validations . And, besides, there are no incentives if you don't run the node yourself. Who will provide you with this data then? I mean, of course, there are centralized providers that provide access to JSON RPC endpoints, but that wasn't the idea of ​​a decentralized system.

So as a result of retrieving the data, you get something like this. So, the modern architecture of a decentralized application looks like this: you have a frontend that writes data to the blockchain. It works. This is cool. And when you want to read the data, you use an indexing protocol like The Graph, which provides decentralized access to the data.

The Graph network has now been running on the Ethereum mainnet for a year, and you can have fully decentralized subgraphs there. This is something we created earlier, and the point is that you pay per request. Pay-per-request provides an incentive structure for data delivery. Well , that's what The Graph is, you know, the API for this decentralized future. Oh, where are we future.

Oh, where are we ? The Graph currently processes about 1 billion requests per day on its hosting service. That's quite a lot. And, you know, big users like Uniswap, Audius, Unlock Protocol, and others use it. Teller too, by the way, but these two already operate on a decentralized network.

And now, a year after launching the decentralized network, you have 224 independent indexers around the world. They index your subgraph and participate in the network thanks to incentives: they receive fees for queries and rewards for indexing. And that makes the system redundant, right? If one indexer fails, another one is ready to handle your requests. And it gives you fast, cheap, and reliable APIs in a decentralized way.

This connects us through a global open API where all data is available to you data is available to you . Yes, so we can have truly decentralized applications. We briefly touched on the topic of subgraphs. So, essentially, all these transactions are a mess, you know, piled on top of each other, and the subgraph creates these focused databases where you can specify exactly what you want to see. So if you're writing a subgraph for your particular contract or protocol over the weekend, you're just saying, "Okay, I'm interested in this contract, this event, and this transaction."

This is how I want to store my data, and it will be there. Otherwise, it would be very difficult to retrieve this data , so you have full control over what data to store and how to do it, and then you can simply query it later. So, that's pretty much how it works. So the dApp on the right—we see how we record transactions on the blockchain. Blockchains get them; they generate events in, in what?

For NFTs, these are transfer events. Um, they are generated, and then the graph node is configured to index these events or receive them. Then you run the mapping code, which can also be improved. If you want to get a price for the best new subgraph, you really should improve your mappings, not just do what I did. But it's a good starting point that will be stored in the database.

On the other hand, on the left, you see how you send requests that go to this GraphQL API and are served by a graph node. This is roughly the architecture of the system. Yes, actually, this is what it looks like. So you have this chaos of subgraph data, and eventually it magically gets organized, and you have a very clear idea of ​​what's going on. Class.

Now, if you want, you can scan the QR code and tweet that you just learned about Graph. Or not. Okay about Graph. Or not. Okay .

So, you want... Now the pressure from the environment begins. Class. Um...Yeah, we already did that, these subgraph things.

But we can actually dig a little deeper into the code. We barely touched on subgraph.yaml, which holds it all together. In subgraph.yaml you define which chain you are interested in, which address you want to index, which starting block, which ABI.

You see here the copied ABI that was magically created for us, as well as what event handlers you are interested in. Since we use the ownable, pausable or other templates from OpenZeppelin, you have all these events. But for NFTs, you're mostly interested in Transfer. So, this is YAML. YML also indicates where the schema is located.

So the schema, when you look at it, it just defines the database. You say, " database. You say, " Okay, there's a table with approval Okay, there's a table with approval , and approvals has IDs and owners, which are represented as bytes, and approved and token IDs." And all of this is just automatically generated according to your contract, but you are free to change that, yes. So, you could say that yes, I'm actually also interested in the block number.

So you write down the block number and let's say it's a big number, and then you can expand your subgraph from there. Then the third part is the actual mapping. So, mappings are written in a language called AssemblyScript. It is similar to TypeScript, but has some slight nuances. For example, you can't just import JavaScript packages here, only AssemblyScript elements, but it's pretty cool, and VS Code, for example, " VS Code, for example, " understands" it, so you can start exploring.

So we can see, for example, what is contained in the event. What do we have here? I usually use Command + click, and then you see click, and then you see that you go to the event where it says, " event where it says, " Okay, this is an approval event;" "Here are its properties." I can also see what is actually going on here, which is included in the Ethereum event included in the Ethereum event . Then I see, "Oh, there's a transaction or a block here."

We see what's in the block, and then we see, "Oh, okay, we have the block hash, the timestamp, and so on." So, I could say that I added the block number here. The next step is to simply run yarn codegen. When you change the schema, you need to re-run the code generation that generates these things. Then I go here to handleTransfer and add the block number to the entity, and I see that now, because I did the code generation, it already "knows" that the entity has a block number equal to the event.

This is something we have also explored before. We have a block at the event, so I'll type in "B" and you can see how you can explore it here; It's not that difficult here; It's not that difficult , number. That's it, I can save and redeploy version three. Steeply. So, that's roughly how a subgraph works, and that's how you can extend it and really create your own magic.

You can come up with new entities that make more sense than just events. For NFTs, for example, you want to have owners, the NFTs themselves, then maybe sales or whatever; It's up to you. We are almost at the end. What I want to show you quickly is this QR code. This time it's not for tweeting.

It will take you to the repository I created for this hackathon. It has all the application code, a link to that presentation, a link to the cheat sheet. So if you, if you want to have it digitally and, uh, yeah, and a lot more. So a really great starting point for a hackathon. Also, if you go over there, you'll see that I have...

Oh, you need to return that. I also added some interesting stuff for you below, especially quality subgraphs. Here's a little trick for you. When you run a hackathon, you want to get as many awards as possible from different sponsors, right? That's why they become sponsors.

And, you know, it's pretty easy to do this: you look for the subgraphs of the sponsors that you want to build on, and then you use those subgraphs to create a cool integration. If you do something interesting with these tools, maybe apply machine learning or something else, you can claim to be the best use of an existing subgraph. So, we have here, for example, Messari subgraphs. Yes, very high quality. Messari has joined as a core partner of The Graph ecosystem, and they're writing standardized subgraphs for these, you know, different verticals.

So we have them for exchanges, ERC, governance, and they all have the same scheme. You can aggregate, compare, and do all sorts of interesting things. You can click on them and then you'll, uh, find links and also be able to view events or, and they have schedules, so that's, that's, that's very useful stuff. But there are other sponsors, for example, Lens Protocol: I know they have their own API, their centralized API, but there is also a subgraph. So if you want to build something based on Lens, you should check out this subgraph and see how far you can go, because if you have a good application based on the Lens subgraph, you can claim a reward from both Lens and The Graph.

And so on, also Unlock Protocol, which we will see here later. OpenSea— later. OpenSea— sponsor, NEAR as an example of how a subgraph on Near works, a very interesting subgraph that works on Polygon. Yes. So you can check these things out here.

Ahem. yeah, I guess I'll leave it here. We are at the stand. I try to be there as often as possible . So if you have any questions, just come by and we'll go over them together.

And if you have any questions now, I think I have two more minutes to answer them. So please put them on. Thank you. Yes. Good question.

OK. So the code, the mapping code, it takes some time to execute. It depends on how effectively you write it. So the main rule: don't make unnecessary calls if possible. But it's usually a matter of milliseconds unless you're doing anything super complicated.

You saw earlier, I just created that transaction. Block, block is mined, and about half a second later it appears in the subgraph. And if you want to know which block indexed your subgraph, there's this special thing. Yes. So we had transfers, this is a meta transfers, this is a meta key, with a meta block, a timestamp, and a number that you can query.

Truth. I created a new version. Okay, let's do it again. Meta block, timestamp, number. You see, this is the last block that your subgraph or graph nodes processed, and here is the timestamp.

This helps you create a frontend that knows how fresh this data is. One more question. If not, then yes. Yes. When you send a request, they respond to it, provide certification, and they have a GRT steak.

So if they give you an answer and it turns out to be wrong, you can prove them wrong. There are also "fishermen" who watch this and then they get fined and the "fishermen" get a portion of that fine, but we're working on something called " something called " verified requests" so that you have proof of the truth of everything, but it's a bit of a complicated math problem. But it's on our roadmap. Thank you very much for inviting me, and I wish you successful hacking.