The Web3 Developer Stack [2023 ed.]

The Web3 Developer Stack [2023 ed.]

Tuned, tried and tasted 😏. This digestible web3 stack is as cozy as your maple-coated fluffy pancakes on a slow Sunday morning.

·

9 min read

Note: the word 'stack' as used in this article is not clumps of flour packed atop each other; but the tools, libraries and frameworks required to build a decentralized “web3-esque” application.

I started my developer journey relatively late, and consider myself relatively lucky as a result. I was exposed to the world of decentralized technology shortly after I graduated from a bootcamp learning the ins and outs of traditional tech. I haven’t looked back since.

One of the first lessons you learn as a nascent developer shuffling your feet to jump into the deep end of web development is that you have to define your tech stack. At the time I entered the ecosystem, web3 was still sort of figuring its life out.

In this guide, the web3 stack is broken down into the following layers:

  1. The Protocol Layer: The foundational blockchain technology

  2. The Storage Layer: distributed peer-to-peer networks for data storage.

  3. The Interaction Layer: where the sweet stuff happens

  4. The Presentation Layer: what users see

  5. The Identity Layer: how users are granted access.

Bon appetit đŸ„ž


01:: The Protocol Layer

The foundation of the web3 stack is comprised of a blockchain or decentralized protocol. In web2, we saw a centralized foundation of databases. In web3, we build atop a nest of trustless and permissionless blockchain architecture.

When picking a blockchain network for building decentralized applications (dApps), developers have two choices: Ethereum Virtual Machine (EVM)-compatible blockchains and non-EVM-compatible blockchains.

EVM Blockchains

Ethereum was the trailblazer for web3 blockchain development. The most important aspect of the Ethereum Virtual Machine (EVM) for developers is that it provides the framework for storing and executing smart contracts. Without the EVM, on-chain logic has considerably less power.

With the rise of Ethereum’s blockchain and the EVM, many different networks aiming to solve Ethereum’s scalability limitations or expensive transaction costs have opted to develop frameworks fully compatible with the EVM. This means EVM-compatible chains all share the same software layer—namely Solidity—that runs smart contracts.

EVM-compatible blockchains allow developers to leverage all the same tools, documentation, and communities built specifically for EVM chains, saving time and money.

Examples of EVM-compatible chains:

  • Ethereum: The OG of smart contract platforms.

  • Polygon: Ethereum's sidekick

  • Avalanche: L1

  • Arbitrum: L2 using Optimistic rollups and multi-round fraud proofs

  • Optimism: L2 using Optimistic rollups and single-round fraud proofs

  • ZKSync: ZK rollup Ethereum L2 network using SNARKs

  • Starknet: ZK rollup Ethereum L2 network using STARKs

Examples of EVM development environments:

  • HardHat: Javascript-based. Allows you to compile, test, deploy and debug Ethereum-based applications.

  • Truffle: A trifecta of javascript-based developer tools for compiling, testing and deploying EVM code. Truffle is the main development environment, testing framework and deployment pipeline, Ganache allows you to spin up a local blockchain, and Drizzle is a collection of frontend libraries.

  • Foundry: blazing fast and modular toolkit written in Rust. (This is really hot right now.)

Non-EVM Blockchains

There is also a community of non-EVM developers. These devs argue that the constraints of the Ethereum framework stifle innovation and developer freedom. Further to this, non-EVM-abiding blockchains are typically optimized for data and transaction scalability and thus enjoy higher transactions per second (TPS).

Non-EVM Blockchain Examples

  • Solana: L1 using Rust/C/C++

  • NEAR: L1 using Rust/Assemblyscript

  • Tezos: L1 using OCaml

  • Flow: L1 using Cadence

Examples of Non-EVM Blockchain Development Environments

  • Anchor: Basically the Truffle of Solana

  • Flow: has its own extension in Visual Studio Code.

đŸ€” Which blockchain should I use?

As mentioned, there is no one blockchain to trump all. The future is multichain and very exciting due to the unique architectures and consensus mechanisms of each. There will be scenarios that fit each chain.

If you go the EVM-compatible route, you'll have a robust toolbox of time-tested and smooth build experience. So if you are just starting in your developer journey, it may be a good idea to learn the ins and outs of the EVM family so that you can take advantage of a mature ecosystem of tooling, infrastructure and documentation.

If you’re a well-oiled developer with a burning passion for innovation and building in a particular niche, you might consider delving into the world of non-EVM compatible blockchains to realize your vision.

The following is a list of questions you might ask yourself when choosing your chain:

  • What am I trying to build?

  • How much community support do I want?

  • What are my priorities?

  • How good is the quality of developer tooling?

  • do it hang low?

02:: The Storage Layer

The blockchain is great, but like the best of us — it's imperfect. Skills in its talent pool include: providing a platform for smart contracts and facilitating the traceability of verifications of transactions.

