Hitchhikers guide to Dapp Prototyping.

Published Mar 21, 2018Last updated May 23, 2018

This tutorial mainly stems from a personal journey into the world of DAPP development. I hope it will help you out to get a better grasp of the infrastructure and tools needed to successfully build and deploy DAPP’s.
For this tutorial you’ll need to have at least a basic understanding of the following subjects:
Git, Homebrew, NPM, Ethereum
React, Testing, Web3
Testrpc, Truffle (and react-box), Solidity

If you don’t feel confident in one of the mentioned subjects and technologies I suggest reading the docs / following the tutorials / watching the video’s in the attached url’s (any suggestions for better resources than the attached url’s is highly appreciated!).

This tutorial will be broken down in 4 steps and leaves you with a DAPP and an infrastructure to improve and update your DAPP. I’m leaving out the step of deploying anything on a production blockchain because my experience is too little to grasp the possible implications of deploying anything at all on the Ethereum production blockchain.

Quick note: this tutorial is specified for OSX. Please let me know in the comments if you would like to see the instructions translated for different operating systems.

If you have any remarks, feedback or questions, don’t hesitate to leave a comment or contact me.
Happy building!

Part 1: Setting up the development environment

First and foremost we need a stable and well functioning local development environment. To start this off we’ll install a bunch of tools like npm and truffle, and we’ll try and set up a sustainable and well functioning development cycle.

You can skip whichever paragraph you’ve already finished but I suggest reading them all anyway (and in the process, help me improve them).
Installing Node and NPM

If you haven’t installed node or npm start with installing these. We’ll use homebrew to install and manage node and npm, so we’ll start with installing that:

Download homebrew:
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Update brew and add to PATH:

brew update
export PATH="/usr/local/bin:$PATH"

Install node and npm using brew:

brew install node

Installing Truffle and Ethereumjs-testrpc

By now we can install truffle and the ethereumjs-testrpc using npm:

npm install -g truffle 
npm install -g ethereumjs-testrpc

Setting up a new repository containing truffle-react

First off: create and cd into a directory where you want to develop your new project.

mkdir hitchhikers-dapp

Then initialise a git repository of your choice and now, run:

truffle unbox react

To unbox the truffle-react box, and we’re ready to test if our setup is able to run.

Starting up the development environment

To start up the development environment, first we’ll have to run testrpc in a separate terminal for our dapp to be able to connect with.

testrpc

Now that our testrpc is up and running we can compile and migrate our truffle contracts, and start the DAPP.

truffle compile
truffle migrate
npm start

Notice that the last command gives us a url of http://localhost:3000 to check if our DAPP is running. Please make sure you have Metamask disabled when you open your browser because it will inject it’s own web3 hook.

If all goes well your browser should open on localhost:3000 and this interface will meet you (check if the stored value is 5):

A quick overview of what we got so far

First and foremost we’ve got two contracts in the /contracts directory. The beating heart of our DAPP. There’s a migrations contract and a contract called SimpleStorage.sol. We’ll get back to that migrations contract later and start with looking a the SimpleStorage contract.

All this contract does is manage the state of a single unsigned integer storedData, so it’s nice and simple.

pragma solidity ^0.4.2; 
contract SimpleStorage {  
    uint storedData;   
   
    function set(uint x) {
        storedData = x;  
    }   
    function get() constant returns (uint) {
        return storedData;  
    }
}

There are two functions working on the storedData uint and this contract describes an important difference between returning state and manipulating state. The EVM is built in such a way that only the manipulation of state costs gas, and getting the current state is free. To indicate that a function doesn’t adjust state constant is added to the function definition.

function get() constant

Notice that this contract doesn’t set any restrictions on who can adjust the state of the storedData, or on the value of storedData itself. So the only thing we really have to test is if we can adjust the state of storedData and if we can read it. Which brings us to tests!
Running the tests

To make sure you don’t waste too much time rewriting the user interface components I highly recommend to start with testing your smart contracts first, then writing web3 tests and only then start with connecting your contracts to a user interface.

Please don’t skip this paragraphTruffle ships with a testing interface, and Truffle react already wrote our first test contract using this interface for us. The contract is called TestSimpleStorage.sol, and is located in /test.

pragma solidity ^0.4.2;
import "truffle/Assert.sol";
import "truffle/DeployedAddresses.sol";
import "../contracts/SimpleStorage.sol";
contract TestSimpleStorage {
  function testItStoresAValue() {
    SimpleStorage simpleStorage = SimpleStorage( DeployedAddresses.SimpleStorage());
    simpleStorage.set(89);
    uint expected = 89;
    Assert.equal(simpleStorage.get(), expected, "It should store the value 89.");
  }
}

First off, it imports the Assert contract and the DeployedAddresses contract shipped with Truffle to provide a method for testing the functionality of a deployed contract.

Second, it imports the Simple storage and tests the state management of the contract by setting the state to 89 and then checking if it returns 89. This covers all the functionality we need in the contract.

You can also write the text in javascript (as in /tests/simplestorage.js), and my suggestion is to use these to make sure your contracts also work with your web3 interface in a later stage before we start implementing the actual user interface.
Last but not least, we’ll try and run the tests:

// Runs Truffle's test suite for smart contract tests.
truffle test

By now we’ve setup, explored and tested our local development environment and I hope you’re still there to go to the fun part. Writing & testing our own contracts!

What’s next?!

In the next couple days I’ll write the follow up parts of this tutorial and release additional repositories with example code to get to a full fledged DAPP running on a public testnet.

Part 2: Writing & Testing your contracts
In this part we’ll discuss how to write contracts, and test them thoroughly, before connecting anything to a user interface using web3.
Part 3: Building the User-Interface
In this part we’ll have our contracts set up, and we’re ready to connect them to an interface that allows humans to use them.
Part 4: Deploying & Migrations
Last but not least: you have everything running and you’re ready to deploy.

More will follow soon!

Discover and read more posts from Kasper Meilgaard
get started