Anatomy of a DApp

This article is my contribution to taking some of the magic and mystery out of Web3 DApps.

Once you understand how they work from a high level, the topic becomes a lot more approachable and less scary.

I hope this will help you wrap your head around Web3 faster.

Note: the explanations below are very Ethereum-ecosystem-focused. They apply to compatible blockchain environments like Polygon though! Probably others as well, but I haven’t got enough experience to generalize with confidence.

Disclaimer: I’m pretty new to this topic, and might be mixing up words and concepts without realizing it! Consider this a work in progress :) I think it’s helpful already, but some parts might be technically wrong. If you spot a mistake - feel free to ping me @vsupalov

DApp?

DApp stands for decentralized application. The main idea is, that the data and computations happen in a decentralized network, instead of compute resources owned and controlled by a single company. The data lives on the blockchain, and the code which powers a DApp is executed on the blockchain as well - via Smart Contracts.

However, as you’ll see, the way in which DApps tend to be currently structured, is a bit more interesting than “talks to the blockchain” and not necessarily completely decentralized, when it comes to practical implementation details.

Let’s take a look at how DApps tend to be structured. We’ll start with the part where users interact with your DApp via their browser.

Front-End Stays Front-End

The part where users interact with your smart contract(s), is built in a way which is pretty much the same as conventional dynamic web applications.

They are built with a mix of HTML, JavaScript and CSS.

You can use React, Vue or any other tool of your choice to create a dynamic web application. Then, you use something like web3.js or ethers.js to “talk” to the Blockckain.

It’s hosted in pretty-much the same way. Uploaded to a place, which can be reached with a browser, which loads the HTML, JavaScript and CSS resources, just with any other conventional website. It’s common that a normal DNS address points to the DApp.

I have to emphasize this: on the front-end side, you are pretty much only coding a dynamic web application. If you are familiar with something like React, you have almost all the skills you need to dive into a Web3 project and contribute real value!

How Does the Front-End “Talk” to the Blockchain?

Your code talks to something like Metamask. Or other wallet solutions, which integrate into the browser.

In the case of Metamask, it injects a new object into your browser JS environment, which web3.js or ethers.js interacts with. They can request the wallet to “connect” to your site, and afterwards they can query blockchain information through the wallet extension, or request to submit transactions through the wallet.

So, if the code wants to fire off a transaction (which costs money), your wallet prompts you to accept or reject that outgoing transaction. But does the wallet interact with the blockchain directly?

What Goes on Behind the Wallet

Metamask doesn’t interact with the Ethereum blockchain directly! It talks to nodes, which have access to the data and are part of the network.

You can configure Metamask to communicate with a local Ethereum node, or specific ones, but by default it talks to something like a managed service in the background.

The service is called Infura. They describe themselves as “suite of high availability APIs and Developer Tools provide quick, reliable access to the Ethereum and IPFS networks”. So it’s a reliable endpoint you can use to communicate with the Ethereum network. Think of it as a somewhat-centralized gateway to talk to the blockchain.

But having services inbetween your DApp and the blockchain is nothing extraordinary.

Back-Ends Still Exist in DApp Land

Good news for all Go and other-backend-languages-slinging folks who are curious about getting into Web3.

Back-ends & servers are still a thing, and pretty relevant for powering DApps. But maybe not exactly in the way you would have expected it.

Getting data from the blockchain can be a somewhat-expensive operation. Scanning through all transactions isn’t free. So it’s a pretty common pattern, to have a back-end service which is responsible to cache data from the blockchain, and make sure it can be queried quickly and with less effort.

The source of truth is still on the blockchain but, for convenience and a better UX, your backend services are asked to provide that data to the front-end. Hooray!

However, write-operations are passed to the network more-or-less directly (well, submitting them to something like Infura nodes in the background, and waiting for the transaction to be written to the blockchain). At least as far as I understand it.