# **Decentralized Applications Architecture**

Web 3 is the application owned by the builders and users. This is some kind of new era for the Internet and an antidote to Web 2.0, which is represented by centralized solutions like Facebook (Meta), Google, and many others. In Web 3, ownership and control should be fully decentralized, but based on architecture and implementation, we have many types of solutions. In this article, we will try to review them and find some pros and cons of each approach.

The main difference is the way how specific architecture addresses the solution for storing the data and the way how Wallet, Frontend, Backend, and Smart Contract are connected.

**Pure Dapp (Decentralized Application)**


With this architecture, everything is decentralized how it should be for Web 3. The frontend is connected directly to the smart contract. The server (Backend) is not centralized as usual in Web2 but is fully decentralized. It stores and manages data in a decentralized distributed file system like IPFS (InterPlanetary File System). It is almost not possible to hack it or restrict access to this type of server. Actually, very few solutions are architect like this because using IPFS is a little bit more complex, and the costs of this type of architecture are also big. On the other hand, I expect that at some point, most of them will be like this. The advantages of IPFS are an important factor that I’m taking into account:

IPFS content is housed in several locations in a shared, peer-to-peer network using a distributed hash table (DHT). This decentralized protocol means there is no one point of failure in a single server. And no one entity can censor or eliminate the data. Not only is each resource in IPFS assigned a unique CID, but these CID files are immutable and cannot be altered by any third-party entity. IPFS also uses transport encryption to keep data secure when being sent from one IPFS node to another. IPFS provides much more control to content creators. Additionally, creators can distribute their work themselves without being dependent on a content distributor entity.

**“Centralized” Dapp (Decentralized Application)**


This is a common way how Dapps are built nowadays. Instead of IPFS the centralized backend is used, so the web frontend is also served from a centralized server. Usually, some cloud solutions like AWS, Azure, or Google Cloud are used to host and manage the web frontend and the backend. This approach is quite good if we have an existing service and we plan to port it to a Web 3 solution without building everything from scratch. The smart contract is only a decentralized part and is still connected directly to frontend.

**Decentralized Applications Architecture**


We can also use a standard centralized backend and broadcast of transactions. In this architecture, we have a fronted and backend, that serves this frontend. In this architecture, users don’t sign transactions on the fronted, but instead, they send the transition to backend. The backend makes sure that the transaction is correct and is going to broadcast it to the blockchain network. This solution can be good if we expect to have not experienced users who may make some mistakes and do transactions that are not correct (for example, transferring cryptocurrency to the wrong not, trusted wallet). This approach makes the system less secure because if the backend is compromised, then the application will not work. In theory, users can always try to send the transitions themself to the blockchain (for example, Etherium) network in that case.

**Backend with Signature**


In this architecture, again, frontend is not using the blockchain directly, but it creates the message that describes the change. It will sign that message and send it to the backend. Backend will make sure that everything is fine and will create transactions for the blockchain, which will embed that signature. The smart contract should verify if that transaction comes from the wallet of the backend and signature of the end user is also correct. This type of architecture is used quite often by centralized exchanges. The orders when you want to buy or sell crypto or tokens don’t go directly to the smart contract, but it creates this signature for transition. For example, buy 20ETH/tokens, and when there is a match for that transaction, it is processed as a final transaction on the blockchain. The biggest advantage of this architecture is that for end-users don’t need to pay transaction costs. The payment is on the application and backed wallet, so depending on our business model, this solution can be useful. Again the problem is that the backend server is compromised the attacker can empty the wallet of the Dapp. It will not usable anymore, but it is also not possible to forge the user’s signature, so it is still quite a safe solution.

**Backend with centralized wallet**


In this architecture, we do not have user’s wallet o on the frontend. The backend is operating on the blockchain and does the transaction on behalf of the user without his private key. This system is not decentralized, and if it will be compromised, users can lose all data or money. It is for sure not a trustless type of solution. The onboarding of the users is easier than in other Web 3 solutions. It is done inside the app in a traditional (Web2) way, so users don't need to have any wallet or buy a specific cryptocurrency and/or token to use the system.

**Conclusion**
Most people spend months figuring out how the tooling chain works and how to build app tailored to your business need. So if you’re a new DApp developer, I hope this article helps you to understand different approaches.

If you want to learn how to build web applications with a web 3.0 stack, clap👏 and follow me on HackMD. I am working on a tutorial for building Web 3 mobile solutions, which will be shared soon. If you see some value in my articles, you can also give me a tip below.