Web 3.0 Decentralized Applications or dApps (Part 17)
Welcome to the 17th part of the 100 part series on Blockchain.
Previous parts: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 and 16.
Web 3.0 dApps or decentralized applications are the digital applications or programs that are run on a decentralized, peer-to-peer Blockchain network.
Let’s consider the examples of Web 2.0 traditional apps like Facebook, Twitter, YouTube, etc., where the backend code runs on centralized servers, owned and operated by an organization, giving it full authority over the app and its workings. There may be multiple app users, but a single organization controls the backend.
On the other hand, the backend code of dApps runs on the decentralized peer-to-peer network. That means the apps are run on a network of computers instead of a single computer; thus, dApps are not under the control of one person or entity. For example, one can create a YouTube-like dApp and put it on a Blockchain where any user can post videos. Once posted, no one, including the app creators, can delete the videos.
Web 2.0 App architecture
To understand how dApps work, it is essential to understand the architecture of a web 2.0 app. Every mobile or web application has two parts: the front end and a backend server.
Frontend: The frontend of the web application is the part with which the user interacts directly. Therefore, it is usually referred to as “client-side.” The frontend consists of everything that the user sees while interacting with the app, such as text colors and styles, graphics, images, tables, buttons, navigation menu, etc. The main languages used for frontend development are- HTML, CSS, JavaScript. The frontend code runs on the client’s browser for the web application.
Backend: On the other hand, the backend is the server-side of a web application. It is responsible for receiving user requests and sending appropriate data back to the user once the logical processing is complete. While the backend doesn’t interact with users directly, it includes all the code to power apps from behind the scenes. In a nutshell, without a proper backend, the frontend won’t work properly. It is the brain of any app. For example, filling your credentials in a registration form is managed by the frontend, but when you click ‘enter’ and get registered, the backend makes it work. The backend has three components: server, database, and APIs.
(i) Server: The server is a computer that can be present on-site or in the cloud. The application running on the server listens for requests, retrieves information from the database, and sends a response. The languages used for writing the backend code are- JavaScript, PHP, Python, Java, etc., which can interact easily with the frontend.
(ii) Database: A database is a part of the backend that makes the web application dynamic. Whenever any user makes a request, like searching for a product in an online store or searching for restaurants for food delivery, the database is responsible for accepting the query, processing it, fetching the data, and returning it to the user. The database is also accountable for accepting new data and editing the old data, as desired by the user.
(iii) APIs: Application Programming Interface or API is a software intermediary that allows two applications to talk to each other. Let’s understand APIs through a real-life scenario. Imagine you’re sitting at a table in a restaurant and want to order a sandwich. The kitchen is the part of the restaurant that will prepare your order. The waiter is here the critical link to communicate your order to the kitchen and deliver your food back to you. In other words, the waiter is the messenger or API that takes your order and tells the kitchen what to prepare. Then the waiter delivers the response back to you; in this case, it is the sandwich. Here is a real-life API example, if you want to purchase something from an online store, the backend manages the actual monetary transactions. While the frontend makes sure that the check-out button is appropriately positioned on the page, the backend interacts with the third parties (your bank or PayPal) for the payment. The entire process of transactions happens behind the scenes in the backend.
How do frontend and backend work together?
Frontend and backend communicate with each other via Hypertext Text Transfer or HTTP requests. In the web application, when a web address or URL is entered in the browser, the browser then makes a request to the server using the HTTP protocol to locate the address of the requested resource corresponding to the entered URL. The server then accesses the database to get the information and returns an HTML page. HTML is the language used to write the contents of the web page. This response is sent to the user browser that requested the resource. The browser then interprets the HTML code and draws the screen showing images, buttons, and all the information on the requested page.
Web 3.0 dApp architecture
With decentralized applications or dApps, there is also a frontend client and a backend server. But unlike Web 2.0 applications, Web 3.0 eliminates the need for a centralized database and a centralized web server; instead, the Blockchain is used. The most used Blockchain Blockchain platform for implementing dApps is Ethereum. Other Blockchain platforms that are also available for dApp implementation are Hyperledger Sawtooth, Hyperledger Fabric, EOS, etc.
Frontend: Like web 2.0 applications, the frontend of the dApp is written using HTML, CSS, and JavaScript programming languages.
Web3.js: Web3.js is a Javascript library that enables your frontend to interact with the Ethereum network. To connect with the Blockchain, you need to connect to a node. It can be done by running a node on your computer. And if you don’t want to run a node, you can connect with a third party who is running the nodes, e.g., Infura. The nodes that you connect with to interact with the Blockchain network are often called “providers.”
Smart contract: Smart contract is a self-executing program that runs on the Ethereum blockchain and defines the logic of a dApp. Smart contracts are written Solidity language. Because the smart contract code is stored on the Ethereum Blockchain, anyone on the network can inspect the code.
Additionally, smart contracts can also connect to any API by integrating Oracle. This helps the smart contracts to extract external data like weather information, market data, etc. One can also make payments through a bank on dApp because of Oracle.
Ethereum Virtual Machine or EVM: EVM executes the logic defined in the smart contracts and processes the updates that happen on the globally accessible Blockchain. The EVM doesn’t understand Solidity language, which is used to write smart contracts. Instead, you have to compile the code written in Solidity language into bytecode, which the EVM can then execute.
How does the frontend of Web 3.0 dApp communicate with the Blockchain network?
Because of the decentralized network, every node in the Blockchain network is required to keep a copy of the full Blockchain, including the code associated with smart contracts. Once you connect to the Blockchain through the node, you can submit the transaction to the Blockchain only after signing it using your private key. For instance, imagine you have a dApp that lets users view or post videos to the Blockchain. You might have a button on frontend that allows anyone to view the videos. Viewing videos on the Blockchain does not require a user to sign a transaction. However, when a user wants to post a new video onto the Blockchain, the dApp asks the user to sign the transaction using their private key; only then transaction, i.e., the new video will be posted. Otherwise, the nodes wouldn’t accept the transaction.
For “signing” the transactions, the third-party Metamask is required, which stores the private keys of a user in the browser. Whenever the frontend needs the user to sign a transaction, it calls on Metamask to sign the transaction and submit it on the Blockchain.
Storage on Blockchain: The smart contracts are stored on the Ethereum blockchain. But storing every dApp data on the Blockchain gets really expensive. The user needs to pay every time they add new data to the Blockchain. Asking your users to pay extra fees for every new transaction on your dApp is not a good experience for the user. This issue can be solved by using a decentralized off-chain storage solution, like the Interplanetary File system abbreviated as IPFS. Instead of storing data in a centralized database, the IPFS system distributes and stores the data in a peer-to-peer network.
Additionally, you can host the frontend code of your dApp on the cloud as in Web 2.0, but that creates a centralization for your dApp. If you want to build a completely decentralized app, you might choose to host your frontend code on decentralized IPFS.
Advantages of dApps
(i) Open source: The dApp code is open source, which means the code is transparent, and anyone can look at the code. This allows a lot more trust in the application.
(ii) Censorship Resistant: dApps are censorship-resistant. It means they don’t have to answer government, corporations, or specific people. In the case of web 2.0 applications, anything or any service which may violate codified laws and is against the interests of powerful political groups or government, etc., is at risk. This is why Facebook or YouTube removes content that could be considered objectionable or is not conducive to their growth. But this is not possible with dApps. If the smart contract is coded to do something and is triggered, nobody can stop it. Censorship resistance ensures that no one on the network can block users from submitting transactions, deploying dApps, or reading data from the Blockchain unless the code is written to do this.
(iii) No downtime: Another essential benefit of dApps is that there is no downtime, or the app will never go offline. There have been times when Facebook or YouTube are down, maybe because of a single point of failure like the servers have a bug, or there is an outage. Since dApps run on Blockchain, they will actually never go down because they are run by hundreds and thousands of computers all around the world. It would be infeasible to turn them all off.
Challenges of dApps
(i) It is challenging to modify smart contracts once deployed.
(ii) Also, it becomes difficult to fix any issues in dApps because fixes require every node in the network to update all the copies in the network.
Few examples of dApps
(i) Social network dApps: Sapien, Steemit, Sola, e-Chat, etc.
(ii) DeFi (Decentralized Finance) Apps: AAVE, IDEX, EOSFinex, etc.
(iii) Insurance and banking dApps: AiGang, Everledger, etc.
(iv) Streaming dApps: DTube, UjoMusic, Theta EdgeCast, etc.
(v) Gaming dApps: Cryptokitties, Zed Run, Splinterlands, Alien Worlds, etc.
If you liked this article and want to know more about Blockchain, NFTs, Metaverse, and their applications, click the below link.
Happy learning!
