I started building MarrySign, a crypto-marriage app, during the Chainlink Hackathon Fall 2022 because I wanted to give any couple regardless of their gender, location or any other factors, a chance to register their union quickly and transparently from the comfort of their homes. Now after the hackathon, I continue working on the project in my spare time.
Since it's the first web3 project I'm building, I'd like to share my learnings.
I wish I could explain it briefly ;) But let me try to use familiar examples for that...
Blockchain is a distributed database with an acknowledgement mechanism, like in MongoDB, and stored procedures, like in Postgres, directly connected to a payment gateway, like Stripe, but for Crypto.
For the Ethereum network, the “stored procedures” (functions) are grouped together into a “class” (contract). The contract code is written in the Solidity language which resembles a mixture of JS and Go.
If you once deployed your Solidity contract to the blockchain, you can't change its code. It means that if you find a bug in it, you can't deploy a hotfix. You will need to deploy an updated version to a new address leaving the old contract and user data intact. It adds some challenges, for example migration of user data from an old version of the contract to a new one. There are solutions for that but it's not one button click.
So the idea is to deploy good-quality code to production, well-tested and well-documented.
Taking that into account, I test my Solidity contract with the Hardhat framework, document it properly to generate human readable docs automatically with solidity-docgen. To format my Solidity code, I use solhint and solhint-plugin-prettier.
You pay fees (aka gas fees) for writing to the blockchain, but read data from the blockchain for free. However, it's not guaranteed that your read-only function will return results if it exceeds some network limits.
The Hardhat framework lets you estimate gas fees for running your functions. Not sure if it's 100% accurate but it helps identify heavy functions.
There are also solutions for gas-less payments. It's when the contract creator pays fees for their users through a special gas station, for example Ethereum Gas Station Network.
Since the price of a mistake is normally high on the blockchain, there are a few test networks which you can use to test your contract without paying gas fees on the Ethereum mainnet.
I use the Goerli Ethereum network. People don't like it for some issues but other options are not widely supported yet.
The UX of some tools and services is not yet ideal, so more and more companies are focusing on web3 UI/UX. I think good UX is a competitive advantage today. I personally liked presentation by Rahat Chowdhury from the Polygon team with ideas on how to improve web3 UX.
I heard stories about contract developers forgetting to implement a withdrawal function and having to lose their earned funds. So if you're going to collect fees from your users or receive any funds to your contract address, make sure you add a withdraw function right from the beginning.
Web3 and Hardhat starters:
Looks like current crypto-winter doesn't slow down web3 progress because a lot is going on in the area actually.
- There are growing Discord groups for almost every blockchain project.
- There are many hackathons, dedicated to a blockchain protocol or network, that are happening now.
- The Techstars accelerator partners up with big players in the area to help web3 and blockchain startups grow.
To sum up, developing for web3 has its challenges and opportunities, so when you get familiar with tools and services available and discover best practices, you can develop something really new, something disruptive.
I originally wrote this post for my blog but after receiving good feedback decided to share with the dev.to community. Hope you guys like it.