Building a production-ready Ethereum DApp from idea to final product — The smart-contract (Part 1)
Introduction
This series is targeting seasoned developers who want a series of articles that revolve around coding best practice to create a production-ready DApps. The developer who has a good understanding of what Blockchain is and how Ethereum smart contract works.
If you need to gain more knowledge about Ethereum and blockchain, check the following post and familiarize yourself with the concept thoroughly.
There are a lot of fantastic guides out there that talks about Ethereum development but usually fall short to show the full picture from the idea all the way to the front-end, back-end and Smart Contract with all of them working together, and all settings and configurations around all that.
Even though I’m targeting a production-ready Ethereum DApp, this tutorial is in no mean the full picture, and won’t guarantee to create a secure app as a security audit would still be needed, and you also need to do your research. But at least I hope to give you enough pointers to know where to go afterwards.
If you care about getting more solidity code and you’re comfortable with the rest, then head to Cyrptozombies.io or follow this guide or that guide, these give an excellent idea of what you need to do.
This series is not going to dig into the specific details of Solidity language or deep dive into the JavaScript and Node.js code, but instead on how to take an idea from the origin and orchestrate the work needed to make everything work. However, if you need any help or more explanation, you can let me know in a comment below.
These posts are going to be short and sweet. It will also be progressive with things getting added as the series goes on. If it attracts enough audience, I can create another series of standard applications like ICOs, Sidechains and more…
Table of contents
This series is separated into 3 layers:
- The smart-contract — Create the Survey smart-contract
1.1. From Idea to a business plan — (You’re here)
1.2. Setting up development environment with Truffle
1.3. Creating the smart-contract the TDD way
1.4. Testing Solidity Code on TestRPC, Local Ethereum chain and Testnet - The Backend — Server side Ethereum development
- The Frontend — Client side user interface and wallet integration
The idea
As part of my dissertation, I need to conduct a survey to collect information, and I always hit the problem that people would like to be incentivized for the time they spent — wasted — filling that survey. It would be good if you can compensate them. But wait you’re looking to pay 10s or 100s or even 1000s of people, that would cost a lot of money, wouldn’t it!
Then it hits you…
A raffle, a raffle is a good option, but then people will start question the authenticity and randomness of that raffle and whether or not you’ve given it to someone you know to save yourself this few bucks!
To solve that problem, you design an excellent survey rewarding DApp to assure authenticity to participants and also to deter away people who don’t understand what Ethereum wallet mean ;)
The user(s) journey
The user journey can all be elaborated in the following sequence diagram
There are 3 actors of this DApp:
- Survey Creator
- Survey Participant
- Survey DApp (The connection between both parties)
Survey Creator’s perspective
- The user Goes to the DApp
- The user Enters the reward and on clicks on Create Survey Link
- The user is Prompted from Metamask to confirm Transaction (Creates smart-contract instance)
- The user is filling the survey link and add integration to survey monkey (out-of-scope)
After the survey is done, the Survey creator can close — announce it is finished — and receive the winner’s details.
Survey Participant’s perspective
- The user navigates to the Survey DApp.
- The user clicks on to take the survey link.
- The user fills in the survey.
- The user clicks on Finish survey.
- A popup comes that prompt the user to enter his ETH account address to claim his/her reward later.
- The user puts his address.
- A few seconds later the user gets a number to save.
If the participant is the lucky winner, then the participant gets notified, which he/she can withdraw their money into their wallet.
In the next part
With the above you hopefully got the idea of how the DApp is going to look like, in the next part we will see how to create your development environment and what kind of problems you’d usually face setting it up on different Operating Systems, and how to overcome them.
