The Graph Featured | Building On Ethereum With GraphQL, The Graph, And Next.js

Republished By Plato

Followers: 0

Using scaling to address Ethereum congestion is undoubtedly helpful for larger adoption. As we all know, expensive on-chain transactions and spiked user experience are reasons why Ethereum network urges for scaling. Optimistic Rollup and ZK Rollup are two prominent Layer2 solutions. Optimistic Rollup is EVM-compatible with low technical cost, while ZK Rollup has shorter withdrawal duration and lower on-chain computing cost. zkSync, as a EVM-compatible ZK Rollup, is showing robust momentum.

Our 3rd workshop, presented by The Graph, of the series in IOSG Ventures & Chainlink Layer2 Hackathon, was live on July 18 at 8:00pm. This live has received a great bunch of supports and likes from our lovely audiences! Don’t worry if you missed out the video, click and watch the replay below! We also bring the full wrap-up in text for everyone who would love to read and learn more about it.

— Let’s get started!

So yes, I’m at the beach. That’s where I’m going to be streaming, from the beach. Because that’s what we do. We work wherever we want, and today I’m working from the beach. I’m going to be streaming from here. I might take a little break in the middle of the streaming, grabbing something to drink or food or something, because we’re going to be here for about an hour.

But today we are doing a big launch of The Graph. That’s what I’m going to be talking about today. We have a pretty cool project that we’re going to build out. I’m going to talk about some of the ideas around some of the stuff that we’ve done here, so we’re pretty excited about this. I’ve only been on this team for about three months, but they’ve been working on this for like four years. So some of the ideas that are launching today have been thought out, but they’ve been theoretical ideas, even concepts that had been thrown around industry but no one’s actually implemented something that’s this complicated and this comprehensive with a user interface that people can actually interact with on a bunch of different level. So we’re pretty excited about it.

What I’m going to be doing today is just showing how to build out an API used on the front end. I’m going to talk a little bit about the network and how you can participate in a few different ways. We’re going to be writing some code today. So that’s mainly what this is about. If you haven’t seen the launch, let me go ahead and link to it here. See if you can check out some of the work that’s been done just by reading over the blog post.

Yeah, someone mentioned the Ethereum Conference in Paris. I don’t have tickets but still I will be there. So even if you’re in Paris, and you don’t come to that conference, hit me up. I would love to hang out and bring in a bunch of Graph swag. I am bringing T-shirts, and I am bringing stickers. I’ll buy you a drink, or I’ll buy you coffee. I might even buy you dinner. I’m going to be there for about a week, so I’m looking forward to that.

I shared a link to the launch. What we launched was two new products or two new features of The Graph. One is called the Subgraph Studio, which allows developers like myself to build these open APIs on top of open datasets. I can curate my own API, meaning that I can basically say, hey, I want someone in the network to start indexing the data from my API. And I can start earning money based on the feeds that I am able to generate. I can basically find other people’s APIs and I can signal on those and make money from those as well. I can be a software engineer that just runs a node, an indexer. I can make money that way. So there are all types of ways that you can make money.

What interests me the most about this is that I think this is going to be incentivizing in a way that allows people to make money. That’s the best incentive. That’s one of the incentives that drives me the most. Mainly because I grew up, I would say, poor, or anything like that, but I would say, for the first ten years of my life, I was hardly making any money.

So the software has been enabling me. I’ve seen a lot of other people around the world, a lot of people that are actually part of The Graph protocol all over the world that have been participating since early on that they have financial freedom because of it. So I’m pretty excited about the incentive there.

I think that’s one of the coolest things anyone can come up with an idea using all of these open datasets that are available from any of the different types of networks that we support. Right now, it’s mainly blockchain and decentralized data sources. But the idea in the future is that we’ll be able to have our indexers deal with any type of open dataset. A lot of people are actually getting around that today about actually finding datasets that they want to index and building them into some type of existing networks. Writing those transactions themselves and indexing them on a Graph API is also possible.

With that said, let’s come up with a cool idea for an app or an API. And I just put that API together. I deployed it. It’s now on the UI. You can go check it out in the Dashboard. Anyone that wants to use it can now build a front end on top of it. They can use the smart contracts as a transaction layer like how they would before, but they can now query those on their front end. We’re going to build out a UI that shows that. Doing so, anyone that wants to use that can use it, and any money that gets charged for that is now instead of going to massive companies like Google and AWS. Of course, the people running their infrastructure might still be on those but the actual profits are going to the developers. To me, that’s one of the coolest parts as well.

