Querying Blockchain Data with GraphQL

Rate this content

Curious about how data works in the world of blockchain? Join Simon in an engaging session about The Graph, the decentralized indexing protocol that makes it easy for blockchain developers to search and query blockchain data. 

Table of the contents:

- Understanding blockchain data

- Anatomy of a smart contract

- Indexing blockchain data with The Graph

- Accessing data on The Graph

- Recommended subgraphs

- Writing subgraphs overview

64 min
29 May, 2023


Sign in or register to post your comment.

Video Summary and Transcription

Simon introduces the basics of blockchain and smart contracts, including decentralization and immutability. The Graph is an indexing protocol that serves as the data layer of web three, providing a solution to challenges with blockchain data. The CryptoPunk example demonstrates the use of subgraphs as a database for specific protocols. The importance of data accuracy and trust in the blockchain is highlighted. The Graph's business model is based on query fees and allows for easy querying and retrieval of NFTs.

Available in Español

1. Introduction to Blockchain and Smart Contracts

Short description:

Simon introduces himself as a developer relations engineer at ActionNode and discusses the basics of blockchain, including decentralization and the concept of a blockchain as an ordered list of transactions. He explains the immutability of blocks and the role of smart contracts in Ethereum. Simon also touches on the idea of using blockchain for data storage and the importance of rules in maintaining the security and ownership of assets like NFTs.

Thank you so much. I'm so excited to welcome Simon to talk about React. Welcome to the DevCon. We'll get started.

Yeah, hi. So my name is Simon. I'm a developer relations engineer at ActionNode. This is one of the companies, we call them core devs, that are working on the graph. Like we discussed together, how blockchain, or how data is stored on the blockchain, and how we can create, we start very high level and go deeper into the actual stuff. I mean, like the whole data on the blockchain is a big domain that could probably be a day of a workshop. Let's start here, and then we can go with questions depending on where you want to go. And as I said, feel free to always just interrupt me to go into a topic a little bit deeper.

So what is a blockchain? So there is this whole buzzword in the blockchain space. So we call it the Web 3 space that talks about the decentralization. And a blockchain, when we look at it from that angle, it is like a geographically decentralized system. So like the blockchain is copied over like actually thousands of times depends on which one. We are a little bit focused on Ethereum. So there are a lot of like, I think, several thousand Ethereum validators right now. And they copy the whole blockchain. So it's like geographically distributed. Also these validators are independent. So it's also juristically decentralized. But logically, the blockchain feels as one thing. Like there is the one blockchain we interact with and the detail that the blockchain is kind of just copied around the world, usually as a user, we don't really feel this, right? So to come that. And the blockchain is in the end like, it's just an ordered list of transactions. So every participant can send a transaction to the blockchain and the blockchain will be included by the validators in an ordered list. And then like one block consists of multiple transactions. And the block, we say it's finalized and added to the chain by the validators and so on and so forth. And like indefinitely it creates these blocks and also like a very important feature about the blockchain is like the blocks are also immutable. Like once a block is included in the blockchain, it stays there forever. That's kind of cool because it makes it this tamper proof system. So like one old block can never be changed like it's cryptographicly almost impossible. And that's why also it works well as a database for financial or like as soon as a lot of value, we work with value, then it's preserved. So that's why people trust it. Yes, and so that's the blockchain. So that's kind of true for Bitcoin and Ethereum. What's different with Ethereum and Bitcoin is that you also have smart contracts. And the smart contract is basically like really on a low level, it is also just a transaction. So when I deploy a smart contract to Ethereum, then this is also just one transaction that are sent to the blockchain and it's stored there in the block. But in a smart contract, what smart contract can do, it can store data and it can... And I can code or we can code X like rules how to change that data. And these two primitives lead to actually a lot of cool stuff. And now when someone else wants to interact with that contract, so let's say my main example are always NFTs, they are simple to understand. So then when someone wants to send an NFT around, then again, like a transaction that is sent to the blockchain, that is basically like calling a function on that smart contract, authenticated as the user. So that's how it works. So we have blockchain blocks, transactions, everything is a transaction, a deployment of a contract is a transaction, interacting with the contract like in the right manner is a transaction, and these are the fundamentals. As I said, like a contract on the blockchain, usually we can think about just simple data storage. It's actually really variables. But one feature about the blockchain is like the, when we have a blockchain node and we ask for the state of the smart contract, the blockchain node always knows about like the current state, so when we look at the crypto punks, for example, these fancy NFTs, pixelated punks that are so super expensive, then we see something like, yeah, which ID is owned by which owner and where is the metadata stored. But like a problem with that data is also, and then they are obviously we have rules, so only the owner can send the NFT, then it makes it really like secure or owned, so to say, like if anybody can just like change it, change it, that would be a little bit stupid.

2. Challenges with Blockchain Data

Short description:

Blockchain data presents challenges in terms of historical state accessibility, provenance, and incentivization. Accessing historical data is difficult due to the large storage capacity and the need to uncompress data. The lack of incentivization for reading from the blockchain and the reliance on third-party node providers further complicate data access. Additionally, the ordering of data and the low-level nature of the JSON-RPC interface pose challenges for data extraction. These issues result in slow loading times and a need for improved protocols. The graph offers a solution to these challenges.

But what we don't see is like who owns it before, so the historical state is not well, I mean, like it's there, but it's not easily accessible. But we know it's, there are some transactions down in the blockchain that changed the state, but to compute back the state, like how was it? I know, like three months ago, basically we would need to redo all these transactions in an opposite way. So the blockchain is an event-sourcing system similar to Redux, if you probably know Redux. Now it is not so cool anymore, but yeah.

