Dive Into dApps: Your Ultimate Guide to Start Crafting Them Today!

Content Overview

• What is dApp?
• What client-side technologies should be used for a dApp?
• Which type of domain should you choose?
• Authentication: MetaMask's Dark Side
• Blockchain Selection: Which Chains Are Best for dApps?
• Funding Your Idea Through Grants

What is dApp?

The commonly accepted definition of a dApp is, in short, an application that can operate autonomously using a distributed ledger system. At first glance, it seems straightforward. But, when you begin to question and list examples of dApps, it appears most dApps wouldn't qualify. It may even seem as if true dApps don't exist.

If one developer tried to explain to another what a dApp is in 2023, they'd probably say, "Well, it's like a website that calls various APIs working with blockchain." Just like that, the magic of the term 'dApp' would vanish. The other developer would think, "What's the big deal? Why so much fuss about it?"

The reason is that the genuine concept of dApps has long been sacrificed for user convenience. Originally, the term implied that every instance of the application runs on the user's device. You'd fetch wallet balances from your node, and you'd send transactions from it as well. The application itself should be stored on a distributed storage system resistant to censorship, outages, and attacks. All user-generated data should also be stored in such storage or directly in a blockchain smart contract.

It's a captivating concept, but it clashes with reality. Blockchain data can weigh gigabytes or even terabytes. Decentralized storage requires specific software and space for distributed data, isn't as fast as AWS, and often needs specialized browsers. Interacting with smart contracts costs money in cryptocurrency, and purchasing it isn't straightforward for first-timers. Then, factor in the complexity of setup, the need for specialized knowledge, ample free time, and the myriad of blockchains out there.

So, dApp developers started offloading the most complex parts for users to separate services, interfacing with them solely via APIs. Now, almost every blockchain has its API. This means dApps have to store settings for each network to cater to more users.

While APIs for distributed storage exist, hosting the dApp on them isn't efficient. Most solutions can't compete with web2 in speed and convenience. Hence, such storage systems are only used for tasks where response time isn't a priority. Even on Hackernoon, Arweave is used only for backing up articles.

What client-side technologies should be used for a dApp?

Well, if we aim to reach the maximum number of people in 2023 and 2024, then client-side web technologies are the way to go for creating a dApp. True, backend technologies like PHP and Python won't cut it, but any framework based on JavaScript/Typescript will do the trick. You can pick from the top 3 frameworks: React, Angular, or Vue.js. However, in my experience, Web3 components for Angular are rarer. My personal choice is React with Typescript. Of course, nobody's stopping you from using plain JavaScript, but why would you?

Further, to interact with smart contracts, you'll need some kind of library. The most popular ones are Web3.js and ethers.js. In my opinion, both aren't the most elegant. Their APIs frequently change, and code examples older than a year might not work straight away. My personal pick is ethers.js. Its structure feels more intuitive to me, and compared to Web3.js, the solutions tend to be more concise. In the documentation of various projects, examples are usually provided for at least these two libraries.

First and foremost, create an empty project (React + Typescript).

npx create-react-app project-name --template typescript

Navigate to the project directory.

cd project-name

Install ethers. This will ensure you have the most up-to-date version. Keep in mind that older examples from the internet might not work without adjustments.

npm i ethers

Which type of domain should you choose?

No, I'm not talking about top-level domains like .com, .org, and the like. I'm discussing whether one should opt for decentralized domains instead of traditional ones.

Yes, domains can be decentralized, too. Instead of the usual top-level domains, you might come across ones like .eth, .nft, .wallet, .crypto, and .go. Unfortunately, using them in popular browsers (like Chrome and Safari) without additional extensions won't work. Various companies have been trying for years to establish a domain zone that functions both in web2 and web3. So far, agreements have only been reached with less popular browsers like Opera and Brave. In these browsers, Web3 domains work.

So, if your target audience primarily uses the most popular browsers, the choice is clear: you need a Web2 domain. However, if your application becomes popular, domain squatters might purchase a domain with your project's name. When the Web3 revolution takes place and domains become accessible in all browsers, these squatters will likely demand a hefty price for that domain.

From this, it emerges that Web3 domains might be worth purchasing as a safeguard against squatters or for a hardcore audience using specific browsers.

Furthermore, such domains can serve as an alternative to unreadable wallet addresses. Instead of a complex address like 0x5301b241879e66EC45fD284D3D97A5C51472D6f3, you could use a domain like “mydapp.crypto” to send and receive funds.

Authentication: MetaMask's Dark Side

Currently, MetaMask stands as the most popular browser extension for storing people's wallet private keys. The private key is the most crucial element - "Not Your Keys, Not Your Crypto.” Entrusting such a vital component to anyone is a no-go, making it preferable to store it on one's device. MetaMask, in this context, allows users to keep their private key locally and doesn't share it with anyone, not even dApps, no matter how nicely they ask.

Despite its millions of users, getting started with MetaMask isn't straightforward. One has to go through a myriad of not-so-simple steps to set up an initial empty wallet. And then an equal number of steps are required to fund that wallet. I can confidently say that the next billion users will opt for a different solution. But as of now, it's the industry standard, and every dApp should support MetaMask.

But what if I told you there are over a hundred other wallets out there? It would be ideal to support those as well. But don't pull your hair out just yet! Solutions already exist that support all popular wallets. Typically, apart from browser extensions, these solutions also cater to mobile apps, significantly broadening the potential user base.

Examples of services you can use are Web3Auth and WalletConnect.

Blockchain Selection: Which Chains Are Best for dApps?

If you delve into the website of nearly any blockchain project, you're often met with bold claims: their blockchain is the fastest, most user-friendly, cheapest, and boasts millions of users now or will very soon. So, with this vast array of blockchains and ecosystems, how do you pick the right one?

