How to Structure a Full Stack Web3 Blockchain App
Web3 has an interesting term for their blockchain web pages and applications: dApps. This term stands for decentralized application and refers to apps and services built using blockchain technology. While this is a great term to know, do dApps have noticeable differences in how they join and interact with other internet apps? Is the composition of their components so different that these apps consist solely of smart contracts and blockchains?
The short answer is no. A Full Stack dApp consists of smart contracts on the blockchain, but can also have many familiar web components such as clients and servers. In this article I would like to review how Web2 applications and services work as well as different ways Web3 applications can be architected to create easy to use and powerful user experiences.
Web2 Architecture: A Request and Response
Web2, the period beginning in the early 2000’s and running to today, stepped beyond Web1 by introducing the idea of interaction to users. Web1 was marked by static content and bulletin board like sharing of information. You went to the Web1 internet to learn new information and maybe do some basic e-commerce, but little more.
There was a shift with Web2 as users were allowed to be creators instead of just consumers. This period saw an explosion of users interacting with sites, and by extension servers, to create text messages, blog posts, share videos, photos, music and much more.
Traditional Web2 app architecture is defined by the communication between clients (your laptop, phone or tablet) and servers (Microsoft, Amazon, Facebook or Google computers that handle requests and return resources). The communication can be further explored as a simple request and response cycle. In this cycle the client (you) sends a request to get information or share information with a server. The server receives the request and does some sort of processing which could be anything from retrieving a picture from a database to creating a new store order based on the information in your request:
Once the server has performed your requested action, it will gather all resources and place it in a package with any other relevant information. It will then send this package as a response back to your client (phone). Your client is then responsible for using software to parse the response and give you the information you need. This is how a basic request and response cycle goes.
Of course there is so much more to modern web architecture than just clients and servers. With so much data flowing to so many users there are plenty of optimization technologies that sit in between you and watching cat videos. Covering caching, CDNs and data stores could take weeks so instead we’ll move on with the understanding that Web2 is simple client server communication.
Web3 Architecture: Mixing Old and New
Now that we’ve examined how Web2 apps work, let’s talk about some different ways to structure Web3 dApps. A question worth asking when discussing dApp architecture is how do I create an experience that will push mass adoption?
This is a common question with Web3, but also a broader topic for any service or product. The key to introduce any new idea is to link it to an existing behavior or product. This linking makes it easier for users to intuitively grasp the purpose and mechanisms necessary to use your product and decreases some of the adoption friction.
We are creatures of habit and the known is a comforting item in a world of unknowns. When we think of how different tech products are named this becomes clear. Bundles of images, text and links on the internet are called webpages because they structure and share information similar to how a page in a book would. Devices that allow us to take video and pictures, connect to the internet and make phone calls are called smart phones because they are phones with extended capabilities that allow them to capture and share far more information.
With this idea of wedding old and new, how do we transition Web2 users to be Web3 users? We can do this by leveraging existing tools such as user friendly UIs (user interface or clients) to allow users to perform smart contract actions. Very few people outside of developers are familiar with the structure of smart contracts or the technical specs of blockchains, but everyone is familiar with webpages. Because of this, the structure of a Web3 full stack app needs to have a front end (client).
The actual structure can get more complicated than just client and smart contract so we can look at a number of different simple approaches. There are three specific full stack smart contract app architectures that I’d like to discuss. The first one is the simplest and consists of a smart contract and a client:
With this architecture you have a smart contract that manages its own state and can interact with the blockchain. You attach a client that offers users the ability to change the smart contract’s state as well as view the current state. A good example of this could be buying and selling a token.
All the state of the token is stored on a smart contract, with all the buying and selling being recorded as transactions on the blockchain. By attaching a UI to the smart contract we can allow users to trade the coin without ever needing to know how we record token ownership. To them these transactions are the same as e-commerce or online banking (even though behind the scenes they are interacting with a blockchain instead of a traditional database).
The next structure adds another Web2 element. In this architecture we have a client that can talk to both a smart contract and a server:
Why would we use this structure when our last structure seems fully accommodating for our users? We would add a server to talk to the client if we want to add some sort of Web2 functionality to our UI. While smart contracts are great for managing decentralized, secure data, maybe we have information that we don’t want to have public, or we have a lot of data that wouldn’t be cost effective if it was all stored on a blockchain.
A good example of this would be an e-commerce site with blockchain payments. You would have a UI (client) for your users to be able to browse and purchase items. To be able to populate your store with these items you may store the items in a traditional database with records returned by a server. Finally we could receive tokens as payment and record purchases using our smart contracts.
We’ve talked about two of our structures, but what is the final common Web3 dApp architecture? The final architecture we’ll talk about is a client with a smart contract that is attached to a server. This architecture looks like this:
For this architecture we have our normal UI which can dictate when some actions are triggered on the smart contract, but now add the wrinkle that the smart contract will talk to a server to automatically complete transactions based on certain server responses.
There are a few terms that we will need to handle before continuing. The first set of terms are on-chain and off-chain storage. Like their names imply, on-chain storage is data stored on the blockchain and is handled by smart contracts. Off-chain storage is data stored in a traditional Web2 database and utilized in smart contracts to handle transactions. Oracles are the tools used to communicate with this off-chain storage.
In our final architecture our smart contracts talk to oracles to be able to get information for executing transactions. A great example of this could be a DeFi trading app. You may write a smart contract that allows users to deposit tokens in your app using a UI. This app will have a smart contract with a set of functions that trigger when certain real life events happened, mainly token price point changes.
How does the smart contract know when these price points have been hit? The smart contract will be able to determine what action to perform and when based off of the oracles that are feeding it information. The oracle will store price changes off-chain that can then be leveraged by the smart contract to run transactions and trade assets. This is another example of Web2 feeding the growth and evolution of Web3.
Conclusion
From a user experience standpoint, dApps shouldn’t be too different from our familiar Web2 apps. With the exclusion of smart contracts, wallets and underlying tokenomics, dApps use the same assortment of components to build apps that can display information to users, take and process user input, react to data inputs from external databases and store user data for further use. I hope that this article helped you think better about how to structure your next Web3 application.