Cool, yeah, and I already touched a little bit on the problem that we don't have the so-called provenance, especially for NFT, so provenance actually, it's a term that comes from art and in art provenance means like when I buy, I don't know, like a very expensive image or a picture that I wanna hang in my villa that I don't have. Then I wanna know who owned it before and also like what's also part of the provenance is actually, is it not a fake one, is it the correct one? So when I see that one that was owned by this gallery or that like very famous collector, then, yeah, the chances are high that I don't have a fake one. And on the blockchain, yeah, the provenance kind of record it, but it's hard to get. So what we don't really have is this time machine. So, I mean, theoretically possible the data is there, but you need to understand, like that the Ethereum blockchain for example, when we run a full archive node that has like all the blocks stored since Ethereum started, we end up with a storage capacity of three terabytes currently roughly. But that's even like heavily compressed. So then to access that data, we need to uncompress and stuff, so that makes it slow. Plus, yeah, and you can think, you can see like there are always new blocks produce, so that probably doesn't get away, right? Like we always have, we always need to think about where to store that data and how to access that data. And then to really get the historical view, it gets a bit hard. So that's kind of one of the problems that we see with blockchain data.

The other one is actually the incentivization problem. So, for which is linked to the other one, so we have this idea, or especially in the early days of this fully decentralized apps. That means we have a front end that we can distribute the code. I mean, basically it's HTML, JavaScript and CSS, we can distribute it however we want. I profess is one of these technologies that's worked very similar to a BitTorrent. And then the idea was that everybody runs a blockchain node on their computer, and then the front end directly interact with the blockchain node. This is the bad dream of blockchain researchers is this fully decentralized thing. The cool thing is there are never scaling issues with such a setup, regardless of 10 or 10 billion of users, although 10 billion will be a little bit too much. It scales because there's no server, everything works on their computers, so it's only the blockchain nodes that interact with each other. That was the initial idea, but there's also a problem with the architecture. And also because it went a little bit the way, nowadays almost nobody runs a node on their own computers. People usually rely on third party node providers. When we use Metamask, for example, in the background, we usually use Infura, which is one of the companies that works with Metamask for that stuff. And then when we write data onto the blockchain, we also pay transaction fees in gas. And that kind of incentivized the whole system to work. So the validators get the transactions in, then they can keep some parts of these gas fees and yeah, that's why they bring their blockchain to the chain. But reading from the blockchain is kind of an unused problem or it's not incentivized on the protocol level, for what they say. So that's also where a lot of companies spun up, as I said, like in info around all those networks with mental masks to provide access to the data, but also they need to find a business model around it. And so there is this whole thing. And it's not easy to get to that data. Also, like what I said before is on the blockchain, we store the same space that's ordered by, yeah, like the timestamp, with all the other smart contracts and everything else that goes on on the blockchain. So in order to see, so for example, Maker, let's say Uniswap is probably the most common name here. So in order to see what happened on Uniswap, we need to look at all these transactions and just filter out the ones for Uniswap because all the other protocols share the same block space. Yes, and then that ends up with getting, and also the protocol or the interface to get that data is called JSON-RPC. That's a very low-level thing to interact with a blockchain node. It's really like an RPC. I can call simple functions, but not really nice data extraction or I don't know like what else would be like indexing instructions and so on and so forth. It's very low-level. So that's actually code that I saw in the wild, so when we wanna try to get a token ID, which has all the tokens by an owner, we see all these await statements here, and a lot of them are actually a call back to the JSON RPC endpoint, and maybe it take 100 to 200 milliseconds to resolve. And then we get into stuff like this, like, okay, I get to first this one and I get this one, and then I wait. And if someone has 20 tokens, and for each token, it takes 200 milliseconds, we end up with a page that takes multiple seconds to load. And we know that users, as soon as we go above 100, 200, 300 milliseconds, they usually get impatient, although people that are using Web3 or blockchain applications are a little bit more used to slow waiting time, but I don't think that's a good excuse. So this is kind of the problems. The data extraction, it's not really incentivized. It's the protocol, the underlying protocol is very basic, and so it's quite a hard task. And that's exactly where the graph comes in.

3. The Graph: Indexing Protocol and Subgraphs

Short description:

The graph is an indexing protocol that serves as the data layer of web three. It sits between the front-end and the blockchain, forwarding write calls and incentivizing reading through query fees. The graph architecture consists of the front-end, the subgraph for indexing data, the contracts built on top of the blockchain, and the blockchain itself. It supports multiple networks and provides an abstraction layer for data storage, making it easier for developers to work with different blockchains. The subgraph is a database schema that instructs indexers on what data to index and how to store it, functioning as a form of curation.

So the graph is the idea of having these APIs for a vibrant decentralized future. So it's an indexing protocol that helps with all these needs, like indexing the data on the blockchain and then serve it in a nice way to our front-ends or also like other data science application. This number is actually one, between one and two billion queries per day.

So the graph, there's currently a host service that will be duplicated over the year, but there, it serves like between one and two billion queries per day for big applications like Uniswap or also enzyme audios, unstable live peer and so on and so forth. So it's really one of those protocols, infrastructure protocols that is very heavily used. So two billion queries per day, it's actually quite a lot.

