The Structure of an Internet 3.0 application

The design and architecture web 3.0 apps (or “DApps”) are totally distinct from web 2.0 applications.
Take Medium for instance, a blog site which lets users post their own content as well as interact with other users’ content.

As an internet 2.0 software, Medium might seem straightforward, but there’s actually plenty of factors in Medium’s design to enable it:

First, there needs to be an appropriate place to store important information, like users tags, posts comments, likes and others. This will require a regularly up-to-date database.

Second Backend code (written in a language such as Node.js, Java, or Python) should define the business logic of Medium. For instance what happens when an account is created by a new user and publishes a blog, or posts on another’s blog?

Third Frontend codes (typically composed with JavaScript, HTML, and CSS) will determine the Medium’s UI logic. For instance, what will the website look like, how does it change when users interact with the elements within the site?

In the end If you write your blog on Medium it interacts with the frontend of Medium, which communicates with its backend, which communicates with its database. The entire code is stored on central servers, and is delivered to users via an online browser. This is an excellent overview of how the majority of Web 2.0 applications work today.

What is it that makes what makes Web 3.0 different?

Contrary to the Web 2.0 applications such as Medium, Web 3.0 eliminates the middleman. There’s no central database that can store application state. There’s also no central web server that houses the backend logic is located.

In addition, it is possible to utilize blockchain technology to create apps using a decentralized state machine which is maintained by nodes that are anonymous on the internet.

When I say “state machine,” I refer to a machine that keeps certain program states and the future state that is allowed by the machine. Blockchains are state machines created with a initial state and are governed by very rigid rules (i.e. consensus) which define how the state can change.

Furthermore, no one entity is in charge of the decentralized state machineit is maintained by all members of the network.

What is the backend server? In lieu of how Medium’s backend was managed In Web 3.0 you can write smart contracts that determine the application’s logic and put them into the state machine that is decentralized. This means that everyone who wishes to build an application using blockchain deploys their code to that shared system.

The front end? It’s pretty much the same, but with a few variations, which we’ll examine later.

A Closer Look

Let’s now dive for a deeper look at the factors that make this possible.

1) Blockchain

It is said that the Ethereum blockchain is frequently referred to as the “world computer.” That’s because it’s an open and deterministic state machine that is managed by a peer-to peer network of nodes. Changes in state on this machine are controlled by rules of consensus that participants in the network follow.

In other words it’s actually made to function as a state machine that everyone anywhere in the world is able to access as well as write on. This machine isn’t controlled by any one entity but is owned collectively by everyone on the network.

Another thing to be aware of The data is only transferred to the Ethereum blockchain. You are not able to update existing data.

2.) Smart contracts

Smart contracts are software program that operates in the Ethereum blockchain. It specifies the logic behind state changes that occur in the Blockchain. Smart contracts are written in high-level language like Solidity and Vyper.

3) Ethereum Virtual Machine (EVM)

Then, there’s you have the Ethereum Virtual Machine that implements the logic defined in the smart contracts . It also manages the state changes that occur in this state machine.

The EVM cannot comprehend high-level languages, such as Solidity and Vyper that are used to create smart contracts. Instead, you must translate the high-level language to bytecode, which the EVM can then run.

4) Front-end

Then, we get the frontend. As we said earlier it is the one that defines what is known as the UI logic, however, it also interacts with the logic of the application defined in smart contracts.

The interaction between the front end and smart contracts can be a bit more complex than what is in the picture above. Let’s have a closer review of this.

What is the Frontend Code Communicate with Smart Contracts on Ethereum?

We would like our frontend to be able to communicate with the smart contracts , so that they can trigger functions, but remember that Ethereum is an open network. Every node on the Ethereum network has an exact copy of every state in the Ethereum state machine, which includes the code and information that are associated with each smart contract.

If we wish to exchange information and the code in the blockchain, we have to communicate through one of these networks. This is because every node could transmit a request for transaction to be performed using the EVM. A miner then will execute the transaction and broadcast the resultant state change to the remainder in the system.

There are two methods to announce a transaction:

# Create your own node that is running the Ethereum blockchain software.

# Use nodes that are provided by third-party providers such as Infura and Alchemy

If you are using a third-party provider it is not necessary to go through the hassles associated with running a full node by yourself. In the end the process of setting up a brand newly created Ethereum instance on your personal server could take some days. (There’s lots of data that needs to be synchronized — and it can consume more bandwidth and storage space than an average laptop can manage.)

