The Graph 🛠 Building Decentralised GraphQL APIs on Ethereum with The Graph - Vishwa Mehta

foreign [Applause] [Music] I'm super grateful for patient audience always because like you never know what goes wrong with like demos and the demo cards are not happy with me like ever so I think that's what happened today but we're gonna make do with what we have super excited to be presenting here um in my home country uh in global hackathons have always been super close to my heart because I started um in the beginning of this year in a new space um with um my passion for graphql and I think that's what I'm bringing to the table for you folks today um so we're going to be learning how to build decentralized graphql apis using the graph so a quick show of hands before I give my introduction or like go into the specifics of it how many people here know graphql or have heard about graphql that's that's a good number I'm impressed um how many people know about the graph awesome we could we could work with that awesome awesome so um today we're going to be learning how to build Azure nft smart contract a uh an API for the Zora nft smart contract um using the graph but before we jump into that hi I am wish short for vishwa Mehta and I am a developer relations engineer at the graph foundation and um this is what what I do I am super passionate about developer education and um right from the start right from my University days I've always been um really excited um about like talks and giving workshops making sure that any um content format that I can you know contribute to is helpful for developers so that I can help them become successful with the tools and the Frameworks that they're using so that brings me here again if you have any questions by the end of this Workshop presentation talk whatever feel free to reach out to me on Twitter at vishwa Mehta 30 and with that we jump right into it doesn't want to move okay um so let's talk about what the graph is let's start with right from the beginning so the graph is a protocol and indexing and querying protocol for web 3 for networks like ethereum ipfs and so much more so but that's a lot of like jargon web3 decentralization graphql the graph indexing querying so I get a lot of like questions around where it fits into the stack so let's look at this tag you folks are here at a hackathon right so you will be building projects you will be building tabs um so let's kind of like picturize where the graph sits into your dap stack right your web development stack so I really love this diagram because it shows the UI layer the subgraph indexing layer and there is the contracts which is your data layer so the graph as an indexing layer sits right between your front end which is your UI and your back end which is basically all of the data that is coming from Smart contracts on the blockchain right and um with that sub graphs are becoming a de facto standard of how you query data that is being indexed by the graph protocol from the blockchain and uh that's why we say that the graph is now a default part of the web3 stack awesome moving forward uh let's talk about the data scenario here I get often I often get the question like where does the graph come into picture we we saw when it fits into the stack but like we we haven't yet talked about why exactly the graph right why should you be using the graph how it is going to be helping you in your journey uh so I I think I need to begin from the data bottleneck that we have um in this data driven world of ours nothing is possible without accessible data right and especially with blockchain data if you're building decentralized applications you want to make sure that your UI has a very robust experience for your users you're bringing very fast and performant and efficient uh UI ux to your clients and for that we need index data so that is point number one point number two is that blockchain um has can anyone guess like how many blocks so far ethereum has the block count any guesses wild guesses that that's that's an accurate one yeah yeah it keeps changing and yeah um I think the number that I saw right now is like 16 million so it's in the same ballpark but it just keeps on increasing and every block has thousands of transactions again it just like keeps on increasing by the hour by the day so what I'm trying to say is if you want to build a dab using blockchain data which is increasing like day by day it becomes increasingly difficult to index that kind of like heterogeneous data which is out there on the blockchain it is D5 data it is nft Data dials governance whatnot so what if you want like a very specific piece of data right um do you start indexing the entire blockchain like do you start indexing all of ethereum no so that's why we need organized data which is well suited for your web 3 applications your decentralized applications um and as a solution developers have been building proprietary indexing servers um so far now let's jump into why we don't want to do that is because it is error prone it is a lot of like complex code that you will need to write but three main points the first one is that if you're building um a proprietary indexing server it is a centralized point of failure which defies the ethos of F3 which is decentralization it just goes against why all of us are here hacking and learning at this hackathon right so that's Point number one the second is that um it's a lot it's a single point of failure so if it the indexing server goes down everything goes down you don't want to do that um and the third but again most important point is that it's a lot of infrastructure to manage it is a lot of investment of hardware and engineering and monetary resources in running that one indexing server all by yourself whether you're a team or an individual engineer now that is where the graph enters the scenario um and that's why we say that the graph is in it gives you a global open API but it's not just an API it's a decentralized transparent and open network of participants like subgraph developers indexers curators and delegators and it is making sure that you can index your blockchain data efficiently but also um can do it in a more decentralized manner and of course um it's built on top of graphql so it brings the benefits of graphql to your table um if you want to learn more about graphql I think it's a pretty nifty thing for front-end developers um and it has been a game changer in the data accessibility landscape so basically using graphql the graph has built a unified data access layer for blockchain so no matter which data is coming from which smart contract it is woven into your sub grab which is pretty basically like a single endpoint um that you just like query every time you want your data from the blockchain to your application and the graph has been powering D5 applications not just D5 applications but this has been like one um vigorous use case um and also a really exciting one um so it has been querying on-chain data like trades and exchange volumes total borrowed supplied stake yield farming total value locked and so much more so all of these like cute little icons that you see um these are like projects that um have been powered by the graph D5 projects and if you talk about other some of some of the other leading projects in let's say websites is coin market cap coin gecko if you've heard about it then there's like nfts in Dallas so Juice Box Dao there's foundation in the world of T5 I'm sure you've heard about it it's uniswap and then there's synthetics all of them are powered by subgraph data through the graph and we have um a hosted service that we started with um about 44 years ago so for four years or it has been supporting subgraphs and subgraph developers um but it was a way to start with um our initial idea so that we can make sure that we achieve product Market fit uh we have tested it out before we go live with the decentralized network and we have had the time to get good feedback from our developers um so we started with the hosted service which was run by our one of our code Dev teams our original code Dev team um Azure node but from from that now we're moving away by sunsetting the hosted service because we want to make sure that we can um find a solution which is more scalable and more sustainable um and also fits into the web 3 mission which is the decentralized network of the graph um and so we've successfully migrated 350 plus uh daps and have been they've been like paying queries for GRT uh in GRT on the network um so 39 plus I think the count is a little bit um higher now uh all of these chains amazing chains that you see and you've probably worked with built on are supported by our hosted service and with that I think we've discussed the graph a lot we've talked about what sub graph subgraphs are and we've talked about like why it makes sense for you as a developer who's building dabs to absolutely use the graph in your stack so let's see some code um now I typically do like a live demo of this like a live um coding session so that I can take you through the entire process of like how to use the subgraph studio how to get started by initializing your sub graphs scaffolding it um designing it as per your use case as per the data that you want um and then finally deploying it but um just to make sure that we're right on time and also to make sure that nothing breaks because of the Wi-Fi I'm just gonna run you through the code here so um here if you see the subgraph um so this hasn't load loaded yet but basically if you want to get started you just need to go ahead and go to the subgraph studio on the graph.com website and um create a subgraph so I'm just gonna show you like a nice little screenshot of it so this is uh something that you will be seeing um the prerequisite here would be that you um will need node.js installed on your machine to make sure that you can install the graph CLI um and then that you also have a metamask wallet using which you can sign into the subgraph studio and you go ahead and first create a subgraph slug basically just create a sub graph on your dashboard the next thing you see will be this kind of like a dashboard for your sub graph with some documentation really helpful documentation on the side and now I'm gonna run you through the kind of like um commands that we need the first one is um the npm install command for the graph uh graph protocol CLI so this is just a one-time thing once you've installed the graph CLI it's going to give you some really cool utility commands that you can use to scaffold and design and deploy yes your subgraph for that you can either use node.js or you can node you npm or you can use yarn um when you're done with that uh you are gonna be like we want to initialize our subgraph so the graph init command is one of those like commands given by the graph CLI um that you see here um and it basically scaffolds your sub graph it gives you some boilerplate code to get started with and let's go ahead and see what kind of boilerplate code it has given us and this is Frozen I think I'm just gonna give it second I guess yes we got it awesome so once you've initialized the graph uh your your subgraph this is what you're gonna be seeing basically and it's uh I I think it's a pretty cool folder structure right here because it's super clean you see it and you know that there are three main files that we want to be looking at the first one is the subgraph.yaml file which is your typical configuration file that describes your subgraph um like which kind of um Network you're working with the name of the token that you're working with and um your data source that you want to pull in as a smart contract from the blockchain so that is basically this right here um now you want to enter and this is basically the smart contract address of the nft the Zora nft smart contract that you can get from the Zora documentation and just want to call out one really useful information is that you would also want to um Define a start block is because you don't want to start indexing from the Genesis block if you know which block you want to start indexing from uh just go ahead and pop in the start block ID here the address and um and then there are a couple of entities here um so enters entities I will go more deeper into this when I talk about the schema.

