Ethereum dApp Development Guide with examples
Good old Ethereum is the grandpa of numerous dApps and contracts. And the recent introduction of Ethereum 2.0 will significantly push further the interest in the process of building a dApp on Ethereum.
In this article, we would show and describe different types of dApps, their variations and distinctive features regarding the hosting blockchain. We will also show the real-life example of how to create a dApp on Ethereum using one of Blaize case studies.
But firstly, let’s define the type of dApp you want to create.
What is dApp?
DApp is shortened from decentralized application and stands for a web application that interacts with blockchain in general and smart contracts in particular.
Unlike standard (or centralized) applications that are deployed on a certain server and work with its private database, decentralized apps rely on blockchain. They can be deployed from scratch and need just the connection to the closest node.
Types of dApps
As far as technology grows and improves, there are a few types of dApps we can differentiate for now. We can basically divide them according to three main categories.
The first type of dApps communicates with the blockchain protocol directly. The most common examples of such dApps are wallets and explorers, like Bitcoin wallet, MetaMask, Polkascan, Etherscan, etc. In other words, those are dapps for the transport layer of the network when compared with the OSI model.
The second level represents dapps that communicate primarily with smart contracts and occasionally with the protocols. They are often hosted by one of the existing blockchains. EOS, Ethereum, and Tron are top blockchain platforms for dApps development.
Akropolis, Compound, Acala, yEarn – all of them are second level dApps. In spite of the fact that those are often called protocols, they are the actual apps (application) in their nature which interact with a decentralized environment.
We will dare to name the third level as a meta-level, which represents not application aggregators, but a large additional solution on top of the protocol. In particular, those are any layer-2 solutions or sidechains like Plasma.
The other good example of it might be any of the future dapps for increasing interoperability within the Polkadot network when parachains, bridges, and other cross-chain solutions will be connected.
Get to know more about how Polkadot works and some of the significant upcoming projects for this network in this article.
To summarize, the two first types of dApps contact the protocol and work inside of it (as far as we know that smart contracts also exist inside the chain). At the same time, the third level dapps go beyond the protocol and improve or broaden its operability.
As you have gone through the dApps types, you can identify which solution is the best for your project. In Blaize, we deal with all types of dApp development, yet we want to underline that during the period of Ethereum Beacon chain release, the amount of dApps built on top of this network is expected to grow. Therefore, in the next part of this article, we would like to share our experience on how to build an Ethereum dapp.
What about Ethereum 2.0?
Blaize blockchain engineers are true experts in their specific fields, so it is very important for us to find out about all the new updates of the system. Talking about the release of Ethereum 2-layer probably many of users are confused about what will happen with currently hosted dApps on the 1.0 version.
To keep your inner peace, as for now, nothing will happen with the already existing dApps, and their owners do not have to do a thing with them. Additionally, dApp development is still maintained on the Ethereum 1.0 version while 2.0 along with Beacon chain is aimed to introduce the new PoS consensus and provide crosslinks for the future integration of sharding.
It is worth noting that sooner or later Ethereum 1.0 dApp owners will have to migrate to the second version, but for now rules remain unchanged.
Besides concerns about Ethereum 2.0, there are a few issues such as the upgrade of Metamask, which should not be disregarded while creating dapp architecture at the current version of Ethereum. That is why we want to turn your attention to this and concentrate on the modern approach to dapp development.
Ethereum dApp development [ the trading platform case study]
Blaize got involved in the project in the trading and stock markets sphere. Our main goals regarding this project were the creation of Ethereum-based application packages and smart contracts development for this dApp functionality. In this part, we will share the experience of our real use case.
About the client
This case is under NDA protection so Blaize cannot publicize the name of this client and share any unique project specifications. However, the implementation of this project reflects perfectly the whole cycle of making a decentralized application on Ethereum and therefore helps us to show Blaize approach to dApp development in the best way.
The client came with an idea to create a secured and reliable platform to manage crypto assets and provide rewards for token holders. The platform must support its own tokenomics with two kinds of native tokens.
The first token should act as a regular ERC-20 token, and be an asset for internal credit rewards. The second token will represent the rewards themselves, which are charged for keeping ETH on the balance.
In other words, the user provides Ether while trading and keeping it to the system. Every month the system should create a snapshot of the token holders, which stands for the list of active users. Then, the system distributes rewards monthly in accordance with the user’s activity within the platform.
We can generally split the whole project implementation into three parts:
1 Phase: includes smart contract development and its further coverage with tests;
2 Phase: concentrates on Ethereum-based dApp development with additional MetaMask integration;
3 Phase: consist of backend service and eventual dApp upgrades.
Recently we have been sharing a few articles regarding smart contract development and conducting security audits of smart contracts along with unit test coverage preparation. So, in this article, we want to move to the part describing dApp development and the following challenges.
How Blaize built a dapp: developing a web wallet
The dApp required for this kind of project represents the second type of dApps and uses Ethereum smart contract as a base.
In order to anyhow interact with Ethereum blockchain, every dApp needs a MetaMask integration. This makes the performance process smoother and eliminates unwanted frictions.
In terms of trading platform, MetaMask is used for dApp logging, sending the transactions, and getting the service info about the user’s holdings along with other data. Also, it stores the actual user account which is used for receiving the funds and rewards.
How Blaize built a blockchain app: developing an Ethereum dApp
The application was built using React and Node.js. During this phase Blaize engineers concentrate on launching an actual dApp in the following steps:
- connect to Ethereum network using the injected web3 provider from previously installed MetaMask;
- configure with the previously built smart contracts;
- load and deploy smart contracts;
Blaize engineers recommend using the OpenZeppelin framework for upgradable contracts in order to ensure safe and smooth contract updates. Thanks to its usage, you can check for the updates and apply them automatically during the deployment. It will also watch all the new changes and recompile the contracts automatically.
- connect with Infura node.
You can see an example of an Ethereum-based blockchain app through this code sample.
Difficulties of dApp development for trading platform
As the main difficulty of this development, we can underline the complexity of initial business logic and tokenomics the application is aimed to use. Projects of this kind require very thoughtful and time-consuming analysis of all the possible interactions between app and contracts, app and user, app and Subgraph storage.
Websocket drop fix
One of the main problems was implementing transaction history in a dApp while having the rewarding system on the backend.
In order to make the transaction history visible for users, there is a need of getting the data from the Ethereum node WebSocket. Such an approach requires the processing of a huge amount of data coming from the node during each transfer to the “transactions” section.
The communication between transaction history and reflected data on the dApp can be dropped due to WebSocket occasional connection issues. Therefore, we needed to implement the functionality to eliminate possible disconnections. We have developed an additional worker which watches the WebSocket and fixes the occurring drops.
Solution for requests limit
While entering the application, the user begins to request data from contracts. The Infura key is one and the same for all dapp users. As the number of users grew, it became necessary to increase the number of possible requests from Infura.
In order to solve this problem, we needed to optimize the requests’ processing on the Ethereum node. We have performed this by keeping most of the received information in the Redux store, and updating it from time to time (caching). It helped to reduce the number of requests by 10 times.
Want to optimize your current solution in such a way? Do not hesitate to contact and we will tell how we can do it together!
The trading platform has to store large and extensive transaction history that slows down the application performance. An excellent solution is to receive transaction data not through the Infura hosted Ethereum node but through a specialized service.
We decided to implement Subgraph hosted on The Graph service, which indexes the transaction history (and other data) in real-time. Subgraph usage helps to optimize a system’s work and makes it very efficient. The service is free, which additionally helps to optimize costs.
See other example of Subgraph implementation in our snglsDAO case description.
We deployed the Subgraph for this application. Dapp is reconfigured to interact with Subgraph using GraphQL. Thus, we remade the architecture of the application so that it receives history not from contracts or node, but from the Subgraph.
In order to build decentralized application for trading platform Blaize used following technologies:
- Front-end: React, Redux, React-bootstrap, Web3.js
- Backend: Node.js, MongoDB, Docker, Web3.js
- Blockchain: Ethereum, Solidity, Truffle
From this article, you know the process of developing dApps on Ethereum and some of the crucial specifications of it. As you can see in order to provide dApp development services, the company needs to possess a vast knowledge of different blockchain platforms and their unique characteristics.
Need skilled blockchain developers to deploy your own dApp? Schedule a call to answer all your questions or get to know more about our dApp development services.
There are also a few crucial differences between existing dApps, so we can divide them into types. This helps to understand the project scope and required skills for your project development.
Start developing your dApps on Ethereum with Blaize!