So with that being said, that’s just a general overview. If you’ve been following The Graph, you understand some of this already. But I think a lot of the people, the miner workers you know, are web developers that are in the traditional web space. Still fairly early days. Even though we’re starting to hit some really wild and interesting numbers that they recently hit over a billion queries in a single day. We’re growing on a really fast cliff. That exponential type of growth is what you look for when you get in on a company or when you want to get in early on a technology. It’s not about the actual total number today, it’s about the growth, because in a year you stay at that same growth, you are going to be crushing it. So that’s what I’m interested in.

With that being said, I’m going to start building. To do that, I’m going to be sharing my screen. Let’s go ahead and do that. I’m going to go ahead and get my computer ready. To start doing this, I’m going to close some of these apps that have opened. Start sharing my screen. All right, there we go. This is The Graph website. You’ve probably seen this already. What I basically want to do in this video is show you how you can build out an API and deploy it to the new UI. The studio here. Then build out a front and on top of it using Next.js. That’s what we’re going to do.

To get started, I’m going to go ahead and create in my terminal an empty window. To do that, I first need to increase the font size, because that’s really small. We’re going to bump this up to something like thirty-three. All right. I’m in my terminal window where I’m going to create a new Subgraph. I think if you look at the Explorer which is also something we are launching today, you can see some of the apps. Some of the APIs are already on the decentralized network. PoolTogether is a really popular one. Uniswap, of course, doing billions of dollars in transactions. So pretty big apps are already here. These are like our launch partners, people that launch today. But if you look at one of these APIs, you’re familiar with maybe some of these applications that they’re driving. A lot of these are financial applications. To me the more interesting ones for demo purposes are actually artwork, the visual stuff. The thing that I’m going to be building out is for an NFT marketplace to visualize that. Because I think financial data is harder to visualize. It isn’t interesting for a user interface demo like this.

Basically, what I’m going to be doing is building out a Subgraph. So we go to the Legacy Explorer, and I go to Zora. You’ll see a bunch of Zora Smart contracts that had been deployed for Subgraphs. Then using this data like the content of a URL like this, you can actually see a little bit more interesting data. So I order by ID, then we pull up something from here. When you have stuff like this, it’s a little cooler like videos and stuff that you can actually show. This isn’t loading right now. Let’s see here. Maybe I can find an image. There we go. Stuff like that. That’s what we’re going to be doing.

Let me just check and see if there’s any questions that I’m missing. I should have. I will get back and answer questions when I have a moment.

This is being recorded. It will be available on my Twitch as well as my YouTube later. What I basically want to do is build out for Zora. So zora.co and this is their website. They have a bunch of NFTs that people are buying and selling. This is kind of what I want to build out a UI for. Another interesting one is Foundation. If you go to foundation.app, this is actually really nice as well. You know you can see the current bid, so this one is like four thousand dollars or two Eth. This one is like five thousand dollars. So this one Foundation and Zora would help us get a decent amount of action.

I’m using Zora. Zora again is an NFT marketplace. We’re going to build out a Subgraph, and then we’re going to build out a UI for that. To get started, I’m going to Subgraph Studio. I’ll go ahead and create a new Subgraph. This is going to be Zoralivestream. And here see that, we have our Subgraph available now in the Studio. We can now basically create and write the code locally. Then we’re going to deploy this thing and push it up here to the actual Studio Dashboard. We have some instructions here on how to do that, but actually the best instructions are going to be on the new website. The new docs that we have. You can also go to the blog Building Subgraphs with Subgraph Studio. This is actually going to be essentially what we walk through today. Actually I personally wrote this blog post. This is going to be the API that we’re building today. It should walk you through all the steps.

So we’ve already created this. We now have our slug. The status is UNDEPLOYED, meaning that we’re not deployed right now. We have our deploy key. We have some installation instructions, Graph CLI and things like that. This is what we’re going to be using. Now we’re ready to start writing some codes. Now that we have this place over here, we can go back to our CLI.

I’m going to go ahead and install the CLI. I think this is already installed I assume. I’m just going to install it again and then once this is installed, we have the binary. And we could start using The Graph CLI. While that’s installing, I’m going to go through this tutorial. This is essentially again what I’m kind of walking through. This shows you how to kind of get set up. I’ve already passed that up. I’ve created my Subgraph, and now we’re kind of be right here where we install. Now that we have The Graph CLI installed, you should be able to just run graph. And see the binary is giving you instructions there, graph — help will kind of give you some common commands. What we want to do is init, so we want to initialize the Subgraph. What this basically do is create all the boilerplate that you need for your API. This is going to be the command that we run graph init. Here we pass it a couple of flags. So we’re passing the contract name. So this is going to be what we’re calling this data source. And for us, it’s going to be token, because these are going to be digital assets using the OpenZeppelin ERC721 standard, which is a non-fungible Token. So Token makes a lot of sense.

