v4 Web Front End Deep Dive
As we approach the release of v4 mainnet open-source software, we want to provide a peek into what the dYdX team is building. We covered the v4 system architecture at a high level in a prior post here. This post dives into how the dYdX v4 open-source chain software’s (“dYdX Chain”) front end will work.
Given that v4 is still under development, please note that what is presented below is subject to change.
What Does the Web Front End Do?
The web front end provides an intuitive and performant UI/UX for traders who do not wish to interact with v4 programmatically. The web front end application will interact with the Indexer via APIs/websockets to fetch and display both on-chain and off-chain information (e.g., orderbook, account balances, etc.). Orders will be placed directly to validators.
dYdX is building three open-source front ends: a web app, an iOS app, and an Android app. We are also building Typescript and Python SDKs for power users/institutions. This post will primarily focus on the web app.
Deploying a Web Front End
dYdX will open source all front end codebases and associated deployment scripts. This will allow for anyone to easily deploy the dYdX front end via their own domain/hosting solution.
While only one deployment of the front end is needed for clients to use the web app, having multiple deployments will make v4 more decentralized. This is a key distinction from past versions of the protocol, and one we are particularly excited about; decentralized hosting will enable access to the v4 trading experience via multiple domains.
All of the web and mobile codebases will be hosted in open source GitHub repos. The web app is written in Typescript using React, while the Android and iOS apps are written in Kotlin and Swift, respectively. Business logic for the front end applications are shared across all platforms using packages written with Kotlin Multiplatform.
The front end deployment will leverage the following technologies and services:
- IPFS - p2p file sharing protocol for distributed file sharing/storage
- web3.storage - IPFS pinning service
- Cloudflare - IPFS gateway and DNS resolution
Any third party wishing to deploy and host a front end (“deployer”) will be able to do so by cloning the codebase from the Github repo, and running the deployment script. The deployment script will:
- Send and pin files to IPFS using web3.storage
- Retrieve the IPFS hash
- Update the DNS record of the domain name to the latest IPFS hash directly in Cloudflare (to ensure the latest content from IPFS is being pulled)
Content stored on IPFS will be accessible using the IPFS hash via any browser with native IPFS support (e.g., Brave or Opera), through a public IPFS gateway such as https://dweb.link or https://w3s.link/.
The deployment script is being built in a way to make hosting and updating the front end as easy as possible for deployers. The responsibilities of a deployer will include:
- Acquiring and owning web domain
- Meeting deployment prerequisites:
- Installing Node.js 16 and npm locally
- Setting up web3.storage account
- Setting up Cloudflare account
- Initial deployment of front end
- Download of front end codebase and deployment script from dYdX Github
- Running deployment script to pin the files to IPFS and update the IPFS hash
- Updating front end
- Following the dYdX Github repos to get codebase updates
- Running the deployment script when new codebase updates are available to pin the updated files to IPFS and update the IPFS hash
- Setup of ancillary accounts
.avif)