A Frontend Developer’s Guide to Web3

Welcome, everyone, to my talk, a front-end developer's guide to Web 3. Really excited to be here at React Summit, talking a little bit about Web 3 and giving you an introduction to it. Here's a high-level agenda of what we're going to be going through today.

We're going to be talking about what Smart Contracts are, going over how to develop them, we're going to talk about how to connect to the blockchain, talk about things like wallets and RPC endpoints. We'll go over that in a bit. Don't worry. We'll look at how to actually fetch data from the blockchain, and some really dope tools that you can use to build with, into the Web3 rabbit hole as I have.

A little bit about me. My name is Rahat. I'm a developer advocate at Polygon. Previously, I've been a front-end developer as well as a freelance Solidity engineer. Overall, I'm an indie hacker, a Web3 enthusiast, and these are places you can find me, Twitter, LinkedIn, GitHub, if you ever want to look at some code examples of some of the things that we talk about during this talk.

Polygon, which is the company that I work for, we're specifically going to be talking about one of our products, which is a proof-of-stake blockchain. One of our popular offers, this is pretty much our most popular offering. It is a carbon-negative blockchain. We're striving to be completely climate positive, uses about 99% less energy than Ethereum or other blockchains. It's a great way to start diving into the Web3 space without having to worry as much about energy wasting and usage that comes up with a lot of the other blockchains that are out there.

But going to the actual main crux of our talk, smart contracts. Smart contracts are essentially the code of the blockchain. It's just a file, contains some code, some instructions for what your app or your DApp, which is a decentralized application, needs to do when it's deployed onto the blockchain. How do we write smart contracts? What do we need to know about them? The languages that smart contracts are generally written in include Solidity, Rust, Viper, or Go. I'm going to be talking mainly about EVM chains during this talk. EVM means Ethereum Virtual Machine, meaning everything that we talk about, all of the code that we do review and go over, are all compatible with the Ethereum blockchain. Our blockchain, Polygon, is also compatible with Ethereum, so anything you learn on that side of things is one-to-one compatible on Polygon. Although Solidity is generally the most popular use language, another popular one is Viper. So, definitely if you to smart contract development, those are some good languages to know. Now, let's say you've written your smart contract, you've written some Solidity code, you want to actually get that out onto the blockchain. Deployment takes a few different steps. First, you need bytecode. Bytecode is essentially machine-readable code that is compiled from Solidity.

Solidity is a very high-level language, meaning it has the code, but it needs to be really compiled down to something that the Ethereum virtual machine can read. And that's what this bytecode is.

Next thing you need to know is what gas is. Gas, not like what you would use at the pumps, but gas fees associated to blockchain developments include essentially a fee that you need to pay in order to transact with the blockchain. This fee is comprised of like a base fee that may get burned, so a certain amount of coins or tokens on that blockchain might get burned during this transaction. And then a certain amount of it is given to what are called miners or validators. And these are folks who have nodes or computers that essentially keep track of the blockchain, have copies of it, and are validating transactions to be added to the overall blockchain.

Next, you need a deployment script. A deployment script can be taken from environments like HardHat and Truffle, both of which are tools for creating like environments for deploying, testing, and essentially creating your smart contracts on your local machine. Finally, you need an Ethereum node. Ethereum nodes is just basically a computer that has a copy of the Ethereum blockchain on it. Think of the Ethereum blockchain as this gigantic database. The node essentially houses a lot of all the information that is on that blockchain. You have everything on what's called a distributed network. There's nodes and computers all over the world keeping track of validating transactions and they together form the consensus of what the blockchain data is.

Polygon works very similarly in this case. We have several nodes all across the world and rather than using folks like miners who mine these transactions, we have validators who validate it. Next, there are services like Alchemy and Infera which can help you with accessing an Ethereum node. Not everyone can run their own Ethereum node or Polygon node on their own computers. These services are essentially providing you with endpoints or RPC or what's called a remote procedure call endpoints that allow you to interact with Ethereum and that allow you to interact with Polygon as well. Finally, let's talk about interactions. Interactions usually happen with a wallet. Wallets are usually inside of your browser. I'm going to show you right now a what's called a MetaMask wallet, which is an in-browser wallet. I have a little bit of Ethan here, but I can switch between different networks. I'm going to switch to the Polygon testnet just to showcase this is the Polygon network. You can have access to different blockchains via this wallet. The wallets all interact using an RPC endpoint, so they have their own built-in endpoints from services like Inferior and Alchemy. But for now, let's go ahead and break down what some of these interactions are. I showed you a little bit about wallets, which is that MetaMask wallet I popped up here.