We’re going to say index-events, meaning that we’re going to look inside the APIs, or the application binary interfaces, which is an Ethereum smart contract. An API essentially that you can use to interact with a contract. It will look inside of the ABI and will pull down the actual events that are admitted, create some boilerplate code locally for us. So this just a helper to write some code essentially for us based on the events .

We also were saying we want to use Subgraph Studio, because now we have both the hosted service as well as the Studio. The studio is what all most future apps are going to be using, but we still want to support the old service. We specify studio, and then we can also specify that smart contract that we’re working with. So I said we’re using Zora. This number here is the Zora smart contracts. How would you get that? If you go to Zara developer documentation, you can get it there.

They had a link to the smart contracts here. Of course, though, you can go to Etherscan. Etherscan has pretty much everyone’s smart contracts listed there. And you can find it in some other ways, but I would say a lot of contracts have their address public. So in this case, Zora even goes as far as to have a developer documentation site. Foundation also does this, so Foundation is cool too. Fnd.dev has all of their Subgraphs. They even have their own Subgraph that they support. I think Zora does as well. Yeah, they have their own Subgraph. So you could use their existing Subgraph, but we’re basically building on our own from scratch.

So that’s kind of from where this contract comes. The contracts are just right here. So now that we’ve done that, we can just hit enter and this should go ahead. To walk us through the steps, we only really need one more thing the Subgraph name. I can just copy that from the slug right here, then all of these things we could just take the defaults. So this is going to create all of that boilerplate code locally for us.

Now I should be able to go into this new directory and go ahead and open up my text editor. All right, cool. So this is our boilerplate code, literally everything you really need to publish a Subgraph. It’s made up of other three main parts. If you can understand these three main pieces, you can build an API on top of any of the networks that we support. You have the schema.graphql, which is graph’s schema. We could delete all of that for now. We have our subgrph.yaml. This subgrph.yaml is your configuration. It is by default about thirty-five lines of code that’s given to you, or just going to be a little bit less, but your subgrph.yaml is basically almost like the infrastructure of code. We’re telling the indexer that we’re deploying this API for what to do with the data sources that we’re going to be working with. We’ll look at that a little more in a second.

Then the last thing you have is your src/mapping. So these are mapping templates. If you’ve ever worked with something like AppSync, or even The GraphQL, you probably worked with a mapping template in the past. So these just define…they’re essentially handler functions. You have the events and you want to handle those events. In our case we might have an event where someone meant to do token and we want to handle that data. We want to store it in our local our own API we’re going to store that and make it available. So the mappings. A lot of these ideas transferred me directly from the GraphQL days working in the Web2 space in traditional applications and stuff. So those are the main things, your schema.graphql, your subgraph.yaml and your mappings.

The first thing we’ll mess with is the GraphQL schema. I’m going to copy and paste some of the entities of the two types that we’re working with. One is the Token type and one is the User type.

So if we look at Zora, you see that we have these NFTs, and they are associated with a user’s address. So we want to be able to store that information, and we also want to store the metadata about the token itself. So that’s why we have these two entities.

For the token, we just have all the metadata that we want to store. We can get this metadata from the actual event that we’re going to be working with. Or if we really wanted to, we could actually go out to a separate smart contract or data source and get data for a type. Or we can actually go directly into The Graph node itself and get data as well.

If we really wanted to, we could actually go out to a separate smart contract or data source and get data for a type or we can actually go directly into The Graph node itself and get data as well.

So in the mappings, you can essentially work with different data sources that are going to populate the types that were defining here and if you’ve ever worked with the GraphQL.

You probably understand that an exclamation point means it’s a required field and if it’s not exclamation point means it’s an optional or a nullable field so we’re going to store the token ID, the contentURI, the metadataURI, the createdAtTimestamp, the creator and the owner then we have the user type the user is basically going to have a one-to-many relationship so a user has many tokens that they’ve created here and then they have many tokens that they’ve purchased so a user can be a creator or a consumer and the way that we create the relationships or using these directives.