graphql file but just as a quick overview entities are basically all of the fields of data that you want your sub graph to query from the smart contract so for example there is the Zora nft smart contract right so here we're defining two types of entities which is like token the first one is token which is all of the nft data and the second one is user which is the user metadata and I think it's gonna start making more sense once you see this schema.graphql file but before we move on to that one last thing uh here in the subgraph.yaml file that you would want to Define is the event handlers so every um smart contract will have events that it emits every time you start indexing it and you want your subgraph to listen to those events to make sure that there is some kind of business logic that is implemented when you listen to those events and then when the business logic is implemented your um your local code and the code on the the and the events is being mapped and you can query all of that data from the events to your client so here we will be dealing with two kinds of events um basic events from the Zora nft smart contract which is token URI updated so every time the URI of your nft is updated this event will be emitted and we want our subgraph to listen using mappings to make sure that we can query that data and the second one is the transferred event so there are two scenarios here either a new nft would be minted and in that case the this event will be emitted but it could also be an existing nft whose ownership is is being transferred from one owner to a new one and we're with that we can move on to the schema.graphql file I know we're moving fast here but um we can all you can always come back to me with questions um I'm just trying to make sure that I can give you a good overview of the folder structure of the subgraph but everything else that you see right now is super specific to what kind of sub graph you want are defining is it like an nft API is it for your D5 use case is it for governance Etc so the schema.graphql file you see right now is basically a graphql file if you work with graphiel at all you can understand what this does is that you're telling your sub graph what kind of data it wants to query it needs to query from the blockchain so I want all of the nft data and the corresponding user metadata so that's why I'm defining using at entity directive I'm defining two types which is token and user so for the all of the token data and the user metadata I'm defining these two types and the at entity directive is a basic graphql directive that lets you define types with top level fields for all of the data that you want your graphql API to query and give a responsive um so it comes with all of the other fields like if the token has an ID a created ad timestamp metadata and content URI Etc and then the corresponding creators and users of the nft are then be being stored as uh using the user object type here so there can be a simple type in graphql and there can be an object type which is basically the user type that we've defined here which can then further have its own sub level fields that you can query so for the user metadata we want to be querying all of the tokens that are being owned by an owner and all of the tokens that are being created by a Creator all of the tokens that are being minted right um so that are those are the two relations that we're defining as part of the user entity the user user type that you want to query using your sub graph um and we're doing that again with another really cool really Nifty directive uh the graphql directive which is derived and derived from directive um now basically instead of this directive you can use alternatively you can create an array um of all of these like creators and owners but this is something that's um a bit more performant that's why we're using it here and once you've done that um you want to move to the mapping.

