As mobile apps proliferated into the common sphere of awareness, the “new normal” of this interconnectedness revealed a dark secret. These convenient, easy-to-install and free applications came at a high personal cost to our privacy. We became the products. As our patterns of behavior and data were transformed into commodities (and through an increasingly unfair exchange) the value of our digital identities are controlled and then sold for massive profits.So, where are the DApps? As we will explore below, there are a number of highly specific and challenging obstacles to overcome before they become viable and easy to use. While it may sound defeatist to simply say that DApps are hard, the trials they present are not insurmountable.

Choosing the Platform

The initial step in the development of a DApp should not be taken lightly. Ethereum is currently the most frequently selected, but others such as AION, EOS, TRON and TEZOs are among the growing number of viable options as well. Even the relatively straightforward first choice requires a hefty dose of research, however.While obviously the selection of which platform to build on should be based on strengths (speed, reliability, etc), developers simultaneously become wedded to its drawbacks. The choice signals “no turning back” and is laden with risks of the most dangerous kind: unknown unknowns.There are numerous considerations you need to be mindful of when choosing a blockchain to develop on. Reliability, performance, scalability, consensus mechanisms, and available talent/tooling must be evaluated. Here are a few resources to help guide your assessment of the available platforms:Cryptosociety — What is BlockchainBlockchain Hub: Blockchains & Distributed Ledger TechnologiesBlockgeeks: Different Blockchains: Ethereum vs Cosmos vs Hyperledger And More!Whatmatrix: Blockchain for EnterpriseEthex: Comparing Top Blockchain Networks in 2019

What About the Nodes?

Once decided, the work cannot begin until connectivity is in place. Should the team deploy and maintain its own nodes? Running a node is a job in and of itself, and difficulties troubleshooting uptime are compounded into the waste of otherwise useful energy that could be spent developing the DApp itself.Let us say a given team has chosen to offload the duties to a specialty provider:In the case of Ethereum, there is the heavily utilized Infura, of which 5–10% of total connections are dependent on. While Infura does genuinely assist in streamlining efficiency, it brings fundamental issues to the fore. Infura relies on cloud servers hosted by Amazon and the high degree of centralization from using this provider easily invalidates every unique selling proposition. DApps are no longer unstoppable, can become subject to censorship (akin to sanctions), are not trustless (the data is taken at face value), and party to a single point of failure (passing along bugs or loses availability status).We don’t mean to single out any one provider, it is merely an example. In the case of Infura, what they have done for the Ethereum community is a gift very hard to repay. The ease in which you can connect to Infura and no longer worry about infrastructure scaling gave rise to rapid development in the space.Here are the options that you have for connecting to infrastructure.

1. You can set up and maintain your own node infrastructure, which gives you complete control but may also cost you time and money that you may feel is better spent elsewhere.
2. You can connect through a service provider or DApp interface (such as MetaMask or Portis), these services take away most of the burden for you and have their own unique specialties. You will still want to weigh the service against your vision and objectives to make sure that you are aligned.
3. You can connect through a decentralized relay network, such as Pocket Network, which then coordinates your requests across a diverse set of nodes from individuals and service providers in order to maintain performance and decentralization.

Running Out of Gas?

Whatever way the connection is established, we still have the network mechanics to consider.Without anything put in place by the DApp team, users are likely to see their transactions fail due to an inadequate gas limit. When there is no feedback about why this has occurred, users are left frustrated and in the dark.Among the solutions to this problem are projects such as the Ethereum Improvement Protocol (EIP-1613) which introduces the proposed gas station network . Portis have already taken steps to decentralize meta-transactions through use of Tabookey’s “toll-free” transactions in a way that circumvents end users need for having gas or even understanding what happens under the hood during their use of a DApp.

Debugging the Layers

Assuming the DApp team makes it this far, we still have the DApp itself to implement and deploy. Despite the open-source nature of the landscape they are working in, the technology stack is still remarkably new and presents sticking points. Dependencies on both the client side and of the smart contract platform create an immense debugging challenge.Wrestling with unfamiliar but dependent codebase frequently becomes a time-intensive and costly factor that many smaller projects may not be able to sustain for sufficient time to get the DApp to MVP status. Solutions to bugs may not be easily discovered.Taken in sum, the enormity of these factors are not only demotivating but potentially even delimiting to the pursuit of DApp development. Factor in an unexpected change in any of the previously mentioned challenges with Infura or addressing the issue with gas and progress suffers the deathblow.

Missing Fundamentals