And if you’ve ever used something like Amplify and many other different GraphQL instructions you might have seen something like this where you have a directive and in this casewe’re kind of saying we want to have this created field derive from the creator here which is an address so the address would be a wallet address and then basically this is going to give us the ability to have a relationship between the token and the user and the user and the token itself or I would say the array of tokens.

Alright, with that being said, we can go ahead and save that and we have our subgraph.yaml so here we’re going to make a few changes we already have the address, which is set when we created this. The next thing we want to do is set the startBlock. The starkBlock is basically going to tell the indexer where to start indexing this data because if you deploy it as it is it will start from the genesis block of the blockchain so it will go to the very first transaction on Ethereum and worked his way up from there which is time-consuming so instead what we can basically do is set the startBlock so for the startBlock you can go to the smart contract itself.

Let’s see here. I think this is the contract itself so how would you find this so you can go to Transactions. You can go to the very last transaction and this is it right here so that’s the first start block that we would say that’s kind of literally the block that we’re using here.

Now, for the entities this is the next step that we want to make these are going to match the GraphQL entities so we have a token and we have a user the last thing we want to do is deal with the eventHandlers the three events that we’re going to be working with are going to be transfer this event is fired every time a token is created or a token is transferred so if I create a token this event gets fired if I transfer it to someone else, this event gets fired this is a good way to keep track of all the tokens that are in existence and then the other two handlers are going to handle updates so if I change the metadataURI, I change the tokenURI, I can track that here.

So these are going to call functions that are in our mappings called handleTokenMetadataURIUpdated, handleTokenURIUpdated and handleTransfer and that’s it.

We can go ahead now back to our CLI, what we might want to do is write our mappings in order to write our mappings we actually had a library called the GraphTS which is a Graph typescript library that we support along with CLI using this library, you can talk directly to the blockchain itself you can talk to Ethereum but you can also talk to The Graph node if you’ve already stored some data there and you want to retrieve that data you can talk to it.

We actually use The Graph CLI to generate a lot of this code for you that makes it pretty easy to work with to generate that code all we need to do is run a graph codegen. This will do a combination of things, it will look into our GraphQL schema as well as the ABIs for the smart contract. It will go ahead and generate a bunch of functions as well as types for us to use so the types have been generated successfully.

We should be able to go to our generated folder and see some stuff that’s been generated the two classes that we should have are token and user so that’s good we’re not going to need to update this or anything just showing you what that does the next thing we’re going to do is open the mappings.

I’m going to just go ahead and delete all this stuff. We’re going to go ahead and import the stuff that we want to use so if I go to the blog post here. This code is formatted not too well but I will format it in just a second. The first things that we’re importing are from the token folder which is under the generated folder the TokenURIUpdatedEvent and TransferEvent are events that allow us to have type safety. The token contract referenced here is Token as TokenContract. This is a class that allows us to interact with the actual smart contract so we can make calls to the smart contract using this and then Token and User. I think these are classes that allow you to talk to The Graph node so this basically means if I store something as an indexer, I want to retrieve that data. I can use these classes here we have three functions we need to deal with so handleTokenMetadataURIUpdated, handleTokenURIUpdated handleTransfer so we need to have basically three handler functions in our mappings so the biggest one is this handleTransfer this is a function that will handle the minting or the transfer of a token so with that being understood we need to handle a couple of different cases here.

We need to handle if the token has never been created before and we also can handle if it has already been created, right because if it’s being minted that means it’s not there yet if it’s being transferred to someone else that means it is there so the first thing that we can do is we can basically use the Token here from our generated code to first look into the existing node so we’re basically calling into that database. If this token exists, return it. If not, we’re going to go ahead and create it and then here we’re basically just setting a bunch of metadata like the creator, the tokenID and createdAtTimestamp. We then are going to call to the smart contract itself because in the event, we are only getting certain data but we can call back to the smart contract to get other data so the thing that we need from the smart contract is contentURI and metadataURI so we’re calling the smart contract here we’re adding additional fields to this object here

We have a token, we are adding the creator, the tokenID, and createdAtTimestamp. There is other content information as well. We then update the owner or we set the owner maybe because it could be a brand new token with no owner we then save that to The Graph node. We then also do the same thing with user if the user exists, we load the user and if not, we go ahead and create the user the last two functions that we need or for handling the handleTokenURIUpdated and handling the TokenContentURIUpdated so tokenURIUpdated just fetches the token and then updates contentURI and saves it the other one we have is TokenMetadataURIUpdated so we don’t have that defined yet so I’m going to go ahead and do that.

