Designing Blockchain D-Apps, Part 1: Overview & Insights
This is part of a series of articles exploring how to design decentralised apps (D-Apps) using Ethereum. Part 1 of this series provides an Overview of the process and Insights we gathered along the way.
As part of our exploration of blockchain we’ve been learning the nuances of creating D-Apps, from inception to QA testing. This article is designed to act as a recording of the process, for anyone attempting to follow the same path. If we have something wrong, inaccurate or out of date, let us know in the comments!
“Learning is pleasurable but doing is the height of enjoyment”
Why are we doing this?
As a team we work within the health technology space, developing new web-based services to compliment existing healthcare models. Given the potential applications for blockchain in healthcare, we’ve been conducting a series of R&D sprints to develop new concepts that we can use with customers.
We like “learning by doing” but we also recognise the value in outside critique, so we’re sharing our process to prompt conversations with smart people around the world. If that’s you, join us in the comments!
What are we hoping to achieve
Our overall goal for this project can be summarised as “learning”, but specifically we wanted to:
- Improve our processes: We’re experienced in developing Web Apps in a LAMP style stack from business case to scaled delivery. But do these processes apply in the blockchain space?
- Improve our skills: There are obvious technical differences in transferring from PHP to Solidity, but we also felt porting our Business Analysis (BA), User Experience (UX), Architecting, and Quality Assurance (QA) would prove challenging
- Find and develop toolkits for D-Apps: Venturing into a young, fluctuating and decentralised environment means re-tooling
- Generate Insights: We wanted to develop a strategic edge, by learning more than potential rivals
- Generate credibility: We feel there’s a lot to be gained by supporting the development of skills and talent
- Have some fun: We all love tinkering with new tech, this was a great way to spend some work time letting ourselves off the leash a little!
Overview of what we did
We laid out a project roadmap to ensure we delivered something tangible each sprint. Here are some of the deliverables we realised:
- A research report into blockchain technology and ecosystem, part of which can be found in another post here.
- Development of blockchain technical skillset, by sending our dev team on training for Ethereum (Solidity) and Hyperledger (Fabric).
- Generated a range of D-App concepts, based on virtual business cases, selecting the most relevant for development.
- Build a testable D-App, that interacts with the blockchain
- Record the experiences, insights and learnings (some of which you’re reading here).
A summary of the things we learnt, for anyone too lazy to read the individual articles:
- Work hard on the use case. The limitations of the technology mean it’s of more importance than with a normal application. There are so few libraries and resources available, figuring out a relevant problem to solve becomes key to saving technical resources.
- Make it simpler than you would normally. Then build from there. Our instinct was to think of this as a cut down Web App. But in essence, we were more at a “Hello World” technical stage. The minute we extended beyond, we placed a huge pressure on the dev team, especially in light of the next points.
- Its all in Beta. Be prepared for the underlying platform to change whilst you’re developing and documentation to be sparse, or out of date. On several occasions, we found things changed in Ethereum without warning. We also found that a lot of the official documentation was not 100% accurate. We attempted to interact directly with the Ethereum platform as we felt that we’d learn more. In retrospect, it may have been easier to use something like Truffle to help.
- Testing is different. Even for simple UI testing with a smart contract on the testnet, there’s a few new processes to get your head around. For instance, you’ll need to set up a Test Account and Transfer in Test Ether, for each user. This meant we did a lot more local testing than normal and didn’t get round to setting up automated tests. This is something we’re looking to formalise next time though.
- Get into a decentralised mindset. Theres a philosophical change required in how the team thinks about the whole process. From concept to delivery, the idea of “having a server” disappears. This is probably best reflected in the language we used, as we needed more specificity for things like “Accounts”. We’ve put together a few more articles you can find here.
Some things we’re going to do next…
- Explore more use cases and create more D-Apps. We aim to repeat the process till we’re good at it.
- Test out Truffle and explore other frameworks and toolkits. If we can’t find things we need, we’ll attempt to build or own or document work-arounds.
- Improve our testing processes and tools. It’s something we didn’t get around to in the time we allotted. But that’s not really an excuse, #QA4Life.
- Explore adding payments by using MetaMask as the interface to run the D-App and handle the payments. We’re also playing with the idea of creating a “Lending Token”, as we feel it may simplify the transactions further.
- Explore blockchain friendly storage with Oracles and IPFS. A major hurdle for many of our use cases, was decentralised storage. By using something like IPFS (or Filecoin/Swarm longer term), we should be able overcome some of these challenges.
- Try using HyperLedger as a private blockchain and alternative to Ethereum. Public and Private blockchains have inherent differences. We’re not clear on the best use cases for each, but we’re keen to find out.
- Create more resources and tools in the space as we go. Generally, we’re keen to get involved with blockchain work, to find the value.