Additionally storage costs for the entire Ethereum blockchain increases as your DApp grows, and you’ll need to increase the number of nodes you have to increase the capacity of your infrastructure. As your infrastructure grows more complex and complex, you’ll require permanent DevOps engineers. They’ll assist you in maintaining the infrastructure to ensure reliable uptime as well as quick response times.

To sum up that avoiding these issues is the reason why numerous DApps prefer to use services such as Infura and Alchemy for managing their node infrastructure. Of obviously, there’s a price to pay as this creates a central chokepoint, but let’s just leave this rabbit hole for another day. 😉

Let’s now look at providers. The nodes you connect to when you want to communicate with blockchain (whether you create them by yourself or utilize existing ones that are provided by third-party providers) are commonly referred to as “providers.”

Storage on the Blockchain

Of course, this design is ideal if you’re developing an application where all the data and smart contracts reside in Ethereum. Ethereum blockchain. However, anyone who has developed apps using Ethereum realizes that storing every single thing on the Ethereum blockchain is extremely expensive, very quickly.

Be aware that with Ethereum users, they pay each time they add new information into the Ethereum blockchain. This is due to the fact that adding states to the state machine that is decentralized will increase the cost of nodes that maintain the state machine.

Paying users extra to use your DApp each time a transaction requires a change in state is not the ideal user experience. One solution is to utilize an off-chain storage service that is decentralized such as IPFS and Swarm.

IPFS is an open file system that is distributed for the storage and retrieval of data. Instead of keeping data in a central database it is an IPFS system stores and distributes the data on a peer-to-peer network. This makes it easier for you to access it whenever you require it.

IPFS also comes with an incentive layer, known in the form of “Filecoin.” This layer encourages nodes all over the world to keep and retrieve information. You can choose a service such as Infura (which offers you the IPFS node) or Pinata (which offers a simple-to-use service to “pin” your files to IPFS and then take the IPFS hash and save it in the Blockchain).

Swarm is like Filecoin in the sense that it’s a decentralized network for storage however there’s a significant distinction. Although Filecoin is a distinct system and incentive system, Swarm’s incentive system is integrated and enforced by smart contracts that are built into the Ethereum blockchain to store and retrieving information.

Querying the Blockchain

So far, we’ve discussed about how to connect to the blockchain by signing transactions and then transferring these to blockchain. What about reading the data from smart contracts that are on the blockchain? There are two methods to accomplish this:

1) Smart Contract Events

It is possible to use Web3.js to access the Web3.js library to search and listen for events that are smart contracts. You can listen for specific events and set an event callback each time the event occurs. For example, if you have smart contracts that transmit the continuous stream of payment through person A B every block, you could trigger an event each when a new payment is sent to the person B. The frontend code will be able to be able to listen for events generated through the smart contract. It can then take specific actions in response to it.

2) The Graph

The method above works however it does have certain limitations. For example, what happens do you do if you create the smart contract, and then discover that you require an event that you didn’t intend to include? In this case, you’d need to redeploy a smart contract that incorporates the relevant event and data. Furthermore, using callbacks in order to manage different UI processes can get very complicated fast.

This is the point at which “The Graph” comes in.

The Graph is an off-chain indexing system that allows you to access information stored within the Ethereum blockchain. The Graph lets you define the smart contracts that you want to index as well as which functions and events to be listened to and also how to convert inbound events into entities the frontend code (or any other application that uses API) API) can use. It makes use of GraphQL as query language that frontend developers are drawn to because of the way it is in comparison to traditional REST APIs.

By indexing blockchain data The Graph lets us query on-chain data within our application logic using low latency.

Cobbling It All Together

If this list is spinning your mind You’re not alone. The process of putting together these tools is a challenge and could cause a very unpleasant user experience for developers. However, don’t fret because we’re starting to see new frameworks for developers that will improve the experience for developers.

For example, it is a development tool that allows it to be easy to Ethereum developers to create and deploy the smart contract they have created. Hardhat provides its users the “Hardhat Network,” which developers can utilize to launch their smart contracts on an existing network without the hassle of live environments. Additionally, it provides an amazing plugin environment that makes the life of developers significantly simpler. Hardhat also comes with console.log() function like javascript for debugging purposes.

It’s true that this is only the beginning. I’m hoping to see improved developer tools in the near future.

Now is the time to start building!

If the creation of Web 3.0 applications is something you’re interested in, we’re HERE for you.