I’m just going to copy this event is actually going to be. Github Copilot is doing some work for me there so we have this tokenMetadataURIUpdated event. We want to set that metadataURI. I think we’re good so now we have written our mappings. We have three functions that we’re dealing with handleTransfer, handleTokenURIUpdated and tokenMetadataURIUpdated and then we have our Subgraph here that’s defining those events. I think we’re ready to deploy this thing.

So what I want to do is go to CLI and I’m gonna run graph deploy and here we can actually define the studio so we’re going to say dash dash studio then I want to go ahead and pass in the subgraph name which is right here.

I’ll give it a label of a version of zero point 1, and oh I need to go ahead, and first so let me go ahead and graph auth dash dash studio. I can get my deploy key right here, alright, so this should be deployed. So if this looks good, then we should be ready to go back to our dashboard here, and as you can see, it’s already been updated with the GraphQL playground. And now we can go ahead and start running some queries, and then we’re going to transfer this into our next JS app. So we might pass in some arguments like orderDirection, descending, and then maybe orderBy createdAtTimestamp, and then we already start seeing some data is coming back. If we look at the contentURI, we see that we have the actual contentURI coming back, for the content coming back. Alright so our subgraph has been deployed. If we want to know how to query this from our front end, we can actually go here for details, and we have our query URL, so I can copy this. I might go to something like a graphQL bin. I think it is.

You can see that we can also use this graphql bin, or any of these different GraphQL UIs. So our API is working. That’s the URL that we’re going to use. Now we can go ahead and jump into a front end application. So what I want to do is create a new next JS app. We’re gonna call this like zora UI. I guess that should show up here, and what we want to do is build out a UI on top of this API, so what I’m going to do is use tailwind, because tailwind is pretty nice. And I’m going to go ahead and install the stuff I need for tailwind, then I’m gonna initialize the tailwind project, and then we’re gonna go into the globals.css, and we’re gonna go ahead and do that.

And now we’re ready to go. So in the UI, I’ll probably go to index.js, and this is what we’ll do our work. Go ahead and delete all this code here, and the things that I’ll need are going to be useState and useEffect from react. And I’ll also probably need to go have some code that I can reference here. I don’t want to kind of like references directly, but I do want to kind of like use it to get started. So we have getServerSideProps. This is going to be where we call our fetchData function, and fetchData is going to call our GraphQL API, and then it’s going to come in here as props, and then we’ll just console.log like that and maybe we don’t even need actually useState because we’re gonna be using next year, so we can just pass it all in this props. So this is kind of where we’re going to get started.

So what I want to do is how do we actually call the GraphQL API. Well you know, we have our input here in our docs. We also have some documentation around. You know, different GraphQL clients, so you can use something like Apollo, or you can use something like URQL. I think I’m gonna go with URQL just because it’s a little less code. So I’m gonna go ahead and install URQL and GraphQL, so we have URQL and GraphQL installed now, and what I want to do is basically let’s just say copy all this code, and then we’re going to kind of break it up in our app. So we have createClient from urql. We have our API URL, the API URL that we want to work with is going to be this API. This URL here I’m in. For the query, we want to just use a query that we know is going to work. So we go back to my API, and just write a query, and then I’ll copy that and paste it over, and we will also say we want to get the first 10.

So that’s our query. This is gonna be our client. We kind of say create client. We set the URL, and then we can call that for the data, so let’s go ahead and just do this, and then just console that log data. We’ll just return like an empty array. Alright, alright, so we have our base functionality ready to go. We can go ahead and run this. So looks like I have to stop another server I have running, so localhost 3000, and when this runs, I think we should be seeing this logged out here. So there we go, there we have it. We have our data there, so we have data.data.tokens. So I might say return data.data.tokens, and then in our UI, we see that we have our tokens that should show up. All right, there we go. So we have our 10 tokens.

We have our contentURI. We have our metadataURI. The metadataURI has stuff like this where you have kind of like the mimeType, the name, the version, the description, stuff like that that you can use in your user interface. So that’s great. So we have kind of all the base functionality. Now we just need to build out some design on it. So for the design stuff and actually one other thing we might have to consider is like mapping over the data itself, because the way it’s coming back. We might want to kind of like to change it up a little bit, so for instance, one thing that we don’t know is directly from this data are things like the mimeType, so to get the mimeType which is going to allow us to display that, we actually have to call a fetch, call an axios or some types of HTTP request to get this JSON data. And that way, we can kind of know if it’s an image or if it’s a video or if it’s a gif, how are we going to display that.

