The emergence of Web3 has brought about a paradigm shift in the way we interact with the internet. The arrival of the decentralised web means users have more control over their data and experience across the internet - and slowly we’ll eliminate all inefficiencies with centralised service providers and internet oligopolies.
But web3 brings some serious challenges to building, testing, deploying, and scaling decentralised applications for millions of users. These decentralised applications, or dApps as they are commonly called, run on a distributed network of nodes. When building a decentralised application (dApp), developers must use a different technical application stack compared to traditional centralised alternatives. Today, we’re going to discuss and explore some common technical application stacks that developers have used when building production read dApp.
The Blockchain
The first layer of the technical stack is the chosen blockchain platform, which is the foundation and provides the compute and defines the smart contract environment to the dApp. There are various blockchain platforms to choose from, including Layer-1s like Ethereum, Polkadot, Cosmos, Algorand, Avalanche. Additionally, there are also Layer-2 or scaling solutions built on another Layer-1 that you might consider, such as Polygon or Binance Smart Chain.
When it comes to building a dApp, choosing the right blockchain platform is crucial. The platform you choose will determine the functionality and features of your dApp, as well as the security, speed, smart contract functionality, and scalability of your application. Additionally, the programming languages that a blockchain supports can also affect the development of your dApp and the expertise required to build it - some blockchains, like Ethereum, use Solidity, other blockchains, like Polkadot, support multiple programming languages, making it easier to integrate existing code into your dApp.
Finally, it's important to consider the developer tools and community associated with a particular blockchain. A strong developer community can provide support, resources, and expertise, making it easier to develop your dApp. Strong developer communities also indicate a strong level of infrastructure and developer tooling support that will ultimately help you as you try to build. Don’t be drawn by flashy marketing, aggressive BD teams, or big grants, focus on the developer experience and support if you want to get to market faster!
To learn more about the basics, check out this video from our own Sean Au where he explains more about indexing, blockchain & indexing architecture, and ends with a quick look at SubQuery.
The Logic Layer - Smart Contracts/Virtual Machine
Smart contracts are self-executing contracts that are coded and deployed on the blockchain network. They are coded with logic that can be used to automate the rules and design of your dApp. For example, automate the exchange of assets, facilitate the execution of transactions, create new tokens for a new product, or reward individuals for supporting the protocol.
The most common smart contract framework is Solidity, the programming language of Ethereum. Most web3 developers have some experience with this, but it’s a highly opinionated language that has some constraints and performance limitations. While Solidity is the most widely used programming language for writing smart contracts on the Ethereum blockchain, there are several other programming languages that can be used to develop smart contracts
Rust is a systems programming language that is known for its safety, speed, and low-level control. It has gained popularity as a smart contract programming language on blockchains like Polkadot and NEAR Protocol. Go is also a popular programming language that is known for its simplicity and readability. It can be used to write smart contracts on several blockchains, including Ethereum and Binance Smart Chain.
Some blockchains are working on supporting the WASM runtime, which will allow you to code your smart contract in any language that can be compiled to WASM code that will then be run on the blockchain.
Each of these programming languages has its own strengths and weaknesses, and the choice of programming language will depend on the specific needs of the project. Factors to consider include the platform being used, the complexity of the project, the skillset of the development team, libraries that you want to use to write and deploy your smart contract, and the security requirements of your project.
RPC Interface Provider
Unfortunately, blockchain technology still can't be easily run on a phone or internet browser, as a result you need to connect to a centralised computer to read and submit transactions to the core blockchain networks. These are commonly called RPC Interface providers and there are some factors to consider when selecting your provider(s)
- Reliability: The reliability of an RPC provider is critical - Nobody wants their decentralised application to cease working because a third party RPC provider has an issue. Your dApp needs to be able to access data and submit transactions reliably and without interruption, look for high uptime guarantees and a history of reliability.
- Performance: The performance of an RPC provider can impact the speed and responsiveness of your dApp. Consider an RPC provider with a fast response time and low latency, especially with global coverage and load balancing so all users receive fast response times regardless of where they are.
- Security and Privacy: Consider RPC providers that use encryption and other security measures to protect your data and transactions. Especially important is the policies around handling IP addresses
- Features: Some RPC providers offer additional features, such as caching or load balancing, that can improve the performance and reliability of your dApp. Additional features like better usage analytics and request method breakdowns can help you optimise the performance of your application and diagnose any issues with your contracts remotely. Consider whether these features are important for your project and the privacy tradeoffs.
User Interface (UI)
The user interface (UI) is the front-end of the dApp that allows users to interact with the application. The UI should be intuitive, user-friendly, and responsive, providing a seamless experience for users. Depending on your platform and application requirements, it can be built using a variety of front-end technologies. Web applications will likely consider React, Angular, or Vue, and mobile applications will consider cross browser technologies like React Native and Flutter, or natively built applications.
Storage and Oracles
This is where things start to change compared to centralised applications -dApps rely on various technologies to function, and two important ones are storage providers and oracles.
Distributed file storage systems are important to allow dApps to store and retrieve files and data in a decentralised and censorship-resistant manner. In a traditional centralised system, files are stored on a central server or network of servers. In contrast, storage providers like IPFS and Crust break files into smaller pieces and distribute them across a network of nodes, making it difficult for any single point of failure or censorship to occur.
Storage providers are mainly used to save static files, such as images or documents, that are needed by a dApp. They can also be used to host the front-end of a dApp, allowing users to interact with the application in a completely decentralised way.
Oracles are a key component of many dApps that require real-world data to function, providing a bridge between the blockchain and the real world. Oracles work by fetching data from an external source, such as an API or website, and then sending that data to the dApp on the blockchain. This data can be used to trigger smart contract actions or to inform dApp functionality. For example; price feeds, weather data, and sports data.
Data Indexer
One of the key components of Web3 infrastructure is the indexer. In simple terms, an indexer is a software component that indexes and organises data stored on the blockchain network into a more performant and available storage, allowing developers to query that data quickly and efficiently. Indexers are an essential part of Web3 infrastructure because they enable decentralised applications (dApps) to function fast and support the load of millions of users.
Because data on a blockchain network is stored in a decentralised manner across many nodes, it can be difficult and time-consuming for developers to retrieve that data. Additionally, that data is stored on blocks, and reading data as it changes over time is particularly difficult. A simple example is reading the last 10 transactions executed by the current user - this is extremely hard for blockchain nodes to provide, but easy work for an Indexer.
Indexers like SubQuery can quickly retrieve data from a blockchain network and save it in a format that is easy to work with, for example in searchable and sortable fields that allow developers to quickly find the information they need. This is especially important for user-friendly dApps, where speed and efficiency are critical factors. Indexers are also critical for the security of Web3. Because data is stored in a decentralised manner, it can be difficult to ensure that it has not been tampered with. Indexers help to verify the authenticity of data by indexing that data in a deterministic way, and then cross-referencing it with other indexers in the network, making it much more difficult for bad actors to manipulate the data.
Overall, indexers play a critical role in the development of Web3 applications. They make it easier for developers to work with data on a decentralised network, while also maintaining the security and decentralisation of the network itself. As Web3 continues to evolve, it is likely that indexers will become even more important, as they help to enable and speed up the development of complex decentralised applications.
About SubQuery
SubQuery is a blockchain developer toolkit facilitating the construction of Web3 applications of the future. A SubQuery project is a complete API to organise and query data from Layer-1 chains. Currently servicing NEAR, Polkadot, Avalanche, Algorand, Cosmos and Flare projects, this data-as-a-service allows developers to focus on their core use case and front-end without wasting time building a custom backend for data processing activities. In the future, the SubQuery Network intends to replicate this scalable and reliable solution in a completely decentralised manner.
Linktree | Website | Discord | Telegram | Twitter | Matrix | LinkedIn | YouTube