Blockchain writer, DeFi disciple, member of dOrg
Web3 is a new and developing homeworld for the decentralized internet. It is an infantile space, with not as strong an infrastructure as its Web2 predecessor.
The developer experience for Web3 is rife with inconveniences, including bloatedness, lack of protocol standardization, limited support for other platforms, and many more.
These issues aren’t really vocalized beyond the Web3 developer community. To bring some of these issues to light, let’s dive into some of the most common problems for Web3 builders.
Integrating Web3 into applications today is extremely slow, especially when compared to Web2.
In Web2, complex application logic is offloaded to centralized servers. For example: when a user tweets, the app simply makes a request to Twitter’s API, which posts a tweet on the user’s behalf. This enables apps to remain lightweight and integrate dozens of APIs seamlessly.
But in Web3, applications handle this complex logic themselves, because central servers have been replaced with P2P networks and expensive smart contracts.
In order to integrate Web3 protocols into applications quickly, protocol developers maintain client-side SDKs for app developers to use. This process requires a lot of time and energy, on both the protocol developer and app developer’s behalf.
In order to understand why these client-side SDKs are required, and why they are time consuming to develop, we must first dive into the range of capabilities a typical Web3 application may want to include.
When building a dApp (decentralized application), you’re often not just interacting with smart contracts. Web3 applications often implement a variety of capabilities, such as: peer-to-peer messaging, decentralized storage, producing cryptographic signatures and proofs, interacting with side-chains, and the list goes on.
As we can see, building a Web3-enabled application is not as simple as interacting with a single endpoint on a server.
This development loop is much different from what web2 developers are accustomed to. Normally, they are able to make backend changes and have them automatically reflected in the frontend, if the service’s API stays consistent.
There are significant costs for creating and maintaining these libraries, making it preventatively difficult to scale protocol integrations.
Imagine having a bookshelf of hundreds of books in alphabetical order, and each new book you add means you must line up every single one of the books alphabetically, all over again.
This is the web3 developer’s headache. Each new Web3 protocol that gets developed has its own “bookshelf,” which only compounds the time needed to maintain and grow the Web3 development ecosystem.
For Yearn you’re able to publish new strategies and get them added to the vaults upon consensus.
The downside is that the application does not dynamically update with details on how the strategy is working. In an ideal scenario, the Yearn Vault app would allow any user to click on a strategy, inspect its mechanics, and interact with the exposed levers and pulleys that keep it running. This instead is being done behind the scenes by a small group of maintainers and enthusiasts.
In the case of Aragon, developers can publish new pieces to the protocol on-chain, but the same scenario repeats itself where the client-side application does not dynamically update to support the new on-chain functionality.
For example, if a developer had created a new quadratic voting contract, and published it on-chain, it’d be great if the Aragon app was able to display and use it automatically (as long as it adheres to a standard interface).
There are however ways around this, by leveraging something like WebAssembly, where it’s very easy to create a new secure VM instance. This allows for secure code injection, which enables dynamic client-side behaviour.
What are the costs associated with Web3 composability? In order to understand this, we must remember the fact that integrating Web3 protocols requires client-side SDKs.
With each new SDK added, the application’s size grows. In addition to bloating the application, SDKs often have conflicting dependencies, leading to incompatibilities and many headaches.
This means that there is in fact an upper bound to how many integrations an app can have. This is much different than Web2’s microservice paradigm, where every imaginable API is a one-line HTTP request away.
In Web3, everything should be transparent, compatible, and reusable. This is the beauty and ethos of open-source. If we apply this thinking here, we’d like to imagine a future where the average Web3 application uses dozens of integrations, but this is looking unlikely if we continue down the path of client-side SDKs
There have been many projects that have been created by the Web3 community to try and fix this (such as LavaMoat), but these are simply bandaids on a much larger issue.
This brings us here: there is a project right now that is aiming to bring that Web2 experience to Web3 in a completely decentralized way. Web3API aims to present a single solution that can help address all of these problems.
Web3API will allow dApp developers to integrate any Web3 protocol through GraphQL, a widely used query language for Web2 developers. It will let you aggregate dozens of protocols into a dApp without bloating the size of the application, and provide the ability to interact with Web3 in any programming language through the magic of WebAssembly (Rust, J Python, Go, C,C#).
Create your free account to unlock your custom reading experience.