DApp development is not popular. At all. It only accounts for a tiny fraction of development projects currently. One thing I can’t understand is why so many front-end developers are turned off by dApps. These decentralized applications aren’t as difficult to program as some people think. In this article, I’ll show you some simple tricks in front-end dApp development.
Nowadays in modern application development, I see a tendency to move as much application logic as possible to the browser. Servers are for providing nice APIs, connecting with databases, and storing data. Servers don’t need to push whole templates filled with data anymore. Rendering can happen inside a browser. As demand grows for more dApp development projects, it means more work for front-end developers like me.
In the current development process, there is always a server part and a client part. Let’s say I need to write a single-page application (SPA). The framework doesn’t matter — it can be React, Angular or Vue.
I often start to write an application before the server part is ready. At the beginning, I start by mocking data. We can create a simple node app to handle the requests serving basic JSON files as a response or use external services for that. Once the back-end work is done, I abandon the mocks and integrate with real endpoints with the ability to easily switch to the mock version changing ENV variables.
Centralized databases store most of the data we produce and send. There is always a server somewhere. It can be an AWS virtual machine or even a computer in the basement. It doesn’t matter, in most cases, though, some centralized entity stores our data. What’s wrong with that? Well, it means we have to trust the company which handles our data.
Everything is fine if the company properly secures our data, and they’re backing it up in a different physical location. In the case of some cataclysm, we will not lose our data. However, In real life, we are not always in such a perfect situation. The history of the internet is full of situations when some hosting providers removed data accidentally with no option to restore it.
Blockchain to the rescue
With blockchain technology, there are fewer client-server architecture boundaries. In some cases, we can remove the server totally to be fully independent. In others there is small server code part as an addition to the blockchain node, to store data without any delays and with immediate access. Blockchains copy data and distribute it between all computers in the network. Even if a few computers crash, the data will still be there.
I’m not a blockchain developer should I care?
Yes! You can still work with the technologies you love such as React, but in place of a server, there will be a blockchain application.
But without a traditional server how it is even possible?
In some cases, it is possible to remove a traditional server. Instead of calling our server with simple AJAX request we will be calling any of nodes creating the blockchain network (via web3 API). In the next paragraphs, I’ll show you how.
DApp development: connecting to the blockchain
The first thing to do when you start a dApp development project is to download web3 library. It’s available in npm. You can attach it to your package.json like any classic dependency. It exists in 2 versions 0.* which is a stable version with callback based implementation and 1.* version which is currently in beta but gives a fully Promise-based interface. Hopefully, a stable version will launch soon.
The simplest scenario is a publicly-available website which is just reading data from a blockchain. This is a very common use case for ICO projects. There is a website that displays specific information like ICO start/end time, ICO phase dates or value of our token in ETH etc. Such methods are always publicly available and don’t require any operations on your wallet.
Assuming you have web3 in your dependencies you can simply import it in your module:
Next thing to do will be to initialize your web3 object. To do that you need web3Provider. For simplicity in my example, instead of hosting my own blockchain node, I used Infura, which is a free blockchain infrastructure provider. In this scenario, I use the rinkeby test network.
I have an instance of Web3 object initialized. Next step will be to create a contract instance.
You may notice in the above lines that something is missing. To create a contract instance you need contractAbi and contractAddress. A contract address is a unique ID in the network in which our contract deployed. It takes 40 bytes of data and always starts with ‘0x’
Contract Abi is json which represents all methods in our contract. It determines how we should call specific methods what parameters are required and what we will receive as an output.
In the example above, the Abi json has only one function ‘testMethod’ which takes one input parameter which should be a valid Ethereum address, then it is doing something we don’t know and in response, it returns a bool value of true or false. When thinking about client-server architecture we can compare abi to classic API endpoints information.
We know how to use such an endpoint but we need additional documentation to know what the back-end or blockchain app is really doing.
With web3 0.* version calling such method will look as follows:
Because 0.* is callback bases it is always a good practice to wrap contract methods with Promise. Then we can easily stack such methods with async await syntax without nested callback hell.
You can connect your website to an existing blockchain application and display data on it. We can have a simple HTML/js app placed in standard hosting without any back-end technology. The application will behave in the same way located in an external server or on our localhost. All information we want can be taken from the blockchain.
When connecting our js app or simple website with web3 I suggest you use Facade pattern to create an additional layer of interface masking web3 executions, helpful when something will change on the smart contract side.
Often during a dApp development project, we not only read some information, but we also want to make more complex operations. These include transferring funds somewhere, paying for something etc… In such a case users have to have access to their ETH wallet. The simplest way to allow that is to install Metamask Chrome extension.
Once you install Metamask, you can use web3 to interact with it. There are methods for taking our accounts list from Metamask, check in what network Metamask is connected etc. Please check web3 API docs for more information.
Our decentralized web application may be 100% dependant on Metamask. Each operation in our wallet (like transferring funds) will open a popup window from Metamask to submit it. It’s a common practice to detect if Metamask exists in the browser. If not, instead of rendering the application we are displaying proper instructions on how to install it and enable it in the browser.
Note about big numbers
minus, divededBy, plus and finally transferred to readable value for our UI with toNumber, toFixed etc…
DApp development is not going to change the way we develop apps. Front-end developers can still use all the tools they already use just with a few tweaks. Instead of our AJAX calls, we are using Web3 to communicate with blockchain. All the data that we get from the blockchain is 100% decentralized stored in a ladder in multiple computers in a secure way, but are we fully decentralized? Still, our front-end application, even created with pure HTML/JS will need to be stored somewhere.
For now, we need to rely on our hosting and domain providers and if they crash, our dApps will go offline. Surely in the case of an emergency, we can host it on our computer and successfully connect with blockchain to get crucial data. Still, there is a long way to have a fully decentralized world. Let’s see what the future brings.