DApps – another blockchain buzzword

In the previous post i have described the blockchain as an immutable records database and the smart contracts as an immutable objects database with the difference the objects can change its state within the database if object method is called.

The definition of “Dapp” is both vague and simple.
It is simple because “Dapp” means nothing but “any application using smart contracts in any way” and it is vague because this simple definition does not have magical aura around itself and they try to add some blessing that masks the simplicity of the term.

Meanwhile the real magic of Dapp is not in the definition but rather in the implementation.

In fact the “using smart contracts” is nothing more but “call JSON RPC methods”. The application which calls the methods is Dapp. This triviality is hidden by Web3.js stuff they put all around and make you to become familiar with it while you want just to become familiar with the Dapp. The reason of this is simple: Web3.js may be treated as one-to-one JavaScript wrapper around the real JSON RPC API and calling Web3.js javascript function you will call the JSON RPC methods. As soon as you understand this using Web3.js becomes natural and obvious but if you have no the understanding Web3.js seems to be a use of spell.

Ok. So we can start making our first Dapp just requiring the web3.js in our frontend or backend application and add a proud line “smart contracts” to the resume. But allas. There are at least 2 rubs.

First just think about how are you going to call the smart contract methods with JSON RPC (or web3.js)? Of course there are APIs for that, but imagine how difficult and dull it would be to pass all the necessary args of the contract’s method inside the JSON RPC arguments. It is possible but it looks like something from the times of the stone age of the unix sockets programmed manually. In the real life you would like to create the stubs with the tools like truffle or perigord and call the smart contracts method as if they are local functions. Well known approach since the IDL/COBRA/DCOM appeared.

Solving the problem with calling the smart contracts methods with JSON RPC stubs we would immediately face another one: what is JSON RPC server? Where we are going to send json rpc to?

The first answer is simple once again: run local smart contract network node. For example launch “geth” in case of Etherium and connect to it from your backend application. There simple but not very perfect: that Dapp will die as soon as the host with the running backend app and geth will have been turned off. It does not seem natural for the “immutable” databases.

Because of that let’s move our smart contract calls from the backend to the frontend putting the JSON RPC queries inside the simple HTML page that can live forever not requiring the particular application server to run. There’s nothing special by adding script tags to include web3.js and smart contract stubs to that page, but we face the same problem as with the backend – where’s the JSON RPC server? And now the answer is not so simple from the technical point of view but still simple from the developers side: just make an user to install metamask plugin into your browser. That’s all. The JS frontend app will call the plugin and the plugin will reroute the requests to the network. The solutions in not very elegant from the end user’s point of view and creates some traction for distributing the app but there’s no another way.

And meanwhile to bring the frontend implemented DApp to the end user’s computer there still some http service necessary. Of course to launch nginx instance on some AWS EC2 host is trivial but is still can not be done fully automated and independent and even “decentralized” in mean the service will have the owner. This is there IPFS and Swarm appears but this is another story.


Leave a Reply

Your email address will not be published. Required fields are marked *