Skills that are not in its talent pool: storing large amounts of data. It is costly, due to gas fees, and highly inefficient.

To mitigate this, however, there exists a decentralized data infrastructure that allows you to store information such as images, videos and more, off-chain. You can then use the link to that data to complete your on-chain activity.

There are two approaches to this. You could stick to traditional, centralized storage solutions such as AWS or Google Cloud. Or you could up the ante and stick to the true nature of decentralization by opting for a decentralization storage solution.

Here I will outline the two main players in the space right now:

IPFS

The Interplanetary File System is a distributed peer-to-peer network consisting of nodes that store and share files. IPFS has been the preference when it comes to NFTs and is known to be the backbone of the current NFT ecosystem.

There are two ways to serve content via IPFS so that it renders correctly in your browser:

  1. Use the public IPFS gateway. This is open to the public which means your content will be available for everyone to use (and/or abuse!) at any one point in time.

  2. Use a private gateway using an IPFS adjacent service such as Pinata*. You can enjoy lightning-fast speeds, 24/7 reliability and unmatched customer service.

*Disclosure: I am currently working in-house for Pinata as their developer evangelist. Sign up for a free account today.

Arweave

Arweave is another popular solution among the developer community today. It differs from IPFS in that it incentivizes people to store data permanently.

Within its network, miners provide storage space in exchange for tokens. The protocol's role is to ensure that the data stored is correct and remains in consensus across all nodes.

Check it out here.

03:: The Interaction Layer

Now that we have our protocol and storage sorted, we will need to locate platforms that provide easy access to (1) read and write blockchain data, and (2) serve the content from our storage network of choice.

You could do this the hard way, or the easy way.

The hard way would be to run your own blockchain node. This might sound pretty cool at first, but it will eat up your time like your TikTok 'For You' feed and will deduct precious productivity.

The recommended alternative would be to use a Remote Procedure Calls (RPC) node service provider that provides access to private RPC endpoints. Although blockchains and protocols provide public RPC endpoints themselves, these are not ideal for production as they are shared and rate-limited. Node service providers handle the setup, management and maintenance of your dapp. These services will allow you to connect your dapp to the blockchain network in a matter of seconds, and re-allocate that time to productive building.

Examples of Node Service Providers:

API Querying + Indexing

Where these two communities diverge, is in how developers retrieve data from external APIs. Unlike web2 databases, the data on blockchains are not optimized for two-way interactions with application frontends. A core primitive of blockchain data is that is it sequential. This makes it optimized for ‘adding blocks’ of data, not indexing, organization or retrieving. Thus, anything beyond the basic 'write' operation is ruled out.

In the web2 stack, we had databases and HTTP request libraries such as Axios and Fetch. In the web3 stack, we have the following:

04:: The Presentation Layer

The presentation layer that comprises the front end of a dapp is where we see the most overlap between web3 and web2 development.

Frontend User Interface

The thriving frontend ecosystem of React.js is loved by the web3 developer community, just as much as it is by web2 developers.

If you’re loving React, or have yet to try it out — I recommend using Next.js as the framework of choice. Powered by Vercel, Next.js has a great developer community and stellar documentation to guide you through your project.

Styling

Recently Tailwind CSS has been having its glow-up. For good reason, too. Other CSS libraries I have used previously include Material UI, Bulma and Tachyons.

Popular web3 frontend component libraries

05:: The Identity Layer

This, in my opinion, is the most exciting layer. This is where the glorious toppings live. Whether you're a maple syrup and glazed banana person, or a bacon, vanilla ice cream and strawberry kinda gal.

In web2, authentication methods rely on the exchange of a user’s personal information for application access.

In web3, identity is based on the notion of a ‘wallet’ and its public keys. I’d like to extract the financial aspect from the term ‘wallet’. In this context, a ‘wallet’ is the web3 equivalent of an ‘account’ as per the web2 paradigm.

The quintessential authentication experience in web3 comprises request access to the user’s wallet address.

In the case of browser wallets such as Metamask, you would access the provider object exposed by these wallets. In the case of mobile wallets, you would employ tools like WalletConnect (for Ethereum) or Solana Wallet Adapter (for Solana) to scan a barcode exposed by the decentralized app.

There are two libraries I’d like to call out for adding wallet connection capabilities into your dapp: RainbowKit and wagmi.


Summary

The resources outlined in this article are just a snapshot of the web3 development ecosystem. They are also protocols and projects that I have either used to build my own dapps, or seen other developers using in their projects.

I have seen multiple iterations of talented developers defining their web3 stack. The five-layer partition, therefore, is not an industry consensus and is more likely representative of the number of real-life pancakes I can consume in one sitting đŸ« .

I hope you found this article tasty and digestible.

If you have any additional resources you'd like me to add to this list, drop them in the comment section or DM me on Twitter.

Connect with me on Twitter and LinkedIn.
Sign up for a free Pinata account today.

Cheers for sticking around, and until next time! đŸ«Ą

Â