And so in a technological sense, we think about the graph as the data layer of web three. So it really sits in between, there's better chart. So later, I go into that later and also like it's a decentralized endings in network protocol, so there are like, the idea again is like to go towards this decentralization so that the end user, we don't need to, or like a developer especially, we don't need to care that much about scaling because as I said, like the initial decentralized that infrastructure scales indefinitely, that's like super scalable and now with decentralized indexing protocol, again, we have like, we have very, very high scaling. So at the point in time, when I copied that slide over, I think that these numbers went up a little bit, but we had like 465 indexers. These are the ones that are actually very interesting for us as a developer. These are the ones that would then in the end, index the data for us and surf it. They are distributed across the world. So wherever like the users are, they will get an indexer. We have at the time 700. I think that number went to a thousand actually already. And the delegators and curators are just like some other roles and I don't wanna go deep into it because as developer it's not so important. So as of today, the network generated like 2.25 million query fees as a, I don't know the charity price is today roughly at 12 cents. So that's, yeah, you see now, I know bad in math. But it's quite something going on. Yeah and this is actually the architecture that we end up with compared to the one before where we said like at the front-end and at the blockchain directly. You have the front-end and then the graph that sits in between the front-end that forwards just like the write calls. Thank you. Forwards just the write calls to the graph to the blockchain, but what gets like the data on both are incentivized. So writing, we already had incentivized but reading is now incentivized. Like while reading from the graph, we pay a small amount of query fees to the indexes that have indexed the subgraph and are serving that query. So they also have like the correct incentive to work in the system. That's kind of the solution. Also a little bit the nicer slide, these ones I made and then design said like, I should use that slide, which is for sure nicer. So we have like the front-end and then the subgraph for the graph, the indexing data in between. Then we have the contracts, as I've said, that kind of build on top of the fundamental of the blockchain. And then we have the blockchain at the bottom. Yeah, so that's very cool. So we end up with these truly decentralized apps that also have like the data layered and decentralized. Also maybe important to say here, like the graph is supported, not only in Ethereum, but like on a bunch of other networks, like a layer of tools or roll-ups like Polygon, Avalanche, Selo, Arweave, I know, what are interesting, Cosmos, a lot of people talk about Solana also. So with Solana, it's a little bit more complicated, but like the fundamental layer is built, so support for the graph on Solana is soon on the way. Also, yeah, so basically whatever, let me go back to this one. Whatever blockchain we wanna use, or then the graph eventually will have some support for it. So that makes it actually as a developer very cool because also like data reading, data is stored in every, and especially the blockchains have a different implementation in Ethereum in a different way. But with the graph, there's kind of this abstraction layer. That's what I loved about GraphQL initially anyway, is kind of different abstraction layer of data where I don't need to know exactly in detail what goes on behind the scenes. But yeah, I can just create a data, cool. So that gives it truly the simplest steps. We had it. So now the next password that's always often talked about is like what is a subgraph. So the subgraph is the fundamental instruction set for indexers, what data to index and how to store that data. So it's basically a database schema and then some rules like to watch on the blockchain and how to store that into the schema. So that's a subgraph. And then we end up with, so a subgraph can also be seen as a form of curation. So someone says like, hey actually this data together makes sense.

4. CryptoPunk Contracts and Database Setup

Short description:

The CryptoPunk example involves two contracts, the CryptoPunk contract and the RappdPunks contract. The focus is on transfers and sales, while other events can be skipped. A database is set up to store the punks, owners, and transfers. The subgraph acts as a database or bucket for a specific protocol or use case, sharing the database with other subgraphs. Models simplify the process.

So let's say for the CryptoPunk example, that's one. Then the developer we look into the CryptoPunk soon. So the developer said, hey, okay so the CryptoPunk says basically there are actually two contracts that are interesting. The actual CryptoPunk contract and then the RappdPunks contract because there were some compatibility issues. So someone wrote this wrapper, so we want to look at both and on, but only these two. And then we want to mainly look at the transfers and the sales. And there are some other maybe events that are not so interesting that we can skip. And then we want to set up a database. The database is like, okay, we have all the punks somewhere, we have all the owners somewhere, we have all the transfers somewhere, we can then say that a transfer that's also sale. That's basically how to approach a problem. But on a more visual way to explain it, as I said, we had to have all these transactions in front of the blockchain, the orders by timestamp. And in the end, like, a subgraph can be seen as like, one database or bucket per, let's say protocol or use case, whatever makes sense here. One guy once pointed me out, like the subgraph by itself for the database, they share the database with other subgraphs on the index system. Just to put this technical detail, but I would say models should simplify what's going on here. So that's what it is.

5. GraphQL and Indexing Protocol

Short description:

GraphQL allows for easy retrieval of NFTs owned by a single owner with fast query resolution. The user interface writes directly to the blockchain and reads through the indexing protocol.

Cool. So in the end, to go back to this, it's like an ugly, ugly Telspray code that we had before. Now we have a beautiful, what do we call that, GraphQL. And can easily, with one request to the graph, get all the NFTs that one owner owns. And that queries, yeah, resolves usually in 100 to 200 milliseconds. Yeah, so that's very cool. So we can have these snappy interfaces now. Yeah. Yeah, that's again like what I said before. The user interface writes directly to blockchain. It's properly incentivized. And then it reads from the blockchain through the graph, the indexing protocol.

6. Exploring Subgraphs and CryptoPunks

Short description:

In this setup, a user sends a transaction that goes through smart contracts, emitting events. The graph node watches these events and runs mappings encoded in WebAssembly. The data is stored in a Postgres database. On the other side, developers send queries to a GraphQL API, which resolves to the user. We create a decentralized network and explore subgraphs published to the graph network. Messari and other companies write high-quality subgraphs, including CryptoPunks. We can examine the source code and see how the data is organized and how the subgraph works.

Cool. All right, and that's roughly how such a set up looks like. So in the top, we have the debt, a user sends a transaction. Let's say someone buys a cryptopunk. Goes through smart contracts, the smart contracts they emit events. So the blockchain is an event-driven system or like smart contracts and a very good smart contract emits events. And then we can watch these events with the graph node, which is the underlying technology that indexes run.

Then when they see the events, they run so-called mapping. The mapping is encoded in WebAssembly. It's written in AssemblyScript. You can compile it down to WebAssembly. So AssemblyScript is very similar to TypeScript. So like a JavaScript, TypeScript, you'll probably feel familiar, although there are like small differences and look into this. And it's stored in a store. It's basically a database like that. It's literally a Postgres database under the hood that each indexer runs.

