Client side Ethereum

# Frontend

## Clientside Ethereum

So, when I say frontend, let me start by saying I'm not going to dive into React, Vue, Svelte, or any other frontend framework. I'm not here to tell you how to move your pixels around the screen, how to manage the state of your application, whether hooks are a good or bad design choice, how much Javascript you should be shipping to the browser, etc.  Instead, let's think about how an Ethereum app (or dapp as the cool kids like to call them) works.  In every web app that interacts with the blockchain, the "backend" for your app will in some part be the blockchain.  You might still have a server that renders your web app before shipping it to the browser but the blockchain is really your backend at the end of the day.  How do you interact with the blockchain from a web app if you aren't running a server?  Good question.

### Fundamental concepts
Conceptually, all blockchain nerds get the idea that there are a bunch of "full nodes" running code that lets them store a local copy of the blockchain and that these full nodes interact with other full nodes in a peer to peer manner to build consensus and track the course of the chain over time.  And, in order for you the end user to move your ether or tokens around or interact with blockchain apps, you have to submit a transaction to one of these full nodes who will then broadcast it around the network and it will get included in a block at some point.  

So, if you're a frontend developer wanting to build a blockchain app, your app has to allow users to sign transactions and then get them included in a block.  How do you do that?  Does every blockchain app run their own node in order to make sure they can broadcast their transactions?  Some do, depending on their needs, but most (especially smaller apps) rely on the user's wallet to actually broadcast the transaction. So in other words, what the web app does is create some transaction for a user and then send that transaction to the user's wallet (usually in a browser extension like Metamask or some other more exotic setups).  The companies behind most of the wallets rely on other service providers who are running full nodes (Infura and Alchemy are two of the biggest) to broadcast transactions to the chain.

So in other words, most blockchain app developers don't actually bring their own backend (aside from having someone host the code that delivers their client side code).  Their backend is the blockchain, with a user's wallet sitting in between.

### Ethers-js -- Nuts and Bolts
For the frontend developer, the main toolset you need is a way to construct transactions and then connect to your user's wallet to send that transaction to the wallet so it can be broadcasted to the chain.  For this, you can construct raw bytecode yourself to call functions on a smart contract, put that into the appropriate hexadecimal format, connect to that wallet, construct the JSON required by the full node, and then check for the existence of a wallet, call the correct API for that wallet to send an unsigned transaction to it and give it the appropriate instructions to broadcast that transaction to the chain with some suggested gas price.  You could do all of that yourself, or you could use the `ethers` SDK to make your life a lot easier.  Think of `ethers` as a Swiss army knife of web3/Ethereum frontend development.  Ethers provides lots of tools but here are some of the keys you will use as a frontend developer.

### Providers
The `provider` is the service or set of services your app will need connect to in order to get your app's transactions to the blockchain.  Think of a provider as an API that your app calls (directly from the client-side app) to send your unsigned transactions to a wallet for signing and then onto the chain.  There's a standard API that all providers expose (and often extend or tweak) and Ethers wraps that up cleanly into a `provider` object that you instantiate in your app and then call when needed to either read data from the chain or else write data to the chain (via a transaction). 

### Contracts
The `contract` object is a nice wrapper object that `ethers` provides to define the functions exposed by a smart contract that your app interacts with.  Instead of having to know how to construct Ethereum bytecode yourself, `ethers` gives you a Javascript class that you can call with a set of standard functions for estimating a transaction's cost, reading contract state variables from the chain, or constructing and broadcasting transactions to the chain.

### Utilities
The `util` object exposed by `ethers` is a handy set of tools for converting numbers into hexadecimal or bytes, interacting with the numbers of various orders of magnitude that Ethereum uses (since at root, Ethereum does math using integers bewteen 0 and 2^256), and many other, various cryptographic functions potentially useful in blockchain work, decoding/encoding numbers to different bases often used in web3, etc, so forth and so on.

Collect this post to permanently own it.
Subscribe to Web3 Ninjitsu and never miss a post.
  • Loading comments...