A Java developer approaching the blockchain (III)
Eventually, here I am with the last part of my first journey in the blockchain world. Last time I mentioned that I would have shown my application in action so let's recap how to run it.
Running the appA quick list of steps to be performed is below; consider referring to previous posts on this blog for additional details on the tools.
- Checkout JavaBallot sources using git from https://github.com/onchainit/JavaBallot.git
- Download and install testrpc
- Start testrpc as explained in JavaBallot's README.md
- Build JavaBallot (mvn package)
- Run the application with java -jar target/webapp.jar
- Browse to http://localhost:8080/
The web app is very simple page with two forms. The first one is to deploy the contract; the user is expected to select the JSON wallet file from the disk and provide the password for decrypting it. The number of proposals, second beneficiary, perc and cap are further parameters required to configure the ballot contract (basically, who besides the account that's used to create the contract is eventually getting the prize and in which percentage, plus the proposals number and max cap for the ballot). By pressing the vote button, a JAX-RS call to the backend is performed. The invoked resource uses Web3J to read the wallet, prepare the contract deployment transaction and send it over to the Ethereum network. Then it writes back an HTTP message with the deployed contract address in the body.
The user can copy the address, get back to the form page and use the part below to perform a vote.
The account for the voter is to be selected by picking the desired wallet file, the number of the proposal to vote as well as the amount (in ethers) to send are to be specified. The vote button sends another message to the backend that performs another transaction using the voting method of the previously deployed contract. A response with the consumed gas is returned to the user.
The application is really trivial and raw, but that's not really relevant at this point. What I wanted to try was putting few pieces together (Web3J, RESTEasy, testrpc, Solidity, ...) and I pretty much achieved that. Now on to the comments.
First of all, the fat-jar approach is essentially a mechanism for shipping a web app and its web container, and running them all together with a browser on the same user host. This way, I don't have to bother too much about transmitting the wallet passwords between the browser and the Java backend (of course we could have also had some degree of security in place for the HTTP communication).
Ideally, when creating a corresponding DAPP for mobile devices, the current JAX-RS resources would have to be factored out to a plain service that would be invoked by whatever is used on the target mobile platform to build the graphic user interface.
This said, there are of course bunch of alternatives to this architecture; just as an example, embedding the Ethereum client in the web page to avoid having an additional layer is what many do by relying on web3.js...
Interacting with the blockchain is clearly an asyncronous process. In the real world blockchain, transactions take time before being confirmed, as the blocks need to be mined. Web3J comes with a pretty nice API supporting "recent" java types (e.g. CompletableFuture) that allow for building up a reactive-syle application. I didn't pay to much attention to that in my prototype, but clearly that's something needed for a decent user experience (you don't want the app to be synchronously waiting for the transaction outcome).
Speaking of user experience, clearly a good application would require a decent look & feel.
As expected, bunch of work for a real world application in the future :-)
Thanks for your attention, stay tuned for future further experiments!