On the other side, we see the dev that sends queries, which goes to a GraphQL API. That's very like how Web development works, right? It's just the API that is also Graph Node and then it's resolved to the user. Or like in a nice GIF, we see, yeah, we have all these different transactions and they kind of magically end up being nicely sorted. Cool, yeah, if you want to tweet about it, you can say that you have learned about Subgrowth but we can maybe do that later. There's another QR code. The QR code basically goes to this one. This one. Yeah, so yeah, it's just like my slides again. So what we do in the workshop, yeah, we create a decentralized network. I would say like the best thing is to do, we just do it now together in here. Are there questions up until now? Some topics that I ran through too fast, okay. All right, then let's go. We can go to the graph.com. Oh, really? Wow, okay, we have an internal server error here. Oh, okay, so only the landing page is down. But anyway, when you go to the landing page, you see on top left, you can check the graph explorer. And here on the graph explorer, we see these are the subgraphs that are published to the decentralized graph network or the graph network. It's quite some. One thing to look out here are the ones from Messari. Messari is another company that works on the graph. There's also data company that are very, like, they're well known in the scene. And yeah, and they write these high quality subgraphs of the big protocols. But the one subgraph that I actually really like is the CryptoPunks. Because so easy to understand. So it's this one. So it's easy to understand and how they work. So we can look a little bit into actually how the data is organized on the blockchain. How the subgraph works. So we see here is the source code. So usually the source code is linked. It lives on GitHub. This is the developer Jerry that created that subgraph. And he's also maintaining it. I think like, a little bit.

7. Subgraph Manifest and Contracts

Short description:

The subgraph manifest defines the contracts, networks, blocks, and events to be indexed. It includes the assign and transfer events, as well as the buying of items. There is also mention of a chain marketplace and other contracts.

So you know what these kind of these silly pixel images that people are paying like so much money for it. And I like really the subgraph we can look at, it's a subgraph dot YOML. This is kind of the manifest of the subgraph that defines which contracts we are indexing on which network and on which block we start to index. And also which events that contract emits that we wanna act upon. So there is the assign, which was the original one. And the cryptocons originally, but they're interesting that they were assigned for free. Kind of the airdrops. Then we see the transfers. We also have the, when something is bought, so it's interesting. Here we have our own chain marketplace. Yeah, and then we have some other contracts. But like, this is basically it.

8. Checking the Cryptopunk Contract

Short description:

To check the Cryptopunk contract, I can simply copy and paste the address into Etherscan. The transactions and blocks are indexed on Etherscan, but there is no direct API access to the data. The smart contract, written in Solidity, is open source and easy to read. There are read functions like punk-index-to-address that allow us to retrieve specific information, such as the owner of a punk.

And then I also can check that contract by myself. And yeah, I just copied paste this address over to here and can go to the Etherscan. And then I see like, okay, this is the Cryptopunk contract. And I see all these transactions in which blocks they happened. It's already a little bit indexed for us on Etherscan, although it's on a centralized server. And I think there's no API to directly get into that data. We can look at the smart contract, actually, really the solidity. I mean, it's quite cool. Like most stuff is open source on Ethereum. So, very easy to read and to learn. And there are these read functions. Basically, they translate back to back. So, when I say, for example, punk-index-to-address, it goes into... Yeah, here, actually this one. Just a punk-index-to-address. And I can do this. I can get to punk one. It's owned by this person. So, I think, actually the same. Okay, cool. So, that's roughly how it would look like if you wanna do it by ourselves on Etherscan.

9. Exploring CryptoPunk Sales and Data Accuracy

Short description:

The most expensive CryptoPunk sold was the punk with ID 9998, which was purchased for approximately 124,000 ETH, equivalent to $211 million. This price is significantly higher than the largest sale recorded on the Larval Labs website, which was for 8,000 ETH. The difference in prices highlights the importance of considering data accuracy and the role of the graph in indexing raw data from the blockchain.

But now, one of the nice questions always is about CryptoPunks. It's like, okay, so, which one was actually the most expensive punk that was ever sold? How much did someone actually pay? So, let me just look at these read functions that we have here. There is none, right? There's no most, nothing like that. The contract basically keeps track, as I said, on the current state. But if you wanna really have this historic state, we need to have another function. I mean, the other possibility is we can just go through all these methods, transactions we can maybe filter for. Buy Punk. Then maybe, I don't know if we can even sort for value. No, it's possible that we can look through these thousands of transactions. But yeah, that's not a good user experience. And also not like something that we can build on top. But can we build a front end top?

So with the CryptoPunks, what we can do is we can just go to the GraphQL playground. And as I said, like I really love GraphQL because it's structured, or like it's heavily typed. So I can just open the Explorer here and I see like all the top-level queries that I can do. And so just by reading through them it kind of starts to make sense. So we have account and accounts. This is this pattern of you can get one by ID or get multiple by a filter. So we have to ask some bits in, yeah, in marketplaces it's like an ask is when I, when I own something and I wanna let's say 10 ETH for it. Then the ask is the thing, and the bid is when someone else have something that I want and I can send it to him, give you 10 ETH for it. We have contact stored, some notification stuff. We have events stored, NFTs offers punks. And now we go to the sales actually, that's where we are like I wanted to see sales, right? So we can just simply click on sales, open it, and then we have an amount which is cool. And we can also see the NFT, and then the ID maybe. And we get the first five order by amount and order direction descending. So this will give me the five most expensive sales of CryptoPunks in history. And that was really quick, right? Like I was just looking at the schema, opening up these things and sending the query. So let's send this. Cool. So it seems like the most expensive punk is this one. So it's the punk of the ID 9998. And the amount is this one, which translate. So we need Ethereum, just this, so Ethereum has 18 decimals. So like as US dollar or Euro or whatever, usually currencies has two decimals. Ethereum has 18 decimals, but it's stored in the smallest number, which is, let me call it weight. So when we want to see the ETH price, like price that we see, like someone paid 124,000 ETH, which I think roughly. As today, ETH was around 1,700, I think. Yeah. $211 million for one NFT. It's quite a lot. I mean, it's surprisingly high. But like now here, it's something very interesting about this. When we go on the Larval Labs website, Larval Labs, all right, Crypto Funks. Here. And here we see also the sales, the large sales. Then interestingly, the highest largest sale that is here was for 8,000 ETH. But here we ended up with 124,000 ETH. So it's quite a difference. So why is there a difference here? And actually, it's quite interesting. So also a little bit about how do we think about data? So the graph indexes the data from chain regardless what kind of data, it's the raw truth. And we see also there's this ID 9998.

