Building Dapps with React

Thank you for that amazing introduction. I'm really excited to be here in person in London. 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 three 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 are 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 terms that I'm gonna be speaking about in just a moment, you've probably heard a lot of hype recently around Web3, 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 10 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 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 three, when 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, the 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 think, 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 gonna 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 gonna, 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 were 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 wanna 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's 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 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. And 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. 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 have spun up a database, you know how complex it actually is to 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 not because they actually liked the implementation, but it's so easy to spin up. Because it is complex to get all this stuff set up. These are all basically trying to fill in the gap that we do not have native state within the internet. Blockchain 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, and 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?

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 three 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 decentralized 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 can't be built. But if you have this application replicated across hundreds or thousands or tens of thousands of nodes, that 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 could build upon? So I build an app, I deploy it to the network. Anyone that can write front-end code can now build an interface on top of that and we can all now compete and we can kind of share infrastructure and we can use this infrastructure as building blocks to kind of make better and better projects. And this is already happening. This isn't kind of 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 gonna 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 gonna cover that in just a little bit, in just a moment. Play-to-earn gaming. So, Axie Infinity is a Web3 game. They've done over $750 million in a single month in transactions.

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.

Decentralized 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 Web3ification to Web2 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 wanna 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 gonna see, and we've already started seeing the Web3ification of Web2 applications.

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 kind of 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 an 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, whatever. 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 performant 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 wanna store everything, probably, on a blockchain. You might wanna have information that is, of course, available to save and read for free. So if you wanna save something and you don't want it written with a 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's 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 RWEV. There's a handful of other ones as well. RWEV is extremely interesting to me because it allows you to store a file forever. So if you wanna store an image and you wanna read it 10 years from now and you don't wanna pay any type of hosting fees or something like that, then RWEV is a great place to do that. I'm experimenting right now writing a blogging platform that saves the text into RWEV 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 actually is already there and working. I would definitely check that out.

So, I think the most, 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, you know, name and email address and phone number and all this shit that we don't really, 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 wanna give people our address, right? Because they might wanna ship us something eCommerce. So, let's have more control over that.

Well, when you're working with web-3, you typically are gonna be identifying yourself via something called an address. And your identity is typically gonna be derived from that address in a few different ways. And the way that you do that is via, right now, something called like 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 a framework like web3.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 wanna log in anywhere in the world, you don't really have to kind of like transfer login 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 wanna attest 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 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 a Polygon, Optimism, Arbitrum, you know, Ethereum, of course, but also Cello, 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 a dapp. So when we're starting with the most basic application we might wanna build, we just wanna think of these main things. We wanna have our client framework, which could be something like React, we wanna have our Ethereum development environments, and there is a really great development environment that we're gonna 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 as something like Axios or Fetch or GraphQL Apollo. This sends API requests via our PC 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 gonna do that. So for the stack that I'm gonna be using today, we're gonna 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 gonna do is build out an application. So can everyone see that pretty good? Okay, cool. All right, so I have a app called ReactDApp. And I'm gonna go ahead and open this up. Sorry, is this gonna be a long demo or is it a short demo? How much more time do we have? Five minutes? 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, yeah, yeah. I can knock this out in about five minutes. You think that's okay? Um, I think that's all right. We'll just cut in the Q&A a little bit. Okay, we can cut the Q&A, that's fine. I'll just stand outside and answer questions. Okay, so, sorry about that. Yeah, I didn't realize that. 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 gonna say I want a basic sample project, the project root, and a git 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 path, for we compile our smart contract into something called ABIs. You could think of ABIs 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 gonna go ahead and run npx Hard Hat node. And this is gonna run an Ethereum node, and it's gonna give me 20 accounts, each one with 10,000 ETH. So, I'm gonna go ahead and copy this private key, and we're gonna 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 seed phrase, or you can kind of get it from your local environment, I guess, when it spins it up. So, what I'm gonna do is I'm gonna import account, paste in the private key, and we now see that we have 10,000 ETH. I wanna now deploy this contract to local host, and if I go here, we should see that this is deployed locally. All right, so our application is deployed. Now, let's go ahead and run this. I'm gonna say npm start, and I'm gonna copy this address, and we're almost done. I'm just gonna go ahead and go to app.js, and we're gonna do our imports. We set our address here, and we're kinda just gonna be interacting with a really basic smart contract updating, I would say, a value that I'll show you in just a moment. We have our contract address. This was given to us when we deployed our scripts. So just by running it, we're given all of 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 gonna go ahead and create a function for connecting our wallets. We're gonna have a function for fetching the greeting. And I'm gonna just walk through one of these because we're almost done on time, we're over 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, because 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 API 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 dot, whatever function we wanna call. And then finally we can go ahead and build out our UI. And whoops, just gonna 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 gonna 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 app that interacts with a smart contract, and we did it in like, what, three or four minutes or two minutes, maybe one minute.