Connecting a frontend

What a dApp really is

A dApp (decentralised application) is, in most cases, an ordinary website — HTML, CSS, JavaScript — whose *backend logic* lives in a smart contract on a public blockchain instead of on a company's servers. The frontend still runs in the user's browser and can be hosted anywhere; what's different is where it sends its important operations. Instead of calling your own API to, say, record a vote, the frontend asks the user's wallet to send a transaction to a contract, and the contract records the vote on-chain. The user's data and the core logic aren't in your control, which is the whole point: the app keeps working even if your website disappears, because the contract is still there.

The library, the provider, and the signer

Your JavaScript can't talk to the blockchain directly; it uses a library — ethers.js or viem are the popular ones — that speaks the chain's protocol. Two objects from that library matter most. A provider is a read-only connection to the chain: with it you can query balances, read contract state, and fetch past events, all for free. A signer represents an account that can *authorise* transactions — it's backed by the user's wallet, and using it is what triggers the wallet to pop up and ask the user to confirm. The rule of thumb: provider to read, signer to write. You get the signer from the browser wallet the user has connected, so your site can request transactions without ever seeing the private key.

import { ethers } from "ethers";

// The injected wallet (e.g. MetaMask) exposes window.ethereum.
const provider = new ethers.BrowserProvider(window.ethereum);

// Ask the user to connect, then get a signer for their account.
await provider.send("eth_requestAccounts", []);
const signer = await provider.getSigner();

// A contract object needs the address and the ABI (its function list).
const counter = new ethers.Contract(address, abi, signer);

Reading is free; writing is a transaction

This is the distinction that shapes every dApp. Reading the chain — calling a view function, checking a balance — costs nothing, happens instantly, and needs no wallet confirmation, because you're only querying data every node already has. Writing — calling a function that changes state — is a transaction: it costs gas, must be signed by the user's wallet, and takes time to be mined and confirmed. So a read returns a value immediately, while a write returns a transaction you then wait on. Designing a dApp is largely about knowing which operations are reads (show them freely, update the UI often) and which are writes (prompt the wallet, show a pending state, wait for confirmation).

// READ: free, instant, no wallet prompt (a view function)
const current = await counter.count();
console.log("count is", current);

// WRITE: a transaction -> wallet prompts, costs gas, must be mined
const tx = await counter.increment();   // user confirms in the wallet
await tx.wait();                        // wait for it to be confirmed
console.log("now", await counter.count());

The ABI (Application Binary Interface) mentioned in the code is the contract's public interface described as data — the list of its functions and events — which the library needs to encode your calls correctly. Your framework produces the ABI when it compiles the contract, so you pass it straight through to the frontend.

The wallet keeps keys off your site

The security model here is elegant and worth appreciating. Your site never asks for, sees, or stores the user's private key. Instead, when your code calls a state-changing function through a signer, the request goes to the user's wallet, which shows the user exactly what they're about to sign — the contract, the function, the value — and only signs and broadcasts if they approve. Your frontend just prepares the transaction and reacts to the result. This means a malicious or buggy dApp can *ask* for a transaction but can't move funds without the user's explicit, informed consent, and a compromised website still can't steal keys it never had.

The full click-to-chain flow

Now the whole path connects. The user clicks 'Connect wallet'; your site requests accounts and gets a signer. The user clicks a button that changes state; your code calls the contract function through the signer, which prompts the wallet; the user confirms; the wallet signs and broadcasts the transaction; nodes verify it and a validator includes it in a block; your code was awaiting the transaction and, once it's confirmed, reads the new state back through the provider and updates the UI. Every layer from the earlier lessons — keys, transactions, gas, nodes, consensus — is in that one interaction, now with a friendly button in front of it.

• Connect: request accounts → get a signer from the wallet.
• Read: query state through the provider, free and instant.
• Write: call a function via the signer → the wallet prompts the user.
• Confirm: the user approves; the wallet signs and broadcasts.
• Update: await the transaction, then re-read state and refresh the UI.

That is a complete dApp interaction. The full-stack dApp project in this track builds exactly this — a contract plus a frontend that connects a wallet, reads state, and sends transactions. Next, though, the most important lesson for anyone whose contract will hold value: security.