10. Exploring a Punk Transaction and Querying Data

Short description:

We can explore a specific Punk on the CryptoPunks website and discover a transaction that was censored. This transaction involved a Flash Loan, where someone borrowed a large amount of money, bought a Punk from themselves, and resold it. CryptoPunks considers this manipulation, but the blockchain provides the raw truth. Trust in the data and ownership of data are important considerations. With the graph and blockchain, trust is inherent as most subgraphs are open source. Although some data may be censored on the front end, we still have access to the truth. To query the data from the front end, we need to use the graph studio and obtain an API key.

So we can go over here and start to look into that PUNK. So we need to hack around a little bit here. We can look into that PUNK. It's this one, it's not even a very rare one, but here we see that transaction actually recorded here too. But they did not... Yeah, they kind of, what is it? They censored on the website a transaction that was not valid. And there's this star that we can learn more about. And, yeah. So, someone with this technology called Flash Loan.

In a nutshell, it is possible on Ethereum to borrow like almost indefinite amount of money as long as you paid back in the same transaction. So, what someone did is like, they loaned so much money, bought the punk from themselves, resold it to themselves and gave all the money back. That stunt maybe cost some hundred dollars, but at least it's now history that... Yeah. That so-called Flash Loan, if you want to look into it. But, yeah. So, they, CryptoPunks kind of think like, this is manipulation. And they might or might not be true, but we know that the data on the blockchain is censorship resistant, so we can have the raw truth here.

Yeah, so that's about... Yeah. About the different data, like, can we trust the data, and who has ownership of data, which is quite interesting. And with the graph and blockchain, like, that trust is always given because most subprime are open source. We can look how they work, and the data is very strong and it's about what data is true. And then we have access to the raw data. If people want in their front end, sensor stuff like this, I mean, it's not fully censored, but it's just not on the main page, right? I mean, it's their choice, it's a fair choice to make, it's okay. But we still have access to the truth if you want.

Yeah, so we looked at this. Yeah, okay. So the next step would be if you wanna query that data directly from, see, maybe it's fixed now, yeah. If you wanna create that data directly from our front end, then we need to go to the graph studio. So first again, I get that the Crypto Punk, I can get that one out. Then I make a new tab, I go to graph studio. And in order to query it from the front end, we have here a query URL. But we need to have an API key to query that URL. I'll show you quickly how that would work. So I could connect here, connect with Metamask. For those that don't know, Metamask is a browser wallet. Wallet is also a little bit a strange term. It basically stores my private key. And so I can interact with the blockchain directly. I can switch networks here. But also let's just create a new account for demo purposes. I can disconnect again. So let's connect the wallet. I think I've met the mask. It's a bit cumbersome. But if you do it the first time, it would basically just work. It's just costing me. Blah, blah. But when I do this, I can give my email. That would send me an email when the billing balance goes low.

11. Connecting to GraphQL and Exploring Subgraphs

Short description:

I demonstrate how to create an API key for free queries and connect to the GraphQL endpoint. The Guild's Graph Client provides useful features like live queries and the ability to create multiple subgraphs. It can be used as a data layer to interact with the blockchain via mutations. The GraphQL mesh combines data from the graph with other sources, creating a unified GraphQL interface. Subgraphs.messari.io is a resource for exploring subgraphs. If existing subgraphs are not sufficient, we can look for alternatives. The fear of new technology can be overcome by seeing it in action. The links to the websites shown are available in the presentation.

But I don't do this for now. What I can do is go to the API keys and create an API key that's the name demo. And then I can get 1,000 free queries just by giving my mail here. So my name is demo, and no.com. Cool, and now I have an API key that's here with 1,000 free queries. And now we can go to GraphQL online, maybe, and go forward. So we have the query URL here, so I can use it, go over there, paste. And then here at the beginning, there's an API key placeholder. So I get the API key here and paste it there. And then I can connect to the end point. Yeah, that should basically usually take maybe a second or two. Yeah, here we go. And so again, I kind of explored the thing here. And with the same endpoint as we see here, I can use that in my front end as a normal graphical endpoint to send my queries to. Yeah, so I stop here for a second. Are there any questions up until now?

No, I don't have any questions yet. Really awesome. Okay, cool. Yes, maybe, so I quickly ran through this. So if you want a query from the graph, there's also the Guild. I don't know like if you know the Guild, they are creating very cool tools like I think the graph called Yogo Server, but they're very active in the graphical open source community, they also work on the graph and they create this cool tool called the Graph Client that I want to show here, so, and I can maybe also go back in the proper slide show the Guild. So it basically sits in between the graph and the frontend, helps us to better access the graph, although it's just GraphQL, there's like cool new features like the live queries which are abstracting away like as soon as data changes and the Graph Client kind of knows that and can send it to the frontend. It's also cool to, like we have, often times in the frontend, we wanna create multiple subgraphs, also across different chains. It's also something that the Graph Client can help, like they have easy tools of bringing multiple subgraph into one unified GraphQL schema, those are very cool. Yeah, it could also be used directly as a data layer even without the graph to have, to interact with the blockchain via mutations, so we can really go all in with GraphQL tooling, or like sitting really in between, also to have these mutations, send transactions to the blockchain with GraphQL mutations, do the proper block tracking to know like if stuff has updated, and so on and so forth. Like it's a very cool tool to play around, especially for advanced use cases on top of the graph. Yeah. So because it builds actually basically on it builds on it's graph, it's called the GraphQL mesh. Yeah, GraphQL mesh. It even is able to combine, you know, like data from the graph with other sources, even like refreshed and XML or gRPC or whatever into one unified GraphQL interface that could even be deployed to Cloudflare workers and other edge computing. Very interesting thing. But again, this could have a full virtual by itself. But the guys will be actually in Amsterdam next week with me. So if you're interested in this, we have a booth. So come by, say hi. And ask some questions. But in the beginning we had the question about how to write subgraphs by itself. And because right now we just saw how to query them. There's also this one is maybe good to know. It's subgraphs.messari.io. I think it's subgraphs. It's a good resource if more subgraphs or as I said the explorer. But sometimes the existing subgraphs are not fulfilling, so to say. We wanna look into something else. So maybe I quickly remove... And I know from myself and when there is a new technology I usually are afraid of that technology because I don't understand how it works. And the best thing to remove that fear for me was always like to see how it works in action and how simple it is. A short question really while you're typing away. Are those links from the websites that you were just showing before, are they also in the presentation or?

