A Frontend Developer’s Guide to Web3


There is a lot of hype and interest around diving into the Web3 space, and it can be hard to manage the information overload and the emphasis on learning new languages to work on smart contracts. Many developers in the frontend space ask, “How much of this new information do I need to transition into web3?” The truth is as a React developer, the skills I know are essential in web3. Let’s add some context around how to leverage those existing skills to succeed in this new space.

In this talk, we’re going to explore how to build the correct context and the technologies to understand to help you dive into web3 as a front-end developer. We’ll go over popular packages like Ethers, which can be used in React applications to interact with wallets and existing smart contracts. We will also explore how you can leverage your Javascript skills to build full-stack dApps using managed services like Moralis and Thirdweb.

Let’s demystify some of the concepts in web3 and leverage our existing skills to start building.



Welcome everyone to my talk, a front-end developer's guide to Web3. Really excited to be here at React Summit, talking a little bit about Web3 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 and dive into the Web3 rabbit hole, as I have. So a little bit about me. My name is Rahat. I'm a developer advocate at a company called Polygon. Previously I've been a front-end developer as well as a freelance Solidity engineer. Overall, I'm like an indie hacker, Web3 enthusiast. And these are just some 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. And 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. And 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 DAP, 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, kind of like 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 ever wanted to go into 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. Development 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. The 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 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. 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 environments for deploying, testing, and essentially creating your smart contracts on your local machine. Finally you need an Ethereum node. So 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, and the node essentially houses a lot of all of the information that is on that blockchain, and you have everything on what's called a distributed network. So there's nodes and computers all over the world keeping track, 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 actually 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, that allow you to interact with Polygon as well. Finally let's talk about interactions. So interactions usually happen with a wallet. Wallets are usually inside of your browser. So I'm going to show you right now 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 endpoint from services like Infera and Alchemy. But for now let's go ahead and break down what some of these interactions are. So I showed you a little bit about wallets, which is that MetaMask wallet I popped up here. And 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 like 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, okay, so what happened during this call? Why was it rejected? Why didn't it go through? These are great for debugging. So 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? 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 couple of little bit of boilerplate of like 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 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 like unmounting 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 you 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 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 ConnectWallet and using something called Sign-in with Ethereum. One of my favorite things that have come up sort of like out of the Web3 space is this sort of like true single sign-on experience where you can take a wallet, connect it, validate your address as we kind of looked at before. And then from there, do something like connecting to a server as you would normally do for like authentication for actually pulling someone in, creating a user profile for them on your DAP or application. And the cool thing here is like 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 like 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 Web3 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 endpoint 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 like 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 Infura. 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 like the miner who actually validated this as well as just like additional data like the gas that was used. And this is sort of like 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 front end 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 you, 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 in like assuming you're looking at a React application. So you're going to import like 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 like a little Pokemon battle between two Pokemon. The next thing is that 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 it 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 Pokemon 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 Pokemon. 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 Pokemon will go down and all of this is tracked on the blockchain itself. So the main things to really understand here, front end development in web3 remains the same. The UI is still built using all of the same practices. You don't, as a front end developer, you don't need to know the deep sort of like 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 web3 front end development tools that you can definitely dive into and learn more about are the ethers and web3 library, as well as the Wagme library. Wagme library provides a lot of react hooks for easily hooking into and transacting with the blockchain. Web3 UI is an awesome library that gives you a bunch of react components that you can use as well. And different block explorers like polygon scan, if you're interacting with a smart contract on the polygon network or ether scan, 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 there. 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. We do have a lot of resources on academy.polygon technology. There's a lot of like gamified approaches there of like learning and building your own dApps. I also wanted to quickly call out polygon village. If you decide to like go in and learn about web3, learn about how to develop in it and start developing your own projects, we do give grants, which are no strings attached grants for actually building out your projects. And eventually, if you wanted to go into the web3 ecosystem, we do have an ecosystem job board for that as well. So this is not just for polygon jobs, but for overall folks in the polygon ecosystem. So just to wrap up, I'm Rahat, again, developer advocate at polygon. These are just a few places you can find me. Really awesome to have you all dive into a little bit of web3 with me. And really excited to see you all possibly in my workshop as well. Thank you.
22 min
21 Jun, 2022

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Workshops on related topic