What wallets really do is ask for user consent for actually accessing their wallet and connecting to the blockchain. Many of the different interactions that you need to do require sometimes some type of transaction fee. Usually this is some type of mutation that needs to be done on the blockchain, or sometimes there's a signature required from you to prove your identity, to prove that you're the one using your wallet. This is all done through a wallet like MetaMask or through hardware wallets like the one you see here from Ledger. These are great for when users need to conduct transactions like minting or buying an NFT, transferring tokens, anything that requires interaction between you and the blockchain or you and some other folks who are using Web3 applications.

The other type of interaction is just a read only type of interaction, so RPC endpoints, like we mentioned before. These are endpoints given to us by a Node provider. These are great for dApps that only have read transactions, like a block explorer. Block explorers will give you essentially a UI that acts as a full ledger for looking through transactions, for looking through the history of those transactions, for looking through any failed transactions that you might have. So when you're trying to figure out what's going on, what's debugging certain calls in your application, you can look at block explorers to see, so what happened during this call? Why was it rejected? Why didn't it go through? These are great for debugging.

Let's look at some code and take a look at how do we actually interact with the blockchain wallet edition. On my screen I have a JavaScript function called handle wallet connect. This would generally be attached to something like a button. So, this is an async function, and what I'm doing here is taking the Ethereum object out of the window. Now, you might be like, whoa, Rahat, what do you mean Ethereum object in the window, right? So, the reason I'm able to pull out an Ethereum object from the window is because I'm considering that this person might have a MetaMask wallet like I have set up right here. As long as you have a browser injected wallet like that, that wallet will also inject the Ethereum object into your window. And then from there, just a little bit of boilerplate of accessing the account associated to that wallet and then accessing the address and logging that out. If the Ethereum object doesn't exist, we'll just alert that, hey, there's no wallet detected. The person should have, should go and install MetaMask or something like that, and you can provide a better alert than I did. So, here's a quick demo on how that works. So, on this page, I have this connect wallet button. I hit it, and once that happens, my MetaMask pops up, I hit sign in, and it displays my address on the page. This is essentially half of what you would use for something like sign in with Ethereum, which I'll cover in just a little bit as well.

Now I'm going to talk about another common connect wallet pattern. This is done quite a bit through a lot of decentralized applications where we take that handle wallet connect function, I didn't bother rewriting it here, and put it inside of a use effect and call it right away, specifically on mounting of the actual application. Please do not do this if you ever dive into the Web3 space. What this essentially does is as soon as I land on the website, the website will automatically request that I connect my wallet. This is sort of like the same kind of situation of like you're going to a website, music starts playing, or a video automatically starts playing. Nobody wants to actually have that happen right away. This is a bad security practice and is something that it just leads to bad UX overall in your application, because it removes the ability for the user to give consent.

One of the main things we talked about with wallets is that this is the gateway for a user to consent to using the blockchain to doing certain transactions. This removes that ability. And some folks might say, you can still cancel the transaction, but no, you've got to stop, because if your wallet immediately pops up, you don't have that opportunity to actually go through the application and understand what's going on.

So I mentioned this a little bit, just a couple of slides ago, going beyond connect wallet and using something called sign in with Ethereum. One of my favorite things that have come up out of the Web 3 space is this true single sign on experience, where you can take a wallet, connect it, validate your address, as we looked at before, and then from there do something like connecting to a server as you would normally do for authentication, for actually pulling someone in, creating a user profile for them on your Dapp or application. And the cool thing here is that user profile can travel with them anywhere. They don't need to create a new email or password every single time they go to a new application. They don't need to trust their credentials to a service like sign in with Google or sign in with Facebook. Everything is actually specifically owned by them. That user profile is owned by them through this wallet. And the way that wallet works is that the wallet gives you access through a key value pair, a public address and a private address. The public address is the one we displayed on the page. And then there's a private address that only they have access to that actually allows them access to the blockchain and is what allows them to approve transactions, view their holdings and just access the overall web three space.