Yeah, they should be in here but I can also quickly... I will check because it went quickly away but I don't want to miss it.

12. Creating a Subgraph for CryptoPunks on Ethereum

Short description:

The speaker discusses using Discord and the GraphiQL online tool. They explain the process of creating a subgraph for CryptoPunks on Ethereum using the graph CLI. The speaker demonstrates how to initialize the subgraph and set parameters such as the network, contract address, and start block. They mention the importance of indexing contract events as entities and provide an overview of the protocol.

Yeah, so are you in that Discord too here? Yeah, yeah, yeah, I just joined that one. I was not there yet. I'll definitely come by your booth, by the way. Yeah for sure. That's the Explorer to find the sub graphs. I mean, yeah, what I did is I followed the links here down to CryptoPunks, maybe the other one that's interesting is this one. Yeah. Yeah, you know what else you did with online query? Ah, the GraphiQL online. Yeah, GraphiQL online I think yeah. Was here, no, no, this one. Yeah. Yeah, yeah. Yeah. I mean, you don't need that actually because the endpoint, this is what you use in code when you want to query it. Yeah, I was trying to try to make a little bit of a wallet and playing around with it, so. Yeah, because the playground, what we have here, this one, the playground we also have the same. This was just to show you how to build together a URL with the APR key in it that actually works. It's just proof of work that this URL works. But everything you can do in here you can do in here too. Does that make sense? Yeah, yeah, that totally makes sense. I just tried to figure out why I cannot, oh, there's no lock on it. Maybe need to validate something. Yeah, well like actually really quick. We have, what is that? If you want to, I don't know, if you want to do this the CryptoPunk subclass by yourselves again, I mean it doesn't make that much sense because the one is already good. But what we could do is like we start with that address. So there is a graph CLI, I can actually go into my sub graph studio, sub graph studio again. It's gonna create the sub graph, give it a name. CryptoPunks, take the blockchain, let's say it's on Ethereum, there are more, right? Just create the sub graph. And then I can follow these steps here like, YARN Global, whoops. YARN Global Add Graph Protocol. So we can install the graph CLI and then follow this instruction here, just like say, Graph Init CryptoPunks. It's really basically it copy paste through that thing here. And then here, we have an init ship. So what that did is like that just was going through these steps here. So YARN Global installed that work, right. And then I copy paste the second command, Graph Init STUDIO. And yeah, and then we have like the protocol, the way it works. There's just like a dialogue. Usually the standards are good, like which network, your mainnet. And then I have to contract the address, right. We have it here. So I can just copy that address over here, paste it. And then it gets the ABI from Etherscan. So the ABI is the outline of, you can say the outline of the smart contract, which events are there, which functions to call. Then we usually wanna start with a start block. So the start block is the one block, as I said before, where a transaction was, where a contract was created. And we can index, yeah, before a start block, before the contract was deployed. Like it doesn't make sense to try to get some data from the contract as long as he doesn't exist. We can give it the name and here it's like matching, we can index contract events as entities. Yeah, I can run through this while it installs them.

13. Subgraph YAML, Schema, and Handler

Short description:

The subgraph consists of a YAML manifest that holds everything together. The schema defines the database tables, including the entity for PunkBot events. The handler, written in assembly script, creates a new entity and fills it with data from the event, block, and transaction before saving it. We can follow the example and deploy the subgraph, which starts indexing the blockchain. The process takes time, but we can soon expect to see data. We also briefly explored developing smart contracts.

I don't know how did I name it? Cryptopunk. Okay, so while it's installing the dependencies, we can also look at the code. And as I said before, the subgraph really consists of a subgraph Yaml, which just looks very similar to the one that we saw on GitHub because it's the same start. So we have a source address, the start block, the network that's indexed, the schema that's referenced here, and also the event handler. So the manifest, or like subgraph, the Yaml is the manifest. It holds everything together.

So let's start with the schema first. So it goes to the schema and then that schema, that despite being GraphQL compatible, it's not the schema that we will query. It's a database schema. It's inspired by Prisma 1. So we have, and these are actually just tables. So we have like a table, let's say for PunkBot here. We have a table, PunkBot. There's an Id that's stored as bytes. It's also immutable. So that's an entity that we kind of change later that makes it a little bit faster to index and query. Let me see which index, like whenever a PunkBot event was emitted, we have auto-generated tables for all the events. It helps us here, if value from address to address, look number, it happens the timestamp and the transaction hash. And so this is kind of the underlying data schema. We can also obviously extend it, add relations, and so on and so forth, but we can also go into the source.

The second thing that's held together here is the handler. Let's see, it's just, let me go again to this handle PunkBot. What it does is just, it creates a new entity and see this assembly script, so it reads very similar to TypeScript. It even has the same features as... Like, because it's not TypeScript, VS Code think it's TypeScript, and there's very little, like, very little differences. So in the standard example, like TypeScript compile doesn't even complain, but, and we can go into and see what's in that event. Oh okay, that's a class that does this. And what's then here? Oh, we have this one. And blah, blah, so we can just explore. We have the auto-complete, as we love it, and here what happens is just we create a new entity. We fill that entity with stuff from the event parents. Then we fill some stuff from the block and the transaction, and then we save it. So that's super simple. The cool thing about this is, yeah, so it asks us if we want to add another contract. But we don't need another contract. So we didn't write any code as of now, and we can just follow the example. The examples, we can set the deploy key. This one is probably already done, and we can just do Graph Deploys to the Cryptopunks. Yeah, give it the name, we follow the same there, give the version. Boom. And it's deployed. And now it already starts indexing, see? Yeah. I hope there's no problem with it. It takes a while until it's starting, it needs five minutes until we see the first. Yeah, cool, it goes on now. Starting. And it reads through the blockchain, processing triggers, blah, blah, blah. Let's see if we already have some data now. Hmm, I think we have a new feature called batch writes which increases indexing speed, but also waits five minutes first before actually writing, so we don't see that now, but it will soon show up. Yeah, so we also looked quickly into how I can develop smart contracts by ourselves.


