How to develop a dapp and why is it so complicated?
Decentralized apps are the catalysts for the decentralized web adoption, bridging the gap between the end user and the decentralized network systems.
However powerful they are (or precisely for that reason), their development is no walk in the park. The tech that dapps employ is extremely niche and complicated, while the immutable and irreversible nature of operations on the blockchain turns the process into a serious pain in the neck once errors or issues arise.
In this article, we explore the common way of dapp development and its impediments while aiming to provide a viable solution.
How developing a dapp looks like?
The essence of dapps is employing decentralized systems for their operation and execution of functions. The decentralized network that is utilized most often is the blockchain tech and in rare cases the distributed ledger tech. Combined with cryptography, these systems provide operations that are inherently immutable, irreversible and sealed on the decentralized network.
So while they provide a fantastic operating potential, the features of dapps also pose a massive obstacle in the development process.
The common way of building a decentralized app does not come around as a clear recipe with a fixed order of steps. Instead, it often looks something like this:
Dapp development requires frequent iterations and adaptations, as well as an understanding of several layers of decentralized systems and communication elements.
The cycle of dapp development
To illustrate the usual dapp building process, let’s look at an example of a dapp on the Ethereum blockchain.
- First, you set up the environment for writing smart contracts, install the nodes (Geth, Parity, etc.), install MetaMask, and open the code editor. Then, you start creating smart contracts in Solidity.
- Once you manage to write your smart contract, you move on to testing, compiling, and deploying it onto the Ethereum blockchain.
- You then realize that the thing is not working. It did work in the local test, but not on the Geth node. You go back, try to find the errors (Solidity does not show Error messages as you’re used to in other environments), you fix them, test the contract again, compile and deploy it. Now, you think, it should be working.
- Or not. This time, the contract is working well on the Geth node, but not on the Parity node.
- So you go back to look for the snag, you manage to find, and fix it. You deploy the darn thing again and wait for it to work.
- It’s just that — it doesn’t. It works on the Parity node, you’ve made it work on the Geth node. So what’s stopping it? It could be the connection with MetaMask.
- You go back for the third time and fix this one, too. At this point, it looks like all the issues have been fixed and the smart contract seems to be working as you wanted it to.
- If you’re not so lucky, you find issues with Ganache. In some cases, the checkSum works, and sometimes it doesn’t. Or, lower-cased addresses work locally but not on MetaMask. And so on…
It doesn’t stop there
All these trials and go-backs take not only loads of time, but also require solid experience in the field to be able to foresee potential issues as effectively and as soon as possible. Because the more you try and test, the more gas you spend. But you have to do the testing to see if it works.
Even once it does, you have to analyze the operation that your dapp successfully executed. If, for example, your smart contract was built to transfer assets, you should verify the result. Also, you should assess your dapp’s price performance by checking the gas fee that was induced in operation and compare it to other transactions and values.
Then, there is the audit. Third-party auditing of your smart contract is an important measure to eliminate the most if not all possible malfunctions. Great auditors should know all the best practices of the Ethereum blockchain and be a step ahead of you in issue detection and solution proposal. However, since even audit service can sometimes be subpar, projects often rely on community feedback. Community review is optimal because it’s based on a shared interest — first to provide and then to leverage a top-notch dapp. Bug bounties are therefore an excellent incentive for the developer community that benefits both sides.
And then we come to the dapp’s front-end. You have to connect your dapp’s UI with the blockchain and write the communication logic. Often, developers have to work with an incredibly large library in the communication logic, which then impedes the effective optimization of the front-end.
Last but not least, you should take care of essential elements required for both centralized and decentralized apps. When it comes to API, there is not much difference between an app and a dapp, but its set-up still takes time. You should also arrange hosting, domains, etc.
What are the issues with this approach?
This process of dapp development is far from optimized, and there are several issues with it:
1. Solidity doesn’t handle as many things for the developer as mature languages do, e.g., it lacks error warnings, so you should foresee the issues, and once they occur, you’re on your own to find them.
2. Once a block of the data string is confirmed, there is no way back.
3. Testing every little thing is crucial before deploying it to the blockchain but it also costs ETH.
4. It’s difficult to choose the most appropriate framework since each one offers a different set of functions and half-way into the code you could find that it doesn’t do the job for you.
5. Gas fees are substantial since you have to repeat the testing several times around, each time costing you some gas. Also, if you integrate functions into your smart contract, the gas cost increases.
6. Libraries in the communication layer are usually huge, they also come in many versions and produce their own errors, which brings us to…
7. Very difficult front-end optimization of a dapp.
All this is inevitably time-consuming and requires a strong team of developers with years of experience, which in turn leads to significant expense and still does not guarantee a quality end result. Since even a small mistake can cause a lot of damage, it also takes its toll on the developer experience.
Ultimately, this slow, painful, and cost-ineffective process is one of the major blockers that prevent the adoption of the blockchain tech and decentralized apps in real businesses and institutions.
How to untangle this Gordian knot and develop a dapp with much less hassle?
If we could funnel all the above complexity down to just a few lines of code, it would save the dev teams months of work, cut down their budget significantly, and provide faster and quality results.
Instead of addressing and improving one issue at a time, we believe that the whole dapp development process should be redefined. Developers should have a tool that saves them time and tackles the listed issues effectively.
The 0xcert Framework happens to be just that.
The 0xcert Framework was built specifically for application developers.
- It cuts the need to be a blockchain expert with years of experience.
- Your project also doesn’t have to hire security experts and expensive auditors.
- All you need is knowledge of building a website.
The solution is a simple and intuitive JavaScript API that can be employed either in the browser or on a server.
- The Framework establishes the communication directly with the Ethereum node, and all the calls are tested to work on all the Ethereum nodes as well as MetaMask.
- All the errors that we’ve found during development are tackled successfully within the Framework and developers don’t even encounter them. And as soon as Solidity starts supporting error handling, the Framework will include that, too.
- All the contracts are pre-written, audited, and packed into a single line of code for deployment.
This is an opinionated Framework made for application developers that supports two officially approved standards and hence two types of assets:
- the ERC-20 standard for fungible tokens (currencies) and
- the ERC-721 standard for non-fungible tokens (assets).
This means you can use the Framework to create dapps for the financial sector (currency) or the industry (assets) — or both. The functions in the Framework are compliant with both standards, and additional functions are added to support these standards in an administrative way.
Another powerful and unique part of the Framework is the certification layer, an innovative Merkle tree algorithm that enables selective verification of data of any JSON Schema format.
And the best part? It’s open-source and free for the developer community to bring dapp development to a whole new level.
The Framework is freely available on our GitHub and comes with a thorough documentation. Feel free to use it for you next dapp and let us know how it worked for you on our Gitter chat.
Read more of the Dapp series:
Part #1 — Intro: What are dapps
Part #2 — Tutorial: How to run and prepare Geth Node for back-end integration
Originally published at 0xcert.org.
