Introduction
DApp指的是Decentralized Application，可以簡單想成是部屬在區塊鏈上面的應用程式。使用者可以透過在網頁上連結錢包(e.g. Metamask)並與網頁互動，進而去跟整個區塊鏈上的資料、帳戶進行互動。
DApp跟傳統的Web application有甚麼差別呢？我認為差別最大的就在於傳統web app的後端通常把程式放在Cloud server(e.g. AWS, GCP, Azure)、或是自己架的server上面運行。因此，一般使用者無法知道一個網站的後端背後進行了哪些動作，只能知道最後的結果而已。而DApp的後端則是部屬在區塊鏈上面，而在區塊鏈上的資料都是公開透明的，因此使用者可以隨時查看區塊鏈上的轉帳紀錄(transactions)、智能合約(program)來得知所有結果。
舉例來說: 小名在網站上按了轉帳按鈕把100元轉給小楊，等待一段時間處理後發現自己錢包少了100，而小楊通知小名說他收到了100元，這樣雙方都知道轉帳成功，但是他們不知道跑轉帳流程的程式背後的邏輯怎麼運行的。而若是這個網站是一個DApp，則小名跟小楊可以查詢區塊鏈得知轉帳的整個流程，轉帳的錢有沒有中途被亂用等等。
Start to build first DApp
在了解DApp後，便可以開始動手實作了。若有網站前後端開發經驗的人，相信會很快地就上手，因為最大差別只是在後端換了一個方式寫而已。
現在有許多Framework或是Tool可以快速建立一個Dapp，像是
- Truffle
- Hardhat
- Scaffold-eth (Hardhat + React)
- Brownie (Python based environment)
- Remix (Online smart contract editor)
詳細資料可以參考以太坊的文件。
使用Framework的好處在於，跟著官方的Get startted走，並且下幾個指令後就能跑起來一個簡單的DApp了。但若是想要更進一步的開發屬於自己的DApp，則還是要對Framework本身及相關的開發工具有所了解。
Find suitable development environment
一開始我選擇Truffle當作開發環境，因為覺得Truffle的操作很直覺，而且利用truffle box可以快速地建立好一個React + Truffle的開發環境。然而後來跟著官方文件的React Truffle box進行操作時發現文件裡的React還是用舊的寫法(Class Component)，查了許多文件、影片跟試了不同的Truffle box後都還是不太順利，因此一度換到Scaffold-eth。
Scaffold-eth在建立環境也是很直白，打開三個terminal，一個負責跑Local blockchain，一個負責跑React webpage，一個負責部屬智能合約便能順利跑出一個Dapp。然而Scaffold預設的Dapp網頁內容太過複雜，我看了不知從何改起，也擔心隨意亂改可能會影響Frontend跟Blockchain的溝通，因此最後決定自己改寫官方的範例Code，把Class component的寫法換成Functional component的寫法。
First tutorial for building DApp
一開始蠻推薦Truffle的官方教學，在這裡面可以學到如何從零開始建立一個Pet shop的Dapp。比較重要的觀念像是
- Smart contract的開發、測試等等
- 如何在前端連接使用者Wallet，並透過Web3.js與Blockchain溝通
在教學中，若是遇到Ganache跟truffle無法順利溝通的情況下(我用WSL 2試了一些方法都不太順利)，可以安裝ganache-cli，並開啟一個terminal 跑指令ganache-cli，一樣可以在本地跑起一個localhost blockchain，就不需要Ganache GUI了。
Smart contract development: Solidity
在了解整個開發流程後，便可以開始寫後端的邏輯，也就是智能合約了。這裡很推薦一個網站 Solidity By Example，這裡面從Solidity的基本語法(variable, function, loop …)到實際的Application(Wallet, Auction, ERC20…)，甚至連Layer 2 (Payment channel)以及Hack (常見的智能合約漏洞)都有。我自己在寫的時候也很常看這個網站，但如果要詳細的解釋的話還是得上網搜尋。
若還對要寫哪種Dapp沒有想法的話，可以從一些常用的應用開始，像是Solidity By Example網站裡的Auction、ERC20等等。
如果想確認自己寫的智能合約的邏輯是否正確的話，建議可以先寫測試檔，測試檔的寫法可以參考Truffle的官方教學(Pet shop)裡面有提到。寫測試檔好處是可以重新確認自己的智能合約邏輯，而且在開發上也會比較快。如果不寫測試檔的話就會很麻煩，想Debug只能
- 編譯並部屬智能合約到鏈上
- 開啟前端程式並操作
整個流程會被拖得很長。
我建議用Javascript寫測試，因為自己原本用Solidity，但想要測試轉錢給智能合約時卻不知道如何測試，也查不太到相關資訊就改用Javascript了。
最後，因為智能合約的程式碼會在鏈上被執行，因此在寫的時候必須特別注重兩個事情: 安全性及效能
- 安全性: 由於部屬到鏈上每個人都可以看到妳的程式碼，因此在寫時必須注意安全性或執行權限。E.g. 某些重要function只有Owner才能進行操作。
- 效能: 在鏈上執行智能合約並非免費，而是要付Gas(類似手續費)。如果執行的東西愈複雜，Gas會愈高。E.g. 要存取某個使用者的資訊，且未來會在查找相關資訊時，使用mapping來存資料會比使用Array還要好，因為在查找時比較有效率。
Frontend Development: ReactJS
寫完智能合約後，再來要寫前端。前端最重要的就是Wallet connection跟與區塊鏈溝通的Library - Web3.js了。
關於Wallet connection，可以使用web3-react這個套件，簡單幾行便能連接到使用者的Wallet了。這裡推薦這篇medium文章來快速入門。
透過Web3.js，我們可以拿取鏈上的資料(Block height, account info…)，也可以與鏈上的智能合約進行互動。如何與智能合約互動一樣可以參考前面Truffle的教學。
比較要注意的是若使用send()來呼叫contract method，則回傳值是Transaction hash，若要獲得contract method的回傳值則須使用call()，但該method必須是只有做讀的動作。如果想獲得一個有讀有寫的Contract method的回傳值，則可以用Event Log的方式，在method裡Emit event，前端則去監聽該event有沒有發生。
Deploy DApp to real world
在本地都順利開發完成後，再來最重要的就是把整個Project部屬到真實世界上了！在部屬前可以先考慮要部屬到哪裡:
- Smart contract: 建議先部屬到Testnet(Ropsten, Rinkeby)，並且上網搜尋Testnet的名字+Faucet來獲得Ether，以方便部屬合約以及與合約互動。
- Frontend React: Frontned部屬的方式有很多種選擇，像是Heroku, Github Page, AWS 等等，除此之外似乎也可以部屬到IPFS上面。
前端的部屬方式我選擇用Github Page。詳細的部屬方式可以參考這篇文章。但這篇文章是手動部屬的，如果要做CI/CD的話可以使用Github Action，在把code推到Github上時自動部屬。
Summary
這篇文章暫時先寫到這邊，之後想到會再補充，若參考以上的文章遇到問題時也歡迎一起討論。在最後附上我在去中心化應用實務課堂上做的期中專案簡報、程式以及網站。
Appendix: Ethereum Development List
最後推薦一個網站ethereum-developer-todo-list，裡面包含了開發Ethereum常用到的許多工具，非常詳細。