Interacting with Other Blockchains

Short description:

The graph is a building block for interacting with other blockchains, providing a unified interface regardless of the underlying implementations. It supports both EVM compatible and non-EVM compatible chains, aiming for a decentralized multichain future.

I think everything is documented online. Think that pretty good, I think I should move this, so graph.com slash docs. So here, we have these subparts. So developing is really just creating a subgraph is the ultimate resource, composed to this chord, but also querying, stuff that I just described here, which we see like magic API key, best practices, and more. What else? There is a quick start, I think. That's basically just what I did. But, yeah. Thank you. Thank you so much.

I think we have time for some questions. First of all, thank you very much for this presentation, it was really awesome. Picked a lot of new things up. A question that I have is like, is the graph then now basically like the building block to interact with other blockchains basically to read them out. So basically, the core components. And does that mean like, is it like EVM compatible? Meaning that you can just go through all the chains or is it like really, they really make those chains different from each other or something? How you need to interact to them.

Yeah, that's a good question. Actually, there's another one, maybe this sound good. So maybe when you look at this architectural slide here, so you can think about the graph as this ETLQ pipeline, like extract, transform, load, query. And it's true, like the query layer, the query layer stays the same regardless of the underlying implementations the graph supports correctly like correct, like most EVM compatible chains that have some traction, I would say, but also non-EVM compatible chains like Near, RV, Cosmo, some of the Cosmos chains have support, Solana support is in the making. So yeah, and that's just the correct to say, like it really the idea is to have this unified interface with whatever lies below. The same idea that GraphQL had for traditional web apps, the graph wants to be for this decentralized. Multichain future.

Introduction to GraphQL and NFTs

Short description:

Starting with GraphQL and NFTs is a good way for developers to understand blockchain without diving into all the details. It's a gradual process of learning Solidity and exploring more complex topics like lending and exchange protocols. The Graph makes it easier for developers to work with GraphQL and navigate the Web3 world.

That makes a lot of sense. So good starting point at least, to be it. Yeah, and that kind of like it, I would say that's how I've structured this presentation that we can start with, you don't need to know understand blockchain in detail, like how it works, there's a lot of small details that might be intimidating initially, but we already know GraphQL, right? Then we can have a rough understanding how an NFT works because it's just like this thing that moves around, that gets sold and sold and stuff. So it's a good way, in my opinion, to start with looking at NFTs through GraphQL to find out a little bit, to play around, think around with the tech, and then slowly we can start about, that's actually my journey, like I started as a front-end engineer into Web3, and then at some point I started to learn to read Solidity, and Solidity is also not that hard to read because it's JavaScript-inspired, and then I started to read into the contracts and started to understand more about these contracts and then maybe learn about more complex topics like the lending protocols like Aave or MakerDAO or the exchange protocols like Uniswap, how they work, how you can participate, these are then a little bit more complex topics. But yeah, I think like, with the Graph, helps a lot of going easy in through GraphQL for developers, yeah.

Exploring Assets and Checking Tokens

Short description:

Besides NFTs, you can also see any asset you hold on a wallet address. The problem is that we need to feed the lowercase version of the address. In the NFT subgraph, I can easily check the tokens I hold, including their ID, contract, symbol, and name. This is useful for tracking tokens across different wallets.

Besides NFTs, you can also see basically any asset that you hold on the, for example, on a wallet address then or no?

Yeah, yes and no. Oh. So the problem with, so there is this, yeah, stop graphs, hello? Okay. So. Okay. So yeah, we could basically go to either scan and then find me. Come on. Just because I'm using a VPN here. No. Oh, you're in China. No. Oh. In a hotel room. Oh okay. It's not... Okay. So this is my public address. You know, I've got my... schmitty.eet. And now we can go... Okay. Okay. For whatever reason. Oh, here we go. Okay. So there's the NFT sub-graph. This one. And here I can go to... I think. Accounts and then where... Wait a second. I think the problem is, let's see, accounts, I think like this. Let's see if it finds me already. No, okay. So the problem is we need to always feed the lowercase version. But I mean that's quick to lowercase. Okay. Okay, so that's my address. Let's see now, it should find it. Yeah, okay, cool. All right, so that's my address. And in that subgraph, I can easily check my tokens that I hold. ID, let's do this. Yeah. Or maybe the word is bad, let's go contract. Maybe identifies also, that'd be nice. Symbol, name, yeah, let's do this. That'll be nice. Oh, I have homework talk, what is this? There's exactly the use case. I've been swapping around and I have like everywhere, all kind of tokens in wallets that I have.

The Graph's Business Model and Querying NFTs

Short description:

The graph's business model is based on query fees paid by users. The decentralized protocol distributes the fees to the indexers. Querying NFTs with the graph allows users to see the tokens they hold. The graph provides a URI for accessing the image of a token, enabling its use in the front end.

