Ethereum is not meant to be a platform to build esoteric smart contract applications that require a STEM degree to understand, but it aims to be one pillar of a different architecture for applications on the world wide web. With this post we will try to elucidate how this can be done and give some basic examples on how to start building a decentralized app.

Who is this for?

This text is intended at those who have a basic understanding of web technology and how to build a simple javascript and html app, and want to convert these skills into building apps for the Ethereum ecosystem.

How can apps run without servers?

Currently servers in web apps do much more than what they were originally intended to. Besides serving static web pages, they also keep private information, handle user authentication and deal with all the complicated ways in which data is analyzed and saved. All the user computer does – a device which would be considered a super computer when the web was invented – is to load and display that information to the user.

Current server models

Instead, a more decentralized architecture would allow a much more modular approach, in which different machines and different protocols would handle specific tasks, some on the user’s side and some in specialized machines deployed on a peer to peer network. Therefore all the Data logic (what gets saved, who saves it, how to solve conflicts etc) is handled by smart contracts on the blockchain, static files are served via Swarm and realtime communication over Whisper. The user device keeps the user authentication and runs the application interface.

Doing this would remove the danger of data breach and attacks as there are less single nodes keeping tons of unencrypted data, while also removing the load and cost of serving apps by distributing it across the network. Since all those protocols are decentralized, anyone can connect to the network and start providing a specialized service: if the user is browsing from a powerful laptop, for instance, they can also serve static files to network neighbors.

Decentralised Server models

A decentralized architecture also encourages innovation: since the interface is detached from the data, anyone can come up with a new interface to the same app, creating a more vibrant and competing ecosystem. Arguably, one of the most interesting and innovative periods in Twitter history was when it served mostly as a central data hub and anyone could build their  Twitter Application.

See it working

If you want to experiment with the app before learning it, we recommend you download Mist and read our introductory tutorial to how to install the app and run it. If you just want to see the whole app instead, you can download it directly from the Stake Voice Github repository.

Stake Voice running on the Mist Browser

Let’s get to it

We are going to build a very simple application called “Stake Voice”. The idea is to allow ether stakers to vote on anything they want, and the app will tally the total ether balance of all those who agree or disagree with the statement.

The app underlying contract is written in Solidity, a javascript-like language and is very simple:

contract EtherVote {
    event LogVote(bytes32 indexed proposalHash, bool pro, address addr);
    function vote(bytes32 proposalHash, bool pro) {
        if (msg.value > 0) throw;
        LogVote(proposalHash, pro, msg.sender);
    }
    function () { throw; }
}

The first line sets up the contract name and the second creates an event called “LogVote”, which will output in the log the following:

• a hash of the proposal being voted on
• if the voter agrees or disagrees with it
• the address of the voter

The function “vote” will then fire the log, which the application later will count. It also has a check that no ether can be sent accidentally. The “anonymous”  function is executed when any ether is deposited on the smart contract and will then automatically reject it.

If you want to learn more about coding in Solidity we recommend you start on the ethereum solidity tutorials, read the  official documentation page and try it on your browser using the online compiler.

That’s essentially it: you choose a hash, choose a side and execute Vote(). So how does this translates into a polling app?

Serverless Architecture

Following the principle of KISS, we are doing the minimum product possible that is still usable, meaning we won’t be using databases for storing proposals or using any feature that requires anything other than vanilla javascript and pure html.

So we will use the URL of the app itself to keep the proposal text, and we will use that to display it to the user and generate a hash that can then be used to check the votes. The users can use social media to share which proposals they want to debate or simply use direct links.

// On the initial startup function:
proposal = decodeURI(getParameterByName('proposal'));

// 

Start with basics

So grab your favorite html framework and get a basic website on your local machine and open it on Mist. All pages in Mist have access to a javascript object called web3 which will where you will be working the most.  First thing we need to do is check if web3 is present or not:

Function init() {
...
if(typeof web3 == 'undefined') {
    // Alert the user they are not in a web3 compatible browser
    return;    
 }
 

Some application developers might want to load their own web3 object, to guarantee forward compatibility. To do that, just add just before