Facing the enormous task of understanding all the different parts of a Web3 application, also known as dApps (decentralized applications), might be frightening at first. If you are a beginner or even a little advanced in the field, you still might have a lot of doubts surrounding the subject. But don’t worry — we’ll try to address all your doubts and explain the differences between the architecture of web2 and Web3 applications throughout this article.

Understanding the architecture of a Web3 application is crucial for making an educated decision when choosing your preferred tech stack. 

In this article, you will learn what a Web3 application is and the different parts of its architecture, with a few examples of what you can use for building your own.

What is a Web3 application?

The term Web3 is vaguely used and can mean many different things. In this article, we will refer to Web3 applications as those applications that are decentralized by nature. These are called dApps, and they run on a decentralized network, such as a blockchain, while using different decentralized protocols and technologies to achieve their goals. They work without needing people to trust them (trustless) or be able to shut them down (censorship-resistant), so they can do what they’re supposed to do no matter what. 

Developers typically achieve these properties using smart contracts and multiple decentralized protocols to construct a fully decentralized application.

General Web2.0 application overview

To begin with, let’s briefly review what a web2 application architecture might look like. This will help us compare with a Web3 application’s architecture later. 

The above diagram shows a general web2 application architecture with a frontend, a backend, a database, and maybe some external services connected to your app, such as  APIs. When users interact with the front end, they may have to authenticate somehow —often using an email address and password. 

The backend is the part that is responsible for processing and storing the data, as well as communicating with other systems or services. It manages APIs, database management, etc.

The database stores all the app’s information, including all the information about your account. Having one entity controlling all the data creates a single point of failure since this database could be compromised with all your information.

You need to trust the owner of the application with your information.

General Web3.0 application overview

Now let’s see how the standard architecture of a Web3 application differs from the above. Please be aware that new protocols and methods for creating decentralized applications are frequently emerging, and the following serves only as an illustration of how a typical Web3 application might appear.

As you can see in the above diagram, a few things in a decentralized application differ from a web2 one.

First, a user interacts with a frontend in Web3 via a Signer (usually a wallet). The user still interacts directly with the frontend, but whenever they need to approve/decline a transaction, they will get a pop-up from their signer asking for approval.

Please notice that the backend and database in a Web3 application are depicted with dotted lines. This shows that in a dApp, you don’t need a backend. Since the core computing and app workings are coded in a smart contract living on the blockchain, you don’t need a backend. However, you could have one to improve the user experience, which some Web3 applications do.

The frontend or the backend (depending on a particular case) needs to connect to the blockchain to send transactions and request information. To do this, we need access to a node. A node allows us to interact with any smart contract deployed on the blockchain. We’ll be diving deeper into this later in this article.

Now that we have an overview of a possible architecture let’s take a deeper look into each component:

Signer

A signer is an entity that signs transactions in the user’s name. Whenever a user wants to interact without a dApp and ultimately with the blockchain, there must be a signer with its private key approving or discarding the transaction. This signing process can be done with a hardware wallet, software wallet, Metamask or Trust Wallet, etc. 

One interesting thing to notice is that we don’t need authentication with a user and a password in a Web3 application because the Signer already has a unique identity, the public key. 

Frontend

The main component web2 and Web3 applications have in common is the front end, but they can be very different. As we said, the idea of a Web3 app is to be as decentralized as possible. This could mean having an open-source code and a hosting solution for your front end that is decentralized. Services, such as IPFS or SWARM, are mainly focused on decentralized storage.

In the most basic version of a dApp, the front end serves as an interface for the underlying smart contracts, nothing else. Your backend could be only one — or several- smart contracts, and the frontend is the way to communicate with it easily for every user. You can permanently interact with smart contracts without a frontend.

Blockchain & Smart Contracts

Smart contracts are our “Backend 3.0”. As previously mentioned, a decentralized application does not need a backend; it uses smart contracts. Adding a regular backend to improve the user experience is a common practice.

We’ll focus on the EVM (Ethereum Virtual Machine) as an example, but there are several blockchains where one could deploy smart contracts. A smart contract is a piece of code that runs on a blockchain and will live there forever. The smart contract could be written in Solidity, then deployed into the Ethereum blockchain,  ready to use. Your users do not need the frontend to interact with the smart contract since they can do it directly from their wallets (for advanced users). 

The smart contract keeps all the data public, and almost every action they perform gets charged a small fee called “gas” that goes to the network. 

Blockchain Nodes

A node is a software application that connects to the blockchain and provides access to the data and functionality. Nodes are responsible for validating transactions, updating the blockchain ledger, and broadcasting new data across the network. These responsibilities are the reason why you need a node to communicate with the blockchain. One communicates with a node via RPCs (Remote Procedure Calls), and there are libraries to help, like ethers.js or Web3.js.

Anyone can run a node. You can even run one yourself. However, running your own node can be technically challenging and resource-intensive. The easiest and more commonly used solution is using a node provider. These services provide a network of nodes of easy access and high availability for developers to access and interact with the blockchain.

Consider this: if the node you rely on for your dApp happens to experience downtime or latency issues, the ramifications are felt immediately and directly impact your dApp and your users.

Node providers & Blast API

Node providers enable dApps to send and receive information from the blockchain through APIs, eliminating the need for dApp owners to run their own full nodes. An ideal node provider should have lots of nodes distributed globally, high availability, low latency, and support for all the blockchains your dApp may utilize, among other features.

This is where the Blast API comes into play, ensuring that programmatic communication with the blockchain is way simpler.

Blast API solves infrastructure issues related to reliability and latency through a multi-region architecture that uses geographically distributed third-party nodes. Properties like the ones mentioned make user requests optimally routed to the nearest point of presence. 

Faster interactions!

Blast supports a carefully selected set of blockchain projects, making it easy for platform users to generate API endpoints. This way, you can have support on several blockchains and generate those endpoints with just one click (see the image above). 

There is also a Javascript/Typescript SDK, the Blast SDK, which makes the development experience smoother.

One of the best parts is that Blast offers a free subscription plan, and users have the option to upgrade to paid plans based on their development and production needs. 

To try it out, you can go to the Blast API website, click “Launch App,” register, and quickly get started. 

Conclusion

Decentralized applications (Web3 apps) can take different shapes, and the architecture constantly evolves. In dApp development, choosing a tech stack that enables you to concentrate solely on what is essential, covers all your dApp’s needs, and is easy to maintain is critical.

You may or may not need a backend, centralized database, and lovely front end… But you will always need a node to help you communicate with a blockchain.

Blast’s standardized Blockchain API service covers all infrastructure aspects of Web3 development. The API can be used for free, so make sure to visit https://blastapi.io/ and give it a try! 

Thanks for reading, and if you have any questions, you can reach out through our discord server.