So we talked about the wallet side of things, of doing interactions, of like actual user interactions, but how do we interact with the blockchain, RPC and Point Edition? In this case, we may only want to do read only transactions, maybe we want to create our own block Explorer, maybe we want to just display some data in the form of graphs, dashboards, whatever it is. On here, I have this provider. And this provider is something given to us from the ethers package, which is a popular JavaScript package you can use in your front ends. And all you really have to do is just use this method, and enter an RPC endpoint. These RPC endpoints are basically just like a URL, an HTTP endpoint, given to you like the services I mentioned earlier from alchemy and Azure. And this is like a blob of information that you can actually get from the RPC endpoint. So, here, what I'm doing is I'm getting the information about the latest block on the blockchain, and what does that mean? What is the latest block? So, blockchain data is broken up into these blocks, they all have some type of number associated to them, a timestamp, different hashed values, and this is what houses all of the data on this block. So, on this specific block, there's several transactions. There's only one displaying here, this is a timestamp, and just some information about the miner who actually validated this, as well as just additional data like the gas that was used. And this is the information you can use to build out some of those dashboards, some of that information. I'm going to give you a quick demo of something that I built using that blob of data. This is just like a list of like the last 10 blocks on the polygon blockchain, including their block number, their timestamp, and the number of transactions on each of those blocks. You can dive a little bit deeper into that JSON data that's returned from some of these calls, but this is just like a very basic implementation of like what a block explorer might start off as. So cool. But how do we actually fetch data from smart contracts, right? Sure, maybe there's like someone wrote some like developer, smart contract developer wrote a contract for us and that houses some information. How do we access that information? We need a map. So Solidity code, like I mentioned before, gets compiled down to bytecode.

We need instructions on how to actually traverse that bytecode. So what we need is an ABI, or an Application Binary Interface. This is usually exported out by a Solidity developer, passed on to like a frontend developer. And this is just a JSON object with instructions on like the different types of functions that are available on a smart contract, what input some of those functions need and the types of outputs that they give to you. This is just going to allow JavaScript to use certain libraries to traverse through the blockchain and get the proper information that it needs.

So rather than doing an HTTP request, it's using this ABI, along with a function given to us from a package like ethers, to actually interact with the blockchain itself. So how does this work? First you would import dependencies. This is done, assuming you're looking at a react application. So you're going to import ethers from the ethers library and an ABI that some smart contract developer may have given you. This is an example from a contract that I wrote, where it showcases a little Pokemon battle between two Pokemon.

The next thing is you want the address of the deployed contract. So every single deployed contract, similar to your wallet has its own address. So we need to get the address to see where on the blockchain that contract lives. We supply the ABI, the address of the contract, as well as the Ethereum object into this contract method given to us from ethers. Once we supply all that, we then get access to the actual functions listed out inside of the ABI file. One of those functions here is this attack functionality, where our Pokémon is going to attack each other, and then certain amounts of like HP, or hit points, are going to be taken away. So let's take a look at that in action.

So what's going on here is I decided, okay, I need to attack this Pokémon. I hit use flamethrower. My MetaMask is going to pop up. I'm going to pay a small amount of gas to make sure this transaction goes through on the blockchain, and once it's completed, all of the hit points of the two Pokémon will go down, and all of this is tracked on the blockchain itself.

The main things to really understand here, front-end development in web 3 remains the same. The UI is still built using all the same practices. You don't, as a front-end developer, you don't need to know the deep intricacies of how to build your own smart contracts. You just need to know how to interact with them like we talked about. You go from a shift in mindset from doing HTTP requests to using ABI code and libraries to call the smart contract, and the other main thing to remember is that mutations cost money. Read transactions are free. Mutations will always cost money. Some web 3 front-end development tools that you can definitely dive into and learn more about are the ethers and web 3 library as well as the WAGMI library. WAGMI library provides a lot of react hooks for easily hooking into and transacting with the blockchain.

Web3UI is an awesome library that gives you a bunch of react components that you can use as well and different block explorers like PolygonScan if you're interacting with a smart contract on the Polygon network or Etherscan if you're interacting with a smart contract on the Ethereum network. These are all tools that I'm going to be touching on as well during my workshop here at React Summit. So if you want to learn more about that, we'll be going into greater detail and overall, if you feel like you want to learn more, you want to check out how to build on the blockchain, how to build on Polygon.