ts file so basically what the mapping.ts file is it's it's a file where you Define all of the business logic that you want to run once your subgraph has started um using like querying all of the index data and the smart contract is emitting the data so you want to map the events that are being emitted by the smart contract to some kind of local uh locally defined um functions or let's say like event handlers basically so you want to handle those events that are being emitted um and the graph the cool part of the graph CLI is that it comes with typescript support out of the box so it gives you really cool um typescript library that gives you some helper functions that you can import while writing your mapping.ts file to make sure that you're writing um your handle your event handler as well uh and easily so to to be able to do that uh there's another command which is called the graph code gen command um it's basically just you just enter graph code gen you run it and um it will give you like the uh out of the box typescript library that there is it will generate all of the um the helper functions and that you can go ahead and import here in the mapping.js file and once you've done that so if you can see here in the generated folder the functions that it has generated for us to import there are basically two types of functions the first one that you see token is something so um you can only read data from the smart contract from the blockchain but you can both read and write data to the graph node which is like a local storage um so the schema uh the generated schema file is basically giving you all of the functions that you need to interact with your graph node which is basically reading and writing data onto it um because you also want to save data that you have gotten from the smart contract and then the token one is the generated uh file that lets you gives you functions that will help you interact with your smart contract like read uh data from the smart contract and finally we have defined here the two um event handlers for the two events that we were dealing with here in our subgraph is it's basically handle transfer event and the handle token URI updated when so any events that you're dealing with you would want to write an event handler so that you can perform some kind of like business logic in your subgraph once you start listening to those events and um so this is basically like assembly script so anyone who has used JavaScript or type types grip this should be a very familiar kind of Syntax for you and I wouldn't just to stay within timing I wouldn't go deeper into what this exact code does um but basically I've already defined what each of those events meant and so we're making sure that every time the event happens and there's an updated piece of information we're saving it to the graph node and we're retrieving it from the uh the smart contract and we're saving it to the graph node so that we can query it via our subgraph later and once we've done that I think we're super close to the end of it which is that you have uh initialized your graph as your subgraph you have defined it based on the smart contract that you want to be using and the kind of data that the kind of events that you want to deal with and the final piece here would be to deploy and see if it's not happening so the final piece here would be to deploy your subgraph so we have another um another command here that lastly you would want to run is the um the graph deploy command and it should if you go to the graph documentation you should be able to see the graph deploy command so you authenticate your subgraph finally and then using your API access key and then you deploy the subgraph getting a little stuck here and there but um while that happens so sorry about that while that happens um I think we've concluded our Code walkthrough of like how to initialize a subgraph how to define it and deploy it and what's once it has been deployed in your subgraph dashboard you should be able to see that the subgraph is now it just went off cool you will be able to see that the subgraph has now been been deployed and there is like a really cool um like graphical playground that you can see um where you can run some sample queries and you can test out whether your sub graph is working or not and uh I think I lost my presentation um never mind so um so you can you're once you've deployed your subgraph you should be able to test out the sample queries in your graphql playground so um come by the booth I might be able to show you the actual live demo um so if this is interesting to you um test out subgraphs we are giving away cheat sheets at our booth and um I think Simon has already um you know done that here as well so um the cheat sheet is basically um a good one-on-one of like how to use subgraphs how do you like what kind of commands you need to learn to basically initialize create and deploy a subgraph and so if you're hacking at this hackathon if you're building a dab um the main takeaway here from this talk slash Workshop is that um subgraphs are a really cool way to efficiently Access Data from the blockchain and it's a it's a really cool decentralized graphql API that you could be building for your dab as long as you're dealing with on-chain data so basically there's like no um programming language barrier it's language agnostic so whether you're using python on your front end you're using JavaScript any kind of like react framework you view framework some graphs are still relevant the graph is still relevant and it is also Network agnostic so if you're using the hosted Service as I said um we're live on 39 plus chains so it also doesn't depend on what kind of network you're using and with that I uh will conclude my talk and thank you so much for being such a patience audience