Summary of web3 features and technical layers involved in a Dapp development service

This article provides a comprehensive introduction to the technical layers comprising a DApp and the services supporting their development for those beginning to develop a DApp.

The three technology stacks that make up a DApp

The technology layers that make up a DApp can be divided into the following three categories as a prerequisite.

Smart contracts
Front end (UI)
Backend (server)

Summary of the technical layers that make up the DApp

DApp development services for each part of the tech stack

DApp development tools and platforms such as Hardhat, Truffle, thirdweb、Bunzz, – as well as a handful of infrastructure development related services-, are anchored in one of the three layers, which can be categorized and organized as follows.

Many services focus on smart contracts because traditional Web2-based development support tools lack the functionality to support the learning and development of new languages such as Solidity.

On the other hand, if DApp developers can handle or build the smart contract layer, the front and backends can be handled by traditional stacks and services such as Vue, React, AWS, and GCP.

Web2 developers already have 80% of the skills to develop Web3 applications

Nik, founder of Decentology, said regarding the composition ratio of the three layers, “front-end and back-end are 80%, and smart contract is only 20%. Web developers already have 80% of the skills to become DApp developers,”. Bunzz’s team agrees with this, with the excepton of DeFi products and other things that require complex and creative algorithms.

Since there are significant differences in the functionality and stance of the major development support tools we have mapped out, and the skill levels of the developers they focus on, we have created the following table comparing all the services.

We hope you will find it helpful to find the service that best suits your skills and objectives.

Please DYOR, use this as a reference only, as the specifications of each service will vary.

DApp and Smart Contract Development Environment Summary

Name of service	Features
Hardhat	1. Smart contracts can be coded, compiled, tested, and executed. 2. This service is popular as a contract development environment and is considered more modern than Truffle Suite. On the other hand, it requires knowledge of blockchain, solidity, and security, making it difficult for junior-level Web3 engineers to handle. 3. The interface is CLI, which requires an environment that can handle Node.js. 4. Emphasis on debugging capabilities of Solidity, with explicit stack traces and error messages on transaction failure. 5. There is also an ecosystem around plug-ins, which other users can reuse in their own projects. Official plug-ins as well as plug-ins made by Hardhat community members are available.
Remix	1. Open source web/desktop applications. Smart contracts can be coded, tested, and deployed. The documentation is well known for its ease of understanding, and even non-developers can deploy it. 2. Unlike Truffle Suite and Hardhat, it is an IDE (browser-integrated development environment), so there is no need to configure the development environment. 3. Users of Truffle and other development environments can also use Remix for quick testing of simple contracts. 4. Although it is possible to deploy a contract from Remix, the functionality is too limited to complete the DApp and make it operational, so it is suitable for prototyping.
Truffle Suite	1. The system has a console that allows direct communication with the contract, network management that allows deployment to the chain, and the ability to compile, link, and manage binaries for the contract. 2. Ganache, a local chain for testing contracts, is available. 3. As Truffle is a “Suite”, it supports not only the backend of DApp but also the frontend of DApp. Truffle has an ecosystem for building DApps, which is organized around “boxes” made up of multiple boilerplates. For example, a combination of smart contracts, libraries, and front-ends are available, and boxes created by the community can be used. Users can also create their own boxes.
OpenZeppelin	1. The main product is “Contract”, a library of smart contracts. Contracts are modular and reusable, and are audited for security, so there is no need to perform an audit. 2. They also provide “Defender”, a tool necessary for creating and automating DApps. 3. Provides documentation for usage with HardHat. It is more of a contract library than a web service, and does not support compilation or deployment, but there are use cases such as using OpenZeppelin libraries from development environments such as Remix.
Bunzz	1. The development environment allows users to easily build a DApp contract layer by combining modularized smart contracts, and the GUI allows intuitive operation. 2. The system can also be called a “smart contract repository service” because users can upload and publish their own smart contracts (scheduled for implementation in 2022 Q2). 3. The DApp front-end construction is supported by simple boilerplates for each module, which can be used as a reference to build the UI. Also, SDK is provided to call Bunzz smart contracts from the front end. 4. If you do not customize your smart contract, you can deploy it simply by operating the GUI without coding or configuring the development environment. All major EVM compatible chains are supported. The same as Remix’s contract testing function, you can check the status of each contract and perform operations such as Mint and Burn via GUI. 5. Bunzz’s modular smart contract architecture is designed to make smart contracts reusable among users in DApp development, enabling composability and a smart contract ecosystem. 6. In summary, Bunzz is an ecosystem that allows users to test and deploy “a library of audited smart contracts like OpenZepplin” with “Remix-like ease” and in the future compose them with other smart contracts in a “repository service like Docker Hub”.
Moralis	1. The platform specializes in building the off-chain side of DApp development, which consists of the off-chain side and the on-chain side. 2. The back-end functions necessary for DApp operations, including servers and nodes, can be easily implemented. This may cause vendor lock-in in the event of a Moralis service outage. 3. Since it is specialized in off-chain services, Moralis does not have functions for creating and deploying contracts, while use cases such as building contracts with Bunzz and back-end functions with Moralis can be assumed. 4. Of all the services introduced in this article, Moralis has the most extensive documentation and tutorial videos.
thirdweb	1. Like Bunzz, this service allows modularization of frequently used smart contracts and deployment via GUI. 2. The service is characterized by its ability to support not only smart contract development but also DApp operations, as it can measure the treasury of each DApp deployed and has standard permissions to control actions for contracts, such as Admin and Minter. 3. The thirdweb SDK is used for integration with the front end. The documentation provides a simple boilerplate for React. 4. The backend server is provided by thirdweb, so vendor lock-in may occur.
Decentology（Hyper Verse）	1. The platform provides modular smart contracts for composability, and like Bunzz, the modules are not independent, but can be combined (Hyperverse calls it Connectibity). 2. The deployed smart contracts on the chain can be accessed by anyone, but there is currently no service to search them, so Hyperverse provides a form-based searchable UI (searchability is called Discoverbility). 3. There is a community that audits modules developed by smart contract experts and offers modules with low security risk. The community can stake tokens (perhaps to design incentives for auditing).