Building Dapps with React

Thank you for that amazing introduction. I'm really excited to be here in person in London. And we had react advanced a couple of years ago. And of course, it's been a while since we've had any in-person events here, especially. But really, maybe in the last month or so, we started seeing them come back. So I'm really excited to be here and happy to be talking about something that I am extremely interested in. So, yeah, I hope you learned something here. So my name is Nader. I'm a developer relations engineer at Edge and Node. Edge and Node is a company that kind of falls into the blockchain, crypto, web 3 categories. And it was really only created back in February. So it's a really new startup. But during the last six months or so, since I joined, coming from kind of a traditional background, I've learned a lot. And I want to kind of share some of the ideas I've learned here with you and hopefully make them as concise as possible and just show you how to get up and running with kind of a stack that might be brand new to you if you've never really looked into the blockchain space. So my talk is called Building DApps with react. And we're going to be building a DApp. And DApp is an acronym for decentralized app. And a decentralized app is an app that kind of runs in the decentralized web. And when we talk about a lot of these, you know, terms that I'm going to be speaking about in just a moment, you've probably heard a lot of hype recently around web 3 and decentralized apps and decentralization and crypto and all this stuff. Well, as a developer, I've been speculating in crypto since like 2015 or so, just buying and selling tokens and stuff. But I never really looked at it as anything more than just a financial tool or something to kind of gamble on, essentially. I never really understood that people were building software with it. So I have been, I would say, writing code for like ten years. So how could I have not really looked into this any further until maybe a few months ago? I really don't know. But once I started kind of diving into some of these platforms and protocols, I realized that what most of these teams are trying to do is build new ways for us to build applications to power the web. And you know, the changes that are trying to be made happen or some of the things that are taking place are kind of a lot different than anything we've seen before. So often you hear people bucketing these ideas into something that people are calling web 3. In reality, we're just kind of building out decentralized applications. But the applications that we're building, again, are so much different than the ones that we've done in the past. So they kind of bring use cases that we've really never seen before in the past. So I think it does make sense to kind of try to categorize these types of applications as something different. A lot of the objectives that people are going for are a lot different than some of the things that we've seen in the past. I think one of the main areas of concern that people have are around things like data harvesting and how social networks work today and how attention is a currency that is kind of used against users. And we have things like, you know, surveillance, essentially, kind of like when we're interacting with applications, they're tracking us and all this stuff. So how can we build out applications that allow developers to get paid, that allow companies to make money, but they take away some of these negative constraints? So web 3 is kind of trying to accomplish that. You could say. And really, if you really want to boil it down to something extremely basic, you could kind of say that web 3 is the stack of protocols that enable applications to be fully decentralized or they allow developers to build fully decentralized applications. Now, when you hear about decentralized applications, it's kind of like, you know, the end goal. I don't think that everything can be built in this way or everything should be built in this way. It's kind of more of a spectrum that we're trying to get to. So let's dive deeper into this, and then we're going to start writing some code. So when you think of the Internet and the way that we build apps today, a lot of the reason that the Internet has thrived and become so successful is that we have common protocols that we can all use around the world and we can just expect them to work. So we know FTP, we know SSH, we've interacted with all these different protocols. If we put our application up, we can be guaranteed that our users can access it from anywhere in the world with HTTP, and there's not going to... We don't need any centralized intermediary in order for that to happen. It just works. So these protocols are widely adopted. They're not subject to change, and they're very well understood by developers, and we just take them for granted at this point. But there are a couple of pieces of functionality that were left out or that we just did not have access to up until really the implementation and the evolution of smart contract technology on blockchains, and that was native payment in native state. So what do we do to get around this? Well, we built out massively complex centralized infrastructure to fix this. When you think about payments, how do payments work? If a person in the United States decides that they want to wake up one day and send money to someone in another part of the world, what does it take to do that, to make that happen? Well, if this person doesn't already have a bank account or an ID, they first have to go get paperwork, go to some authority, receive an ID. They need to go then to a bank. They need to take money from another place. They need to open an account. They need to provide all this information to this bank, put the money there, and then they may or may not get a bank, depending on where they live, because there are still over 70 countries that don't allow women from certain categories or certain communities to even open a bank account by law. But let's say that they live in a place that allows them to open a bank account. They open that bank account. They then go to their computer. They create an email address. They then go to PayPal or Stripe or whatever. They then create an account. They then link their account. Maybe they try to link their account, but they get blocked for whatever reason. So all this stuff has to go through for this one person to do it, and then the other person has to do the same thing on the other side of the world. And then maybe the two things that they decided to use are not compatible, because PayPal doesn't work in their country. So in order to get around this, we've built more and more complexity. So we have more people, more companies trying to solve this problem. Well, with smart contract technology and blockchains, you can programmatically enable digital scarcity, resulting in assets that people are willing to exchange for other things, aka tokens or currency. So we kind of have now ability to build this as developers. We can do it in a couple of lines of code. We can actually send transactions between parties in just a couple of lines of code. That's why this is revolutionary. That's why things are happening here. Now what about payment? I mean, what about state? Well, right now, if we want to build a database, how does this happen? Well, typically we'll spin up a database in our living room, our garage, or maybe in aws. Now this is great, because it enables anyone to build a database without a ton of work, right? But there are drawbacks here as well. First of all, this database is a central single point of failure. So if something happens to our database, then our application is down. Also when you think about how applications are accessed from around the world, if you want to have caching or anything like that set up, you typically have to have edge networks and all of these things working. So again, I'm kind of skimming over all the details around an implementation, but if you've ever used something like aws and you kind of have spun up a database, you know how complex it actually is to kind of build all this from scratch. Therefore you now have really great solutions out there like Amplify, like Superbase. They're abstracting away a lot of this. And Firebase, we just had a talk yesterday with Superbase, and they said a lot of the reason that people were using Firebase is because not because they actually liked the implementation, but it's so easy to spin up. Because it is complex to kind of get all of this stuff set up. These are all basically trying to fill in the gap that we do not have native state within the internet. Same technology and smart contracts enable you to programmatically have distributed global state that anyone can read and that is trustless. We can assume that if it is there, that it's actually the right data and anyone can access it from around the world, anyone can verify it. So with that being said, what are the types of characteristics that you might expect from these new types of applications? Now I don't think that decentralized apps are going to kind of take over the world. I think it's more like we now have a new way of building things. Again, we have things that have evolved over time, giving us more and more tools to accomplish the job that we're trying to accomplish. So I'm not saying you should use Web 3 or decentralized applications to build everything, but now you have a new type of application that you can build, and we can also improve on some of the old ones, but some of the old ways of doing things are perfectly fine and we shouldn't reach for these tools. But when you think about a decentralized application, decentralization is in the discussion because it often has to do with every part of what we're doing. We're decentralizing the web infrastructure, but we're also decentralizing ownership, we're decentralizing data, we're making everything more equitable and more distributed, and a lot of the things that come from that are these other characteristics. So one of them that is very important is this idea of distributed, trustless, and robust infrastructure that just doesn't go down. So if you have a single server running somewhere and it goes down, your application cannot be built. But if you have this application replicated across hundreds or thousands or tens of thousands of nodes, then if a node or if 25% of the network goes down, your application still runs. There is no single point of failure. That's why when you kind of think about us as software developers, to me this is what stands out the most. If I can build on a back end that really never goes down, I don't really have to worry about a lot of the things I kind of have to worry about today. Another thing that excites me as a developer is this idea of open and public back ends. Essentially you have open source code today. What if we had open source infrastructure that anyone can build upon? So I build an app, I deploy it to the network. Anyone that can write front end code can build an interface on top of that and we can all now compete and share infrastructure and use this infrastructure as building blocks to make better and better projects. This is already happening. This isn't kind of like theoretical. We're already seeing this start to take shape. Dozens of applications are being built on different decentralized exchanges, DeFi. You're starting to see, of course, NFTs have been in the news and stuff. I think it's kind of just the evolution of this idea and I think we're going to start seeing better and more real world use cases in the future and that's kind of a thing that I'm excited about. So what are the actual categories of applications? Well, DeFi and stable currencies are interesting because they allow anyone that can write code to build financial applications. Decentralized web infrastructure protocols. I work on a protocol called the Graph protocol that enables developers to build graphql APIs on top of blockchain data. I'm going to cover that in just a little bit, in just a moment. Play-to-earn gaming. So Axie Infinity is a web 3 game. They've done over $750 million in a single month in transactions. It's like Fortnite except for 100% of the money going to the platform, 95% of the money stays with the users. So if I put in $1,000 into the platform or $100, I can expect that when I decide to stop playing that game, I can get some of that money back. And again, it makes a lot more sense to me. Developments, autonomous organizations, digital art, tokenizations of physical assets like real estate, kind of opening the market for more people to participate, lowering the barrier to entry for people to buy into financial markets that they were priced out of in the past. And I think this idea of transferable content ownership, applying web 3ification to web 2 is really interesting. So right now on YouTube, if I upload a video, I have no control over that. I can lose my password or someone can hack my account and it can all go away. This happens so many times. Also if I want to build out my own front end on top of this, I have to use their APIs and if I use them wrong, I might be limited by that or they might not even provide the api that I want. What if all of our data was there for us to use forever? We don't have to ask anyone for it. And other people can also build front ends on top of this and interesting stuff like that. So I think we're going to see, and we've already started seeing the web 3ification of web 2 applications. So mirror.xyz is a blogging platform that allows users to do all types of financial types of stuff within their blog posts. So you've seen people doing fundraising, you've seen people do NFT launches within their blog posts. Recently someone did a blog post where they wanted to create a movie. They raised over $3 million directly within their blog post. They also give tokens to the writers, so if you're writing stuff, you actually make money. That's pretty interesting. Music, there's a program called Audius, or application called Audius that is a decentralized Spotify that allows not only the content creators to make more money, but you as a user, if you create a playlist that people really like, then you actually earn money for that. Instead of the platform like Spotify taking all this money, you're actually participating and you're getting paid for it, and I like that. So with that being said, we want to focus on building and we want to focus on the web infrastructure. Let's take a look at a few of the pieces for building a decentralized application. So the graph protocol is what I work with at Edge and Node. When you think of a typical database, it's optimized for indexing and querying. Blockchains are not optimized for querying. They're only optimized for indexing. They're not really even optimized for indexing. They're only optimized for transactions, for saving data. So blockchain data is saved in these blocks over the course of days, weeks, months, years, and it's really the focus is to kind of have the most transactions per second, the lowest latency and the least expensive transaction costs. For you to query this data, though, you typically can only read single pieces of information at a certain point in time. If you want to get all of this data and perform queries like relational and all this other stuff that you typically need for a performance application, you have to index that data in the database, then build out your own api endpoint, therefore breaking the important security principles of decentralization in the first place. The graph protocol is a decentralized network that allows developers to build graphql APIs that kind of do this indexing, but they replicate it across the entire network, and they also provide incentives for your data to be correct. So therefore, if you provide the wrong data, you get penalized in the form of a money penalization, so you kind of are losing money. So that's one piece of infrastructure. Ceramic network is interesting. It is a decentralized network, but it's for off-chain data, so you don't want to store everything probably on a blockchain. You might want to have information that is, of course, available to save and read for free. So if you want to save something and you don't want it written with the transaction cost, you might use something like the ceramic network. You have video streaming. Livepeer is a very, very successful decentralized live streaming platform. It's anywhere between 10X to 50X or more, less expensive than using something like aws. The reason that it is less expensive, it uses people's computers that are already running, doing other stuff to offload the processing for videos to a decentralized network of people that decide to buy in, and the people that are running these nodes get paid for their processing. But it's more efficient because there is more participation, and it's utilizing the compute, I would say, more efficiently than you might see in a centralized network. For file storage, like videos, images, and things like that, you have IPFS and you have Rweave. There's a handful of other ones as well. Rweave is extremely interesting to me because it allows you to store a file forever. So if you want to store an image and you want to read it ten years from now and you don't want to pay any type of hosting fees or something like that, then Rweave is a great place to do that. I'm experimenting right now writing a blogging platform that saves the text into Rweave and kind of stores the anchor of the ID to retrieve that text on a blockchain like Solana, therefore building a censorship-proof forever blog that I never have to pay hosting for. It just lives forever. For Git, Git itself is decentralized, but GitHub is not decentralized. So Radical is an attempt to build a decentralized version of Git, and it's already there and working. I would definitely check that out. So I think one of the most interesting differences between Web 2 applications and Web 3 applications is how we think of identity. Identity to us is actually our name and email address and phone number and all this shit that we probably shouldn't be handing over to all these people. We're handing it over hundreds and thousands of times within our lives. Why isn't there a better way to identify ourselves that is anonymous for most use cases? And sometimes we still want to give people our address, right? Because they might want to ship us something eCommerce. So let's have more control over that. Well, when you're working with Web 3, you typically are going to be identifying yourself via something called an address. And your identity is typically going to be derived from that address in a few different ways. And the way that you do that is via right now something called wallets. The wallets have a couple of different things that you can do with them. But essentially you can create a wallet either via getting a seed phrase from one of the wallet providers either directly through the wallet or kind of like doing it yourself using like a framework like Web 3.js or Ethers.js. But the idea with the wallet is this. You're given a seed phrase. You can then mathematically derive a private key from that seed phrase. You can then mathematically derive a public key from the private key. And then you can mathematically derive your address from that public key. Meaning that you can transfer your wallet anywhere in the world. All you need is that seed phrase. So anytime you want to log in anywhere in the world, you don't really have to kind of like transfer log in information. If you have that seed phrase, you can kind of like go in and get your information. And therefore you can kind of like sign transactions and parse those transactions using public key encryption. And it allows you to do really interesting and a lot lower, I would say, complexity for building authentication mechanisms. And one of the things I'm really excited about is this idea of like sign in with ethereum that kind of leverages this. And IDX is an identity protocol. So let's say you do want to attach some information to your address about yourself. You can do that in a decentralized way that you control all of that information. It's kind of like this idea of self-sovereign identity. You can decide what to put there. And the application typically doesn't ask you for that information. It'll ask for the pointer. And it will look in this place. And then it will decide, okay, I need this information based on what you've stored there. And then you can go back and change that however you would like. And then the last thing you would probably need to build an app is, of course, the blockchain. There are a handful of ones that I'm kind of interested in right now. I think the one that most people start with is the ethereum virtual machine. And ethereum virtual machine is the implementation of ethereum, but it can also be applied to a handful of other blockchains. It's kind of like the react of blockchain development. If you learn EVM, you can write for Polygon, Optimism, Arbitrum, ethereum, of course, but also Celo, Avalanche. There's like a dozen or so popular smart contract blockchains that you can build on once you learn EVM. So web3 could be thought of as the typical infrastructure that we're used to, but decentralized, and we now have smart contracts. So we still need all these things like compute identity, data, storage, web hosting, but we now have additional tools at our disposal that allow us to do more things. So let's build an app. So when we're starting with the most basic application we might want to build, we just want to think of these main things. We want to have our client framework, which could be something like react. We want to have our ethereum development environment. And there is a really great development environment we're going to look at in just a moment that kind of does everything that you need. We also need our ethereum client library, and we need our wallet. So the wallet is the identity. The ethereum client library could be thought of something like Axios or Fetch or graphql apollo. This sends api requests via RPC endpoints to our network that we're interacting with. So I think one of the most loved projects in the EVM ecosystem is Hard Hat. Hard Hat is just really, really, really great to get up and running. You can spin up an entire blockchain network locally in just a couple of seconds, and we're going to do that. So for the stack that I'm going to be using today, we're going to be using actually react.js, Hard Hat, Ethers, and MetaMask. I do like next.js actually for most of my applications, but I think for this demo it's more simple to solve with just react. So what we're going to do is build out an application. So can everyone see that pretty good? Okay, cool. All right. So I have an app called react Dapp. And I'm going to go ahead and open this up. Is this going to be a long demo or a short demo? How much more time do we have? You're already a bit over time, actually. Oh, really? Yeah, it's a 20-minute slot, man. Oh, it's a 20-minute slot. Yeah. Okay. I can knock this out in about five minutes. You think that's okay? I think that's all right. We'll just cut into the Q&A a little bit. Okay, yeah, we can cut the Q&A. That's fine. All right, all right. I'll just stand outside and answer questions. Okay. So sorry about that. Yeah, I didn't realize I thought it was a 30-minute slot. So we have a react application here. And let's see here. Okay. Whoops. That's not it. Okay. I'm sorry. I actually had... Okay. Here we go. So, anyway, we're in a react application. I have just run npx create react app. We have our scaffold there. What I want to do is I want to add hard hat, which is our ethereum environment. So I can run npx hard hat. This will walk us through a hard hat setup. So I'm going to say I want a basic sample project, the project root, and a get ignore. We'll go ahead and do that. And this will go ahead and create a contracts folder with our smart contracts, a hard hat configuration, which has our configuration for our project here. And I want to go ahead and set our paths for... We compile our smart contract into something called ABIs. You can think of ABI as something like a graphql query. It sends the information across the network for us to interact with our endpoint. So now that we have that, we can go ahead and create our ethereum node. So I'm going to go ahead and run npx hard hat node. And this is going to run an ethereum node, and it's going to give me 20 accounts, each one with 10,000 ETH. So I'm going to go ahead and copy this private key, and we're going to go into Chrome. And this private key is kind of the private key that I mentioned that can be your identity. You can either get it from a C phrase or you can kind of get it from your local environment, I guess, when it spins it up. So what I'm going to do is I'm going to import account, paste in the private key, and we now see that we have 10,000 ETH. I want to now deploy this contract to localhost. And if I go here, we should see that this is deployed locally. All right. So our application was deployed. Now let's go ahead and run this. So I'm going to say npm start, and I'm going to copy this address. And we're almost done. I'm just going to go ahead and go to app.js, and we're going to do our imports. We set our address here. And we're kind of just going to be interacting with a really basic smart contract, updating, I would say, a value that I'll show you in just a moment. So we have our contract address. This was kind of given to us when we deployed our scripts. So just by running it, we kind of are given all this here. Next I want to go ahead and create some initial state. So the contract that we're interacting with is pretty basic. We have a greeting, and this should look very familiar if you've done typescript before. We have a state variable called greeting. We have a constructor where we set the greeting, and we have a function that returns the greeting, and we have a function that updates the state by setting the greeting. So we can either return the greeting or set the greeting. So let's go ahead and open up app.js again. We're going to go ahead and create a function for connecting our wallets. We're going to have a function for fetching the greeting, and I'm going to just walk through one of these because we're almost done on time. And I have a function for setting the greeting. So just to kind of give you a quick overview of what it looks like to interact with the contract, we import the ethers.providers api, I guess you could say, from ethers.js, and we're able to access this variable called window.ethereum. If you have a wallet installed in your browser, it injects this global variable called window.ethereum that you can access. We then get a reference to our smart contract deployment by using the address of our contract deployment, the ABI that was created when we compiled our smart contract in the provider we just created, and now we can call functions within our contract. So here we're calling contract.whatever function we want to call. And then finally we can go ahead and build out our UI, and whoops, I'm just going to do it here. And we can go ahead and test this out. So our UI isn't nice, but it's just, you know, it's just going to work. Something basic. What I can now do is click fetch greeting, and we should go ahead and be able to get the greeting from the chain. Hello, hard hat, and if I go to here, you can see that this contract call was made, and then I can set the greeting to hello, react advanced, and this should, yeah, this should be interesting, because we should be able to now interact with our wallet. So we can choose the address we want to interact with. We can now pay for this transaction, because we're writing something to the chain. We can confirm that. And now if I refresh, the value should be the updated value. And we've built a really basic DAP that interacts with a smart contract, and we did it in, like, what, three or four minutes? Or two minutes? Maybe one minute. So that's it. Thank you for checking out my talk. If you want to get further, scaffold-eth is a great place to check out. Anchor for Solana. Full stack guide to full stack ethereum development. I wrote that. Check that out. And that's it. Thank you. Thank you so much. Thank you.