Blockchain application development is not popular among front-end developers. 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 blockchain apps. If compared with a traditional application – a decentralized application is not as difficult to program as some people think. In this article, I’ll show you some simple tricks to get you started.
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.
Client-server architecture
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. In 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 development 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 a 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 to a decentralized 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 how is it even possible without traditional centralized servers?
In some cases, it is possible to remove a traditional server. Instead of calling our server with a simple AJAX request, we will be calling any of the nodes creating the blockchain network (via web3 API). In the next paragraphs, I’ll show you how.
Connecting to the blockchain
The first thing to do when you start a dApp development project is to download the 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 that 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 the status of the network. 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:
The 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.
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 that 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.
Web3
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 espeoblockchain.com. 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.
Non-trivial examples
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 the list of our accounts from Metamask, check in what network Metamask is connected etc. Please check web3 API docs for more information.
Our decentralized web application may be fully 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
As we all know javascript is not perfect when handling big numbers and float types. Most of us are familiar with the problem when calculating float number like 0.1 + 0.2 which is a typical recruitment question for years. For more details related to float arithmetics in javascript please visit this article.
Smart contracts don’t have float numbers, they operate only on int values and on very large ones. How to make it compatible with javascript? There is BigNumber library which is helping with that. All numeric results which we are getting from Smart Contract methods using web3 are in Big Number format. I use the BigNumber API for every calculation. For example, minus, divededBy, plus and finally transferred to readable value for our UI with toNumber, toFixed etc…
Conclusion
Blockchain application 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 the 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.