Building GraphQL APIs on Ethereum

Hello, my name is Nader Dabit. I'm a Developer Relations Engineer at Edge and Node. And today I'm going to be speaking about building GraphQL APIs on top of Ethereum, but also the Ethereum virtual machine. You can think of the Ethereum virtual machine, it's kind of like the React of the blockchain world. You learn this one skillset, and you can build not only on the Ethereum blockchain, but any EVM compatible blockchain, meaning a handful of different Ethereum layer twos and side chains, as well as other completely different blockchains like Avalanche, Celo, and many others that are out there.

So with that being said, let's go ahead and get started. So how we interact with and build on top of blockchains is much different than what we're used to in the traditional web. In a blockchain, data isn't stored in a format that can be efficiently or easily consumed directly from other applications or front ends. The problem is that you need to have the data indexed and organized for efficient retrieval. Traditionally, that's the work that's done in the centralized tech stack, but that indexing layer was missing in the Web3 stack.

So in the traditional web stack, databases, servers, APIs, they filter, sort, paginate, and join data before it's returned to our client applications, typically via some type of HTTP request. And these types of data transfer nations are essentially not possible when reading data directly from Ethereum or other blockchains. So in the past, developers and teams would build out and operate their own proprietary indexing servers. But this requires significant hardware and engineering resources, and also broke the important security principles around decentralization. So around the year 2018, the graph began being built to solve this problem. The graph is an indexing protocol for querying blockchain networks like Ethereum and IPFS.

So let's talk about how the graph works. So let's take a look at a couple of other indexing systems that we might be using in the day to day world that we're already used to. So search engines like Google crawl the internet, they index relevant data and they make it available for users like us to search via their web interface or their APIs. And without this indexing layer, it would be kind of hard for us to know where to look for, where to look and how to find relevant information across the web. So you could think of the search engines that we use on a day-to-day basis, kind of like an indexing layer. Another similar analogy is a library. So using an indexing system like the Dewey Decimal system, we know exactly where to find the book that we're looking for without having to go looking book by book throughout the entire library.

Using the graph, developers can build APIs called subgraphs. A subgraph defines how to efficiently index data in a deterministic way and make it available for querying from frontend applications. Subgraphs live in between the blockchain and the UI, providing an important piece of software infrastructure, a flexible, performant and decentralized API layer. Once a subgraph is deployed and the data is indexed, apps can start querying the data without relying on any centralized service provider, and instead they can lean on a query marketplace that's comprised of a decentralized network of indexers, all competing to provide the best service at the best price. Right now the graph serves over 1 billion queries per day, and many types of applications in the Web3 world are using it, including DeFi, gaming, NFT marketplaces, and a handful of other types of applications. So to get started, you would go to thegraph.com, and in the user interface here, you can go ahead and define the subgraph name, along with any other searchable metadata that you'd like to be made available. Next you would use the open source graph CLI tooling to scaffold out a subgraph locally that you can then begin building on.

Next you would define the data model, which is essentially the GraphQL schema, the contract addresses that you would like to have indexed, and any other configurations that you'd like to have set up locally. The GraphQL schema would look like any typical GraphQL schema. The main difference is that we do have a couple of different directives that allow you to interact with the graph network, like, at entity, as well as, at derived from for creating relationships between different data types.

When you're ready to deploy your subgraph, you can then run graph deploy. And then once the deployment is successful, you should be able to start testing it out directly in the graph dashboard. So here we have a graphical editor, we also have a different logs for any errors that might have happened when you deploy your subgraph. And then when you're ready to query, you can just query it like you might have done from any typical applications. So you can use a GraphQL client like Apollo, or Oracle will be giving you the GraphQL endpoint from the graph dashboard. And then you can just run whatever type of query that you would like. And everything should work just like any other GraphQL application that you've probably interacted with in the past.

So with that being said, let's go ahead and go to the graph.com and see what this looks like. So here we are in the Graph Explorer, and you can see that we can view all the other different APIs that other people have deployed. So these are all completely open and public. So if we'd like to view one, we can click on one. And we can see that we can test it out. We can run different queries here and the playground. We can view the graph graphical introspection here. So anything that you would like to know about a subgraph should be available here. But let's go and test one out. So I'm going to go down here to search and I'm going to find the foundation subgraph, which is something that I've created a couple of. And here we can go ahead and test this out. So this is a subgraph that queries the NFT marketplace foundation. And we'll go ahead and just run a query here. We can see that we have all this data coming back. So we have this content URI. This is going to be something that we can fetch and use for finding all the different metadata for an NFT. So here we have the IPFS path. So we can test this out by going to IPFS.io slash IPFS. And here we see that the data is indeed coming back. So if you'd like to learn more, if you'd like to build out a subgraph yourself, I would check out the graph.com slash docs. I would also maybe check out this workshop that I've created at github.com slash dabit3 slash building a subgraph workshop. And if you'd like to learn more about the graph, check out the graph on Twitter at graph protocol, the graph.com, the graph docs or join our Discord. That's it. So thank you for checking out my talk.