So I was like, I was really like hoping to get out of this a way how I can easily see that instead of. But honestly, that does look wrong to me. Okay, I need to investigate this. But that's basically how you do it. I can send it to Discord. Yeah, that works with NFTs. But with other tokens, there are just too many to be honest. ES20s, it's just, we have that running to scaling issues with the indexes that they cannot keep up because it's just too much. Like there's new technologies coming out, like fire hoses in substreams. To hint on this, that should sort of be scaling issues. But that's it now. Yeah, like ESC721 balances kind of works, but ESC20 doesn't. And the business model for the graph is basically the queries that you pay for. So you're querying with the graph and the fee that's basically their business model or not? Or is there like a different business models applicable for them, for the graph? Sorry, can you repeat? I just found out what I'm doing wrong here. Yeah, I don't really know. So the business model for the graph is basically that they getting paid with fees when you query. So you get like when you now signed up, you were getting, I think a thousand free. When you went to add them, that's basically where you, that's for them their business model or not? Yeah, I mean, the graph is a decentralized protocol like Ethereum, so there's like nobody. Or like that money is distributed. So like, when it goes to the indexes actually, and you know, I have to know that you see here, we also just run one indexes. But yeah, the business model is there. But yeah, it's, I mean, yeah, like simply said, yes, the business model is paying back query fees and the business model is actually for the indexers to get these query fees. Excellent. Yeah, and so now we have actually, I made it like, I should have queried the child. So now I have it. So when I sent this query, actually I can also get the query over. So, like this, then I see like all these NFTs that I have. So I have like some Pantheons, Livesar tokens, NFV, Bern, Chubby's, what else? Oh, I have Sound and some proof of attendance ones. The dev, the developer now, Spiro NFT, a Rari token. Yeah. So quiz. Yeah, keep going. Yeah. Play it around a little bit, but yeah. So that's how, yeah. That's how you can get it out. And if you want to use that in the front end, you can actually also go and get the URI over in the front and then you need to follow the URI like this. And you have the image and then it can upload the image. And that's one of them that I hold, yeah.

Watch more workshops on topic

React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
GraphQL Galaxy 2021GraphQL Galaxy 2021
140 min
Build with SvelteKit and GraphQL
Top Content
Featured WorkshopFree
Have you ever thought about building something that doesn't require a lot of boilerplate with a tiny bundle size? In this workshop, Scott Spence will go from hello world to covering routing and using endpoints in SvelteKit. You'll set up a backend GraphQL API then use GraphQL queries with SvelteKit to display the GraphQL API data. You'll build a fast secure project that uses SvelteKit's features, then deploy it as a fully static site. This course is for the Svelte curious who haven't had extensive experience with SvelteKit and want a deeper understanding of how to use it in practical applications.

Table of contents:
- Kick-off and Svelte introduction
- Initialise frontend project
- Tour of the SvelteKit skeleton project
- Configure backend project
- Query Data with GraphQL
- Fetching data to the frontend with GraphQL
- Styling
- Svelte directives
- Routing in SvelteKit
- Endpoints in SvelteKit
- Deploying to Netlify
- Navigation
- Mutations in GraphCMS
- Sending GraphQL Mutations via SvelteKit
- Q&A
React Advanced Conference 2022React Advanced Conference 2022
95 min
End-To-End Type Safety with React, GraphQL & Prisma
Featured WorkshopFree
In this workshop, you will get a first-hand look at what end-to-end type safety is and why it is important. To accomplish this, you’ll be building a GraphQL API using modern, relevant tools which will be consumed by a React client.
Prerequisites: - Node.js installed on your machine (12.2.X / 14.X)- It is recommended (but not required) to use VS Code for the practical tasks- An IDE installed (VSCode recommended)- (Good to have)*A basic understanding of Node.js, React, and TypeScript
GraphQL Galaxy 2022GraphQL Galaxy 2022
112 min
GraphQL for React Developers
Featured Workshop
There are many advantages to using GraphQL as a datasource for frontend development, compared to REST APIs. We developers in example need to write a lot of imperative code to retrieve data to display in our applications and handle state. With GraphQL you cannot only decrease the amount of code needed around data fetching and state-management you'll also get increased flexibility, better performance and most of all an improved developer experience. In this workshop you'll learn how GraphQL can improve your work as a frontend developer and how to handle GraphQL in your frontend React application.
React Summit 2022React Summit 2022
173 min
Build a Headless WordPress App with Next.js and WPGraphQL
Top Content
In this workshop, you’ll learn how to build a Next.js app that uses Apollo Client to fetch data from a headless WordPress backend and use it to render the pages of your app. You’ll learn when you should consider a headless WordPress architecture, how to turn a WordPress backend into a GraphQL server, how to compose queries using the GraphiQL IDE, how to colocate GraphQL fragments with your components, and more.
GraphQL Galaxy 2020GraphQL Galaxy 2020
106 min
Relational Database Modeling for GraphQL
Top Content
In this workshop we'll dig deeper into data modeling. We'll start with a discussion about various database types and how they map to GraphQL. Once that groundwork is laid out, the focus will shift to specific types of databases and how to build data models that work best for GraphQL within various scenarios.
Table of contentsPart 1 - Hour 1      a. Relational Database Data Modeling      b. Comparing Relational and NoSQL Databases      c. GraphQL with the Database in mindPart 2 - Hour 2      a. Designing Relational Data Models      b. Relationship, Building MultijoinsTables      c. GraphQL & Relational Data Modeling Query Complexities
Prerequisites      a. Data modeling tool. The trainer will be using dbdiagram      b. Postgres, albeit no need to install this locally, as I'll be using a Postgres Dicker image, from Docker Hub for all examples      c. Hasura

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
Top Content
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!
Vue.js London Live 2021Vue.js London Live 2021
24 min
Local State and Server Cache: Finding a Balance
Top Content
How many times did you implement the same flow in your application: check, if data is already fetched from the server, if yes - render the data, if not - fetch this data and then render it? I think I've done it more than ten times myself and I've seen the question about this flow more than fifty times. Unfortunately, our go-to state management library, Vuex, doesn't provide any solution for this.For GraphQL-based application, there was an alternative to use Apollo client that provided tools for working with the cache. But what if you use REST? Luckily, now we have a Vue alternative to a react-query library that provides a nice solution for working with server cache. In this talk, I will explain the distinction between local application state and local server cache and do some live coding to show how to work with the latter.