A massive gap exists between the general population and users of cryptoeconomic assets and decentralized applications. Despite widespread familiarity with mobile applications, the necessary leap to DApps is both philosophical and technological and remains to be seen. A rudimentary understanding of the existence, purpose and effective interaction with blockchains rarely occurs spontaneously or over casual conversation.Even with sufficient interest, users need to master several tasks before using a DApp. They must secure cryptocurrency via an exchange (which requires a KYC process) and then install a wallet such as MetaMask. Even the most enthusiastic early adopters will run across several friction points and decide to “try it later” or outright give up trying to use the DApp.

A Painful Experience

Poor UX negates any and all success made during prior developmental processes. For the user, frustrations which were kept at bay up to this point may finally succumb to the user’s existentially despair: “ why do I need this? “ To knock over the first domino toward mass adoption, single-step onboarding is a must.Developers have an enormous challenge in delivering this last crucial aspect. Fortunately, there are several comprehensive resources which provide step-by-step guidance:Dappuniversity: The Ultimate Ethereum DApp TutorialDAppsforbeginners: Your First DAppBloom: How to Make a User-Friendly Ethereum DAppUX Collective: Designing a Decentralized Profile DAppLooming over this discussion is the broader issue of the blockchain trilemma: how to adequately balance decentralization, scalability, and security. This delicate triangle has yet to find an optimal equilibrium where the strength of any given attribute does not take from the others. Should any particular aspect take precedence in a given application or context? The answer to this question will likely serve as the “bridge” to allow developers to cross the chasm and bring a pleasant, useful and valuable DApp into the mainstream.Also, should the first steps begin in the ideal, where decentralization is complete and advances toward practical application? Perhaps the opposite direction is the better choice: where a pragmatic level of centralization is used as a stepping stone toward the ideal and totally decentralized system.We have seen both approaches taken in the space today. For example, one blockchain interoperability protocol may be built on the conviction that a multi-chain universe lies ahead and takes the ground-up approach of totally decentralized components as they are designed and implemented. Taking the other tack is building its structure for functionality first and foremost and will gradually increase the level of decentralization once features become operationally stable.While the debate on the approach is always passionate or even heated, the fact remains that no one can say for certain which will be the winner. The practical, valuable and fully decentralized web3 application has not yet seen the light of day. Many agree that efforts are inching continually toward it, however.

Next Best Steps

All things considered, the advent of “the app” is still quite new. Even the monolithic success stories of the traditional market (Uber and Airbnb) are only now reaching the initial public offering phase of their lifecycle. It has taken this long to get to this point and will take longer still to bring decentralization into the picture.So how far along are decentralized apps, and what sort of work in their development should be worked on?New support ventures in the DApp universe are already working to facilitate the transition from web 2 to web 3. Examples such and are have made their assessments and focusing their efforts on the supportive elements and gradual decentralization approach. While the chicken-versus-egg debate continues to unfold, both agree that the underlying support infrastructure must be improved concurrently with the development of DApps themselves.Bringing additional services into the arena adds necessary competition as well, and is likely to drive superior options to the surface. Even in a scenario where coexisting entities provide similar services (such as Portis and MetaMask), distributing the load (in combination with unique approaches to specific segments of the market) can diversify the options available to DApp projects, thus mitigating the risk with single points of failure.

Filling One Gap at a Time

In summary, as a developer looking to build a DApp for either completely humanitarian reasons, completely profit-driven, or a happy hybrid, you’ll need to consider these important factors:

1. Choosing the right platform fit, and de-risking your long-term dependency on that platform if it does not pan out as planned.
2. Ensuring that your infrastructure has minimal reliance and what could ultimately become a single point of failure.
3. How to deal with crypto-economics implications for the end-user, such as “gas fees”:
4. Debugging and other quality assurances in rapidly changing codebases.
5. Elegant interfacing through mindful UX considerations.
6. Motivations of the end user, do they actually care about the same things we do? How do we get them to care?
7. Constant orientation and reorientation of the key technical value propositions with the users ideal experience.

A special thanks to Tom from Portis.io for providing feedback to this article.To continue the conversation around DApp development, node infrastructure, and their deeper considerations, join the telegram group. https://t.me/POKTnetwork

References

Apple trademarks ‘There’s an app for that’What is a Decentralized Application?The blockchain: A programmers nightmare and why dApps are so hard to programWhat is a Light Client?The Race is On to Replace Ethereum’s Most Centralized LayerInfura is a massive single point of failure — Do not use it for your DApp!Why you shouldn’t be using Infura for your DAppSponsor your users’ gas fees with Portis and TabooKey’s Gas Stations Network1–800-Ethereum: Gas Stations Network for Toll Free TransactionsCryptonetworks Will Challenge Infrastructure Monopolies