DApp Development Guide
I was intrigued to read the following article this week, “Decentralized Apps Facing Half-Life After Peak”. It provoked many thoughts around new DApp development challenges. Building a decentralized app (DApp) is significantly more challenging than building a traditional API-powered cloud or mobile app. Leveraging a platform like Ethereum or Computes makes the development process significantly easier but there are still a ton of re-thinking in the design phase to build a successful and enduring DApp.
For starters, most modern (centralized) apps rely on APIs. APIs are centralized. Using traditional APIs in a DApp defeats the value proposition provided by decentralized architectures. Computes has solved this problem by introducing a new decentralized API concept (more details and here).
Hosting your new decentralized app on the AWS or Azure clouds also defeats the purpose. Developers should be looking into using peer-to-peer (P2P) file protocols such as DAT or IPFS. These protocols allow users around the world to reference files (or entire websites) via hashes. These hashes allow content to be versioned and accessed via a decentralized P2P network. In addition to not be controlled centrally, these P2P hosted files typically load faster than cloud content. Video streams buffer less. Sites load almost instantaneously.
Computes extensively uses IPFS for our networks, file systems, pubsub messaging, and our DAG-based DLT (distributed ledger technology). IPFS is gaining in popularity and is even now featured in FireFox Nightly edition! DAT is also making good headway as a standard protocol. It’s built into the Beaker browser! Beaker allows you to browse DAT directories natively and even update content seamlessly.
While I believe that we have demonstrated that browser-based DApps can easily and effectively be hosted in a decentralized fashion, I have seen many DApps being written as thick client binary apps such as Scuttlebutt and TickTack. There are pros and cons to thin vs. thick client apps as we have seen over the years. I’m a huge fan of the progressive web — no app stores or downloads plus the web runs everywhere (even without the Internet).
Regardless on whether you choose thin or thick, you will need to deal with many of the same challenges associated with DApps in general including: synchronizing content and updates as well as transaction speeds. People are accustomed to centralized apps being easy to use and install as well as being very responsive (fast). DApps don’t typically have easy signup processes due to the lack of a centralized database. This means that your setup is usually handled locally and synchronized to other nodes via a blockchain (like Ethereum) or via a mesh network (like Computes).
The lack of a centralized identity system also adds complexity to DApp development and end-user experience (UX). Some companies including BlockStack and Civic are trying to solve this problem; however, I have yet to see an open universal solution.
Platform transaction speeds must be taken into account during your architectural design phase. If you’re building your DApp on Ethereum, you’ll need to account for a maximum of 18 transactions per second (and that’s if you’re running a private blockchain). As we learned with the CryptoKitty craze, it only takes one successful DApp to clog up the entire public Ethereum blockchain. For this reason, many new Ethereum DApps are using “sidechains” like Lighting to speed up blockchain transactions that don’t need to write to the main Ethereum chain.
Computes, on the other hand, is not built on blockchain technology but rather a DAG-based DLT called Lattice. Our design allows nodes to come and go without synchronizing the entire blockchain. We also don’t need to deal with wasted PoW mining. Every compute has meaning and purpose. Today, we are running thousands of transactions per second on private and public mesh networks. Our goal is millions of transactions per second and we’re making great progress!
No matter how fast the platform, DApps create another problem related to aggregating data. Not having a centralized database requires that statuses and timeline updates etc. need to be pulled from nodes in your network via P2P messaging. Computes leverages IPFS pubsub for this activity but it still requires discovery and chatter on the network. (Note: Here’s an article on how we used our pubsub messaging system to manage an Internet of Things (IoT) demo.)
Aggregating data in a responsive way requires some foresight to user expectations and usage patterns. For instance, it’s a good idea to start fetching status updates in advance of the user click next page or scrolling down. It’s also a good idea to attach to bootstrapped nodes on the network which are always online before discovering other relevant nodes. Anything to speed up the user experience will keep them engaged.
Computes is trailblazing the way to building a decentralized cloud computing platform that will power the new decentralized machine-to-machine economy. Our mesh computing technology is 100% decentralized and distributed. It’s powered by a next generation blockchain-like, DAG-based distributed ledger called Lattice.
Contact us (hello@computes.com) for more details. Stay tuned to this blog for more exciting information about our new technology stack and development progress! You can reach and follow us on Twitter, Facebook, Reddit, Slack, and GitHub.