In my view, the answer is clear-cut: if the blockchain is EVM-compatible, you're already halfway there. EVM, or Ethereum Virtual Machine, backed by the Ethereum Foundation, is a standard that any blockchain project can adopt. Critically, all tools for testing, debugging, deployment, linting, explorers, etc., will seamlessly integrate with this new chain. This means that if you create a dApp for one EVM-compatible project, it can, with minimal configuration, work across nearly all others. Sounds like magic, right?

Regarding non-EVM compatible projects, when developing dApps for them, you must have a clear rationale. Recognize that targeting these chains may limit your user base, offer fewer tools, and present more unprecedented bugs. The smart contract languages also differ, sometimes drastically. Here are the languages used for smart contract development in the top 20 capitalization projects: Solidity, Plutus, and FunC. Each of these languages is tailored specifically for individual blockchains. Grasping each requires considerable time, as their operational principles vary substantially.

Of course, you can architect your dApp to operate across a majority of these diverse chains. However, that's an advanced move and quite time-consuming. Straddling two worlds isn't always straightforward.

Let's dive right back into building our dApp with the newfound knowledge at our disposal. For this walkthrough, I'll be using the Gnosis Chain as our EVM-compatible blockchain. It's an L2 network that boasts cost-efficient transactions. For several years now, I've deployed a public notes smart contract on it, allowing users to create textual notes under their usernames. You can find it at this address: `0xf6b270136Da7F8a2113B93a3b9Eeaf5160C45bA0`.

To read data from this contract, you first need to instantiate a provider. A provider essentially acts as an RPC API to a specific blockchain node. The server delivering the data is already in sync with the blockchain network and provides the most up-to-date state.

const provider = new JsonRpcProvider('https://rpc.gnosischain.com/');

To fetch data from our contract, we'll create an instance of `Contract` from `ethers`.

const contract = new Contract('0xf6b270136Da7F8a2113B93a3b9Eeaf5160C45bA0', notesAbi, provider);

If I had linked my contract address with a .eth domain, then you could access the contract like this.

const contract = new Contract('myapp.eth', notesAbi, provider)

In this instance, we're passing in my smart contract's address, the provider, and the ABI (Application Binary Interface). The ABI ensures that the node can interpret state data from binary correctly. The ABI content is quite detailed for this article, so I've moved it to a separate URL.

Next, we need to prepare the username in the required format to use it for data retrieval:

const usernameHash = keccak256(toUtf8Bytes('igor'));

Then, you can fetch all the records I've saved in the smart contract like this:

const items = await contract.getNotes(usernameHash);

You can check out the entire code for `App.tsx` here.

Also, a quick heads-up: In the example, I'm using a free provider. If you're scaling a dApp with a significant user base, it might not be suitable. In such cases, you'd either want to set up your node or opt for paid providers from services like Alchemy or Infura.

Funding Your Idea Through Grants

In the fast-paced world of dApps, innovative ideas can often operate at a loss for extended periods. It's great if you've got a plan to turn a profit swiftly and a few thousand dollars to sustain yourself in the meantime. But if you don't, fret not.

Ideas with sound financial potential always catch the eye of venture angels and investors. But in the Web3 universe, innovation is additionally fostered through grants provided by major foundations such as Ethereum, Binance, and Optimism. These grants are often disbursed without any strings attached, either in phases or as a lump sum. Unlike venture capital, grants don't come with the business obligations typical of angel investors.

Projects awarded grants from a specific foundation should, in the long run, positively impact that specific ecosystem. The conditions and allocated amounts vary from one foundation to another, with grant amounts ranging from hundreds to hundreds of thousands of dollars. These are often disbursed in the project's native tokens.

To gauge if your project idea aligns with a particular grant program, study previously awarded grants and benchmark against your own.

Do you think you can deliver something similar or even better?

You're likely grant material.

But bear in mind that securing a grant can be a long process. Despite being a fantastic avenue to bring your project to life, be prepared for each stage to take weeks or even months. The stages you'll navigate are:

• Application Preparation. Many grant applications are straightforward. You'll be detailing your idea and showcasing your team's expertise. Put forward a compelling pitch about both the project and the team. Lack of experience in Web3 might reduce your chances of securing a grant.

• Project Evaluation. After submitting your application, anticipate a long evaluation phase. The higher the grant amount requested, the longer the evaluation. Typically, you'll receive an approval or rejection email. However, some projects might ghost your application. A month post-submission, don't hesitate to follow up on the application status. And feel free to apply to multiple foundations. Some projects might even qualify for grants from various foundations. Just be wary of potential conflicts of interest and clarify the feasibility of securing multiple grants upfront.

• Contract Signing. Post-grant approval, you'll engage in a phase of document preparation and signing by all committee members. While you can often start working before the contract signing, there's no guarantee that the contract will get finalized. The hold-up isn't always on the foundation's end; sometimes, sanctions might prevent a grant's disbursement based on your citizenship or residency.

• Project Acceptance. Acceptance of your grant can be slow-paced. Every committee member will thoroughly vet your solution. Prep a top-tier demo of your project since some members might have less technical knowledge and will evaluate based solely on your demo resources: demo sites and video presentations.

• Grant Payout. Post a successful grant review, the approval decision goes to accounting. Here, too, payments can get held up, especially if multiple people's confirmations are required. Often, these individuals are engaged across various projects, not just grants.

  
  

To obtain a list of nearly all projects offering grants, search for "List Web3 Grants" online.

As you can see, if you have experience in web2 development, not all concepts in web3 will be clear at first. Many things might raise questions. Nevertheless, this article calls for a part 2, where we could build a full-fledged application using different networks, with the capability to store data in a decentralized manner, as well as interact with smart contracts either at the user's expense or the developer's.

See you in the next part!