A month ago, I finished writing the Ethereum development walkthrough tutorial series, with the last part being a how-to make a DApp. While it concluded that tutorial series well enough and could serve as a solid starting point, I still thought it could be far more interesting to make a tutorial on how to make a full DApp, from start to finish, and share not only the code, but also the experience to get it running on the Ethereum’s main network.
You can find that DApp here, its github repos here and here. It’s on all accounts a real DApp deployed on the Ethereum main net, and we’ll try to dissect its development together.
As a project, making a decentralized application on Ethereum is not really different from making a classic, centralized one, beside the fact that more care should be put into planning and implementing the smart contracts that power the DApp.
So the first thing we need to come up with, is, of course the idea.
What will we create
On this point, everyone has a different way of coming up with an idea for a project. For me, a project I always found funny, and it always remained in the back of my mind, is The Million Dollar Homepage, a website from 2005, where the owner, Alex Tew, sold every pixel in a 1000 x 1000 pixels canvas on his website for 1$.
So my idea was, why not try to reproduce it on Ethereum? It should be fun and small enough to be doable for a tutorial. Our DApp could sell each pixel not for a whole Ether, it wouldn’t be realistic, but let’s say 1/1000th of one.
Starting the development process
For a project as small as this one, writing down the milestones that needs to be achieved is enough to get started, anything more elaborated would require more documentation and throughout designing and modeling.
The idea in this DApp is to sell pixels in 10 x 10 parcels, since individual pixels are too small to be seen easily. Tracking these parcels can be achieved by non-fungible tokens, commonly known as ERC-721 tokens, since each parcel is unique. We could obviously have a token keeping track of each individual pixel, but because of the performance limitations of the smart contracts, we have to make as much optimizations as possible.
Each token owner in our DApp should have the possibility to modify the pixel colors, add a description or a link to their parcel, and could resell their parcel.
Doing it the MVP way
In order to not waste development time making the perfect product, and check our assumptions early on, we will make just the most important functionality first, which is allowing users to acquire pixels parcels, and modify their colors and description.
There are people who just set up a text-only landing page to see how many users it attracts, but let’s not be that lazy and actually create a functioning prototype.
The smart contract(s)
Having your core features in mind (for some it’s just generating a bunch of tokens and selling them) you should design your smart contract(s) in a way that you could enhance or upgrade them in a practical way. There isn’t an industry standard or a best way to achieve that but a bit of research will return a few potential solutions implemented by other projects. You could pick up one and adapt it to your needs, or come up with a solution more suitable to your project.
In this project, I preferred to implement all the functionalities directly in the smart contract. Since I already had the base code for an ERC-721 token from another project, I just made some necessary modifications to it, and added the ability for the owner to modify the data of the token, and the possibility to sell their token.
I don’t think there will be any needs later that would require updating the smart contract, and if someone, for example, wants to add a functionality like renting their parcel, they could use another smart contract to achieve that.
Also, I didn’t put any pause functionality into the smart contract, or a mechanism to change the smart contract if something goes wrong, because my second goal for this project, is to show off what differentiate developing on the blockchain from a classic centralized application for anyone who’s new to the blockchain and discovers it through this project.
It’s the wise choice to have a safety plan if shit hits the fans, but I wanted to take that risk with this project by stripping myself from any power over the deployed smart contract.
Writing a good test suite is also important, since you can’t risk to follow the write-code-then-wait-for-bugs-during-production methodology with smart contracts. You need to make sure as much as possible that your code does only what it should and nothing more.
While I wrote the smart contract completely since it was short enough that I didn’t want to waste more time finding the best way to upgrade it, on the web front-end, it’s definitely possible to go down the MVP road.
The functionalities I implemented are: showing the pixels grid, allowing users to acquire the parcels, and allowing them to modify the data for it. One could say that the last functionality crosses the first iteration of making an MVP, but again, let’s not be lazy asses.
Of course the other functionalities exists on the smart contract, and could be added anytime to the front-end, but we want to confirm our assumptions first, and make sure that there are people who want to use our product.
Deploying the DApp
Now, that our MVP is developed and ready, we need to deploy it.
The smart contract
To deploy the smart contract, we need ether for gas, to acquire ether, you could buy it on a platform like Coinbase or Cex.io, but it will probably take days or weeks depending on the platform for your order to go through.
Another solution is to buy ether from a seller nearby, by finding them on a platform like LocalEthereum or some Facebook group. Yeah, it really looks like buying drugs, and it definitely doesn’t help cryptocurrencies shady image.
After you got your ether, the easiest solution to deploy a smart contract is to use Remix and MetaMask, but I preferred to use a light geth node and truffle.
For the front-end, I used Github websites, it’s free and makes the code source available openly, which is what we want.
Well, as I said on top, a DApp is just like any other software, the same rules apply to it, it’s great to create something, but if no one knows about it or try it, it’s useless.
Now, this is a point I can’t help you on, because I’m totally oblivious to taking the word out for a project, I could not sell sunscreen to a sunburned guy. So you would need to rely on some PR magician to attract users to try your DApp.
The source code is available on Github.
The smart contracts are here:
While the repo for the web front is here:
Obviously, even the functionalities I implemented on the front end are incomplete and need more polishing, but since we are going the MVP way, it’s not necessary to enhance them now. I can also see some performance problems that could arise if a lot of parcels are acquired, but it’s not the case now, so there is no need for early optimizations, until we see how the DApp performs during production.
Apart from this being a tutorial, I really want to have this website as a real, working, demo project for people who are just discovering the blockchain, and Ethereum’s possibilities, if the DApp gets any attention, one of my goals is really to put an accent on introducing decentralization to newcomers, and of course, keeping this project as an ongoing tutorial and field report of how the DApp is surviving on the blockchain.
So, don’t hesitate to take a look at the deployed version of the DApp, maybe acquire some parcel and link it to your super, ground-breaking DApp, or advertise your scammy ICO, or just to leave your mark on it, it will be helpful to have anything of value to write in a follow-up tutorial.
And of course you can find me on twitter @dev_zl.