Web1, the grandparent of Web3, was all about decentralization. Everything was community governed and open. Value was not in the hands of the service providers, but at the very edge — in the hands of individual users and groups of multiple users.
“Web 2.0” was a term coined in 1999 by Darcy DiNucci, later popularized by Tim O'Reilly and Dale Dougherty during the O'Reilly Media Web 2.0 Conference in 2004. In this chapter, the power resides, and has always resided centrally, with the platforms, such as Facebook, Google, and Twitter.
This has caused many problems (Cambridge Analytica anyone?). The argument for the new name was different, however. It was that before the new era, content was mostly static, while Web2 was about dynamic content. Not all agreed (not even the creator of the internet himself), but the name stuck.
Fast-forward to now, we are possibly living at the start of the new era, the time of Web3. The time when we have decentralized apps that run on blockchains. Now, we can finally make things right. The next iteration of the web aims to fix many of the shortcomings and flaws of the previous version.
The code that governs transactions, and runs on, e.g., Ethereum’s (ETH) virtual machine (EVM), is visible to everybody in its entirety. There are no surprises here.
Web3 apps are also much safer. That is because the authenticity of your code is ensured by all the Ethereum nodes around the world. Of course, ETH is not your only option, which is a blessing, as the chain does not have the highest bandwidth possible. In practice, the network is limited to only up to about 15 transactions per second, which some alternatives solve quite well. These are Solana, Polkadot, or EOS.
With the problem of scalability gone, there is one concern that does not go away. No matter which solution you are using, the complexity of new apps sharply rises.
Complex? Not necessarily.
Despite what one might think, Web3 apps are more complex than their Web2 ancestors. Sure, you don’t really write your back-end code anymore in a way that you used to, nor do you manage your backend like before.
There is not exactly a server you need to worry about. The lack of a traditional backend could be seen as a positive. There are so many things you don’t need to worry about or configure.
On the other hand, traditional servers scale much better. You do have to start adding resources eventually, though, though definitely you will not run into a brick wall. The difficulties start when your product becomes known to more and more users.
Ethereum cannot handle too many operations at a time, which it has a bad rap for. The limits can become painful, too fast. There is a light of hope, however. The Eth2 update started on October 29, 2021, with the aim of making the chain more scalable.
The complexity is a result of bypassing the limitations of Ethereum. IPFS to store data, Layer 2 solutions for increasing the number of transactions possible at a time.
The graphic below illustrates what an app’s architecture can look like.
Decentralized? Absolutely.
Web3 does not resolve the issue of centralization fully, either. We still have to host our web apps somewhere. It more often than not will be on the servers of a cloud provider, such as AWS or Azure. There is always an option to host everything on your premises, though we definitely see a trend to do otherwise.
Http is not a necessity, however. The traditional way to access websites (including ours), is not the only way for your clients to access your new app. The Interplanetary File System (IPFS) or Swarm can be the alternative routes to your service. Of course, the majority of your users will not have the necessary extensions installed. Most likely, you will have to host your service in both the “traditional” way, and the Web3 way.
Costly? It depends.
Even though we do not have to have a database, saving all our generated data to the Ethereum chain can become very costly, very quickly. If you feel it would be better not to run out of money too fast, you might store data off-chain. There are a couple of options for you to do that. There is the IPFS, and Swarm.
IPFS may serve as decentralized storage for your app, though as it aims to replace http, your clients would have to at least have a custom extension installed to view the website you’re sending them to. Swarm is another solution to the problem. You may host your websites on the network, and also enjoy the benefits of hosting your app on a decentralized network.
There are some clients There is also a Chrome-based browser, Brave, that comes with an IPFS functionality built-in. If you want a good Web3 compatible browser, that would be the best choice. Another browser that comes with the native IPFS support is Opera. Both of them might be too niche for your taste, so if you want to keep using your current browser, you may download the IPFS Companion extension.
Conclusion
There are always obstacles to overcome when any new tech reaches the phase of Early Majority – do not be discouraged that it’s the same way this time. Obstacles can be overcome in some of the ways we have described.
These obstacles are no mountains that one cannot climb. If you are discouraged by the limitations we have now, it would have been similar to claiming something like “Netflix will never work” back in the dial-up modems days. Sure, it would not have worked then. What was needed was a couple of breakthroughs that did come, in time.
Once you overcome these obstacles, there is a whole another world waiting for you and your users. A world where you and your clients literally own parts of the web. A more democratic world, than the one we have now. If you need a hand stepping into this world, feel free to check out our blockchain development services and contact us!
Originally published on https://www.itmagination.com/blog/developing-web3-decentralized-application-3-considerations
Top comments (0)