Beyond Solidity, The Language

I think I was familiar enough with the syntax of the Solidity language to write any logic of smart contracts running on the Ethereum platform, what's next?

I would like to persuade a career in the DApps Development, I think one need to posses the following skills in order to play the role as professional Blockchain Application Developer:

Unit Testing

Regardless of whether we are practicing Test-Driven Development (TDD), we should write tests for the smart contracts to ensure correctness. Writing Tests in JavaScript from Truffle documentation is a good reference for that matter. The @openzeppelin/test-helpers is a great library to simplify your testing code and you can refer to Testing Time Dependent Solidity Smart Contract Functions using OpenZeppelin Test Helpers for sample code. The solidity-coverage is a good tool on test coverage report.

Security

As smart contracts running on public networks,involved monetary transactions and the source code is most likely open source, it is prone to security attacks. Hence, security aspect is the most important aspect of smart contracts after correctness. I think the best source on learn to write secured codes is start from security section of the Ethereum documentation. Learn by playing the Ethernaut game and reuse well-tested @openzeppelin/contracts library and learn from well-documented million dollar mistakes. Lastly, I think it is best to incorporate code analysis tool such as SmartBugs into automated build pipeline. Thanks to Ender Phan, a security engineer published an article regarding automated pentest. 

Gas (Performance) Optimization

As execution of smart contracts in Ethereum Virtual Machine (EVM) causing money (known as gas), it is best to write optimize code for the core features or commonly use functionalities of the DApps. I just find out that we can optimize the codes beyond Solidity by using Inline Assembly. Also, I heard of eWASM, the Ethereum client with Web Assembly runtime, which ultimately will replace EVM. After some research, I think it is still in infancy stage and currently not much progress. But that doesn't stop us from getting ready and trying it out with Compile Solidity to Web Assembly with SoLang or Deploying a WebAssembly smart contract on Oasis Ethereum.

Updated on Sep 16: The Unit Testing, Security and Gas Optimization brought together with a build automation pipeline, please see the Solidity and Truffle Continuous Integration Setup with GitHub Actions to find out more.

Integration

No application is an island including DApps, it need to integrate with external entities to function well, for example:

• Scheduler: Ethereum Alarm Clock
• Interplanetary File System (IPFS)
• The Graph API
• Chainlink

Thanks for reading. Do you have anything to add?

Kickstart Your dApps Development with the Ethereum dApps Next.js Boiletplate

Follow up the previous blog post, I plan to build Fluwix as DApps using Flutter. After search through the Internet, the harsh reality kick in: Most DApps in the market, sample codes and DApps-related libraries and frameworks written in JavaScript and as ReactJS components. 

It is not impossible to port those libraries, frameworks and components to Dart and Flutter, but it is really a big undertaking. So, I picked up ReactJS and found NextJS, the React Framework for Production. I also realized that the codes in the Learn Ethereum book is outdated, hence I took the Udemy's  Master Ethereum & Solidity Programming From Scratch to have better understanding of the latest version of Solidity.

To keep the long story short, the outcome is the Ethereum dApps Next.js Boiletplate.

The creation of the Ethereum dApps Next.js Boiletplate is inspired by a truffle box known as truffle-next with the following improvements:

• TypeScript support
• WalletConnect integration
• Better UI with Chakra UI
• JQuery HTML example (without React)
• Github workflow to run truffle test on every git push

It is tested with MetaMask Chrome extension and Android. I think it is good idea to test out the dApps yourself before you continue reading further.

The dApps is interacting with a Greeter smart contract that running on Rinkeby testnet, hence you need some ETH in your wallet. If you don't have any, you can request some ETH from Rinkeby Faucet.

You might wonder why I still go ahead to build this boiletplate as there's great abstractions such as useDApp, web3-react, web3modal, etc. These libraries are great, but they are fall short on the following aspects:

• Customization. To fully customize a functionality, we need to stick to low enough abstractions such as @metamask/detect-provider, web3 and @walletconnect/web3-provider.
• To avoid abstraction over abstraction. For example, it would be hard to fix a bug on useDApp and web3 which has inter-dependency. I think it is far better to build the abstraction specific to DApps ourself from the base libraries.
• To upgrade the base libraries to the latest version without depends on the abstraction. For example, web3modal still using @walletconnect/web3-provider 1.3.x when the latest version is 1.6.x.

If you are interested to look into the code and run it in your local machine, please check out the git repository hosted at https://github.com/limcheekin/eth-dapps-nextjs-boiletplate. Feel free to fork the repository and send me pull request.

I hope to hear from you soon! :)