We also just want this data, this metadata anyway. So what we can basically do is kind of like have a function right here that maps over this data. So what we’re going to do is we’re going to say something like data.data.tokens.map, and then we’re going to kind of like map over everything, and then we’re going to call fetch to kind of get that metadata now. Luckily I’ve already created a function that does this. That way, we don’t have to like walking through all of that. I’m going to go to my GitHub. I have this fetch data function. I’m just going to replace that with this. Maybe delete some of the console.log. Okay cool. So this function is basically going to map over all of the tokens and we’re going to call out to fetch the metadata, and then we’re going to kind of like update the type based on the metadata.

So if it’s mp4, we want to show a video. If it’s audio, we want to show audio. If it’s image, we want to show image, and then once we have that new updated metadata, or refresh, unless we broke something here, we should see that metadata. I think I’m going to update the query to just return the first one for now. Now I’m going to restart the server. Alright so here are our tokens, we have our metadata, we have our description, we have our mimeType, we have our name, and we have the version.

The last thing we want to do is build out the actual styling using tailwind and also have an example UI for that that we’re going to use. So I’m going to go ahead and copy this, and I will tweet out and make all this stuff available, and I’ll probably put it in the comments as well, but the code for this, but it’s nothing too fancy. It’s just kind of some basic css using tailwind, but what we’re gonna do is this — we have our props, we have our tokens, so if we refresh, we now see that we have our UI here, and what I might do now is instead of returning one, let’s go ahead and bump that back up to like 10. Oh that’s ugly. Oh I think I know what I’m missing, missing this. There we go. So now our UI is showing, you know, all the different NFTs, and I must have not taken into consideration some type of mimetype, so let’s see what mime type that is, or just may not be loading for whatever reason.

It looks like there might. Okay looks like this one’s loading. So it looks like this is audio. I’m unsure about why the audio isn’t working, but I can kind of look into that, but that’s kind of the demo we just wanted to kind of show you how to build that out, and I think the interesting thing you might do at this point, if you’re a developer and you’re willing to make money off one of your APIs, I think this is like, again, the power of having a self-governing application that’s out there in the wild that people can basically compete against each other based on quality to build out the most valuable different APIs, and you can actually publish this to the network and start earning query fees on it. So if you publish this, then anyone that wants to use it can use it, and based on the usage, you’re gonna make money. You don’t even really have to do anything. You just put it out there, and then if people use it, then you’re going to basically make a portion of the money from the usage, and this is done by writing your information and your transaction of the publication to the blockchain.

So this is pretty interesting, because you’re basically publishing and once it’s there, it’s always there, and you know, that’s to me pretty powerful, and if you want to do that, you would basically need to have some tokens, so I have some tokens and I can basically publish either to Rinkeby or the main network. So I can go here to Rinkeby, and here I have some tests, go ahead and publish this, select Rinkeby network and probably needs to do something with my go ahead and disconnect from all these different accounts, and then reconnect. We try this one more time. It looks like I’m having some issues publishing. I’ll have to look into what’s going on with that. It looks like I have. It’s showing I have zero eth for some reason, but that’s not the case. Oh I think I may I know what I need to do. Let me go ahead and disconnect, and then connect again. So I think I was authenticated with the wrong wallet, so after this is published, it’ll show up on the network, and I can test it out because this is the Rinkeby test network, but if you publish this to the mainnet, that’s when you would have people starting to basically be able to like pay if they user it.

So I’m going to stop sharing my screen and basically, start seeing if anyone has any questions or anything like that.

This interview was very fruitful, thanks to Nader Dabit from The Graph, a project that solves this problem with a hosted service that indexes blockchain data. These indexes (“subgraphs”) can then be queried using the standard GraphQL API. In simple terms, subgraphs are like developer-written data indexes for specific business logic, and once the business logic is deployed, then it will keep updating the corresponding database based on the deployment to make it easy for developers to extract and call at any time. We will continue to invite more guests to participate, whether in the form of interviews, workshops or any other way, we hope to bring more inspiration to those who are interested in exploring layer2 in depth, and to do our best for this!

— END

Nader Dabit currently works at Edge and Node to help build a decentralized future. He previously led developer advocacy for front-end web and mobile at Amazon Web Services; focused on GraphQL, cross-platform and cloud-enabled web and mobile application development. He developed applications and reference architectures on AWS using a combination of GraphQL and serverless technologies.

Next, we will have Polygon, Aztec and other projects bring us solid experience and great insights! More workshops to be announced soon. Stay tuned!

Polygon