A traditional web application, or a Web2 app, has a familiar structure. Your browser (the frontend) talks to a company's server (the backend), which then talks to a database. This is the classic client-server model. All the logic, data, and control live on that central server.

Decentralised applications, or dApps, break this model. They replace the centralised backend and database with a peer-to-peer network: the blockchain. Instead of trusting a single company to manage the logic and store your data, you trust a network of computers running open-source code.

The frontend of a dApp looks and feels just like any other website. The real change happens under the bonnet, in how that frontend communicates with the backend logic and data store.

A dApp's architecture can be broken down into three main layers that work together.

1. Frontend: This is what the user sees and interacts with. It's built with the same technologies as any modern website (like React or Vue.js). Its job is to present data and provide a way for users to create and sign transactions.

2. Web3 Middleware: This is the bridge between your frontend and the blockchain. Libraries like ethers.js or web3.js provide the tools to format requests and read data from the blockchain, and to ask a user to approve and send transactions.

3. Smart Contracts & Blockchain: This is the backend. Smart contracts contain the application's logic—the rules of the game. The blockchain itself is the database, storing the application's state in a permanent, verifiable way.

A dApp's frontend doesn't talk directly to a server you control. Instead, it sends requests to a blockchain 'node' using a standard called JSON-RPC. Think of a node as a gateway to the entire peer-to-peer network. Anyone can run a node, but for convenience, most dApps use services like Infura or Alchemy that provide reliable node access.

This communication happens through two key concepts: Providers and Signers.

A Provider is like having a library card. You can go to the library (the blockchain) and read any book (data) you want. You can check an account's balance, read the state of a smart contract, or look up past transactions. But you can't change anything.

A Signer is like having a pen with your own unique signature. To change something in the library—say, to check out a book or add a note to a public ledger—you need to sign for it. In a dApp, a Signer (usually managed through a wallet like MetaMask) lets you approve transactions that change the state of the blockchain. This could be sending tokens, voting on a proposal, or interacting with a smart contract. Every state-changing action requires a signature.

A traditional database allows you to create, read, update, and delete data (CRUD operations). A blockchain is different. It's a transactional state machine. You can't just 'update' a value. Instead, you submit a transaction that transitions the system from one state to the next.

Imagine a simple smart contract that tracks a single number, starting at 0. The initial state is 0. If you send a transaction that calls an increment() function, the smart contract executes, and the new state becomes 1. This transition from state 0 to state 1 is permanently recorded on the blockchain. You can't go back and edit the fact that it was once 0. You can only create a new transaction to change it again, for example, by calling a decrement() function to move it back to 0. Every change is an auditable, unchangeable event in the chain's history.

This model provides immense security and transparency but comes with trade-offs. The biggest is latency. In a Web2 app, a database write is nearly instant. In a dApp, a transaction must be broadcast to the network, included in a block by a miner or validator, and then confirmed by the network. This can take anywhere from a few seconds to several minutes.

So why accept this delay? For the benefits of decentralisation:

• Censorship Resistance: No single entity can stop your transaction or take down the application. As long as the network is running, the dApp is available.
• Data Ownership: Users control their own data and assets through their private keys. There's no central server that can freeze your account or misuse your information.
• Transparency: All logic (smart contracts) and transaction history are public and verifiable by anyone.

Building a dApp means carefully balancing these factors. You must decide which actions need the trustless security of the blockchain and which can be handled off-chain for a faster user experience.

Understanding dApp architecture is the first step toward building and evaluating Web3 applications. It's a shift from the centralised models we're used to, but it opens up a new world of possibilities for user-owned and resilient applications.