0xNelliI built an Onchain App: Front-end - Part 1
The code for the first stage of development explored in this article can be found here. Please use this to provide additional context in the event that any parts of this article are unclear. Additionally, if aspects of this article are unclear or do not follow best practices please let me on 𝕏.Project SetupSvelteKit InitialisationAs aforementioned in the previous article, I am using SvelteKit to build out my frontend. It is important to note that while Svelte recently announced the release o...
0xNelliTransparent Proxies & Upgradeability
The Goal of the Proxy PatternSmart contracts are immutable, therefore it is not possible to change the logic of a smart contract once it has been deployed. However, the ability to update code is often vital, whether to add new features or to patch critical bugs and defects. This is what the proxy pattern offers to developers, a means of updating code by introducing upgradeability to smart contracts. Upgradeability is achieved by separating storage and logic. A proxy contract contains the stat...
Fledging Security Researcher | Software Engineer | Onchain Enthusiast
0xNelliI built an Onchain App: Front-end - Part 1
The code for the first stage of development explored in this article can be found here. Please use this to provide additional context in the event that any parts of this article are unclear. Additionally, if aspects of this article are unclear or do not follow best practices please let me on 𝕏.Project SetupSvelteKit InitialisationAs aforementioned in the previous article, I am using SvelteKit to build out my frontend. It is important to note that while Svelte recently announced the release o...
0xNelliTransparent Proxies & Upgradeability
The Goal of the Proxy PatternSmart contracts are immutable, therefore it is not possible to change the logic of a smart contract once it has been deployed. However, the ability to update code is often vital, whether to add new features or to patch critical bugs and defects. This is what the proxy pattern offers to developers, a means of updating code by introducing upgradeability to smart contracts. Upgradeability is achieved by separating storage and logic. A proxy contract contains the stat...
Share Dialog
Share Dialog
Fledging Security Researcher | Software Engineer | Onchain Enthusiast
Subscribe to 0xNelli
Subscribe to 0xNelli
<100 subscribers
<100 subscribers
As a long-time onchain enthusiast who has been dabbling in DeFi and battling with Metamask since 2020; I have always marvelled at the premier onchain apps. Apps like AAVE and UniSwap are so clean and always iterating and improving. Furthermore and perhaps most importantly, in the most adversarial environment imaginable with billions of dollars at stake, these apps have never been exploited.
*I hope I didn’t just jinx that😬🤞*
But since I have started using these applications, I have graduated from university as a software engineer and have a few years of experience under my belt, I no longer marvel at onchain apps. Now they pique my curiosity. What goes into creating an onchain app? What is the best way to build one? How much effort does it take to go from nothing to a URL that hosts a clean frontend that allows users to interact with a decentralised protocol? I needed to find out, so that’s why I built an onchain app.
Ultimately the idea doesn’t matter too much here. The purpose of this project is to understand how to build the thing, rather than building the thing itself. I know, I know if you are passionate about the application you are building, the odds of you completing it dramatically increase. But you know what, I am passionate about learning so that’ll suffice.
So what am I building?
Anyone who has attempted to develop anything onchain would have undoubtedly come across the man himself Patrick Collins. The content he has created is at the pinnacle of onchain development and security, I strongly recommend you check it out.
As a long-time onchain enthusiast who has been dabbling in DeFi and battling with Metamask since 2020; I have always marvelled at the premier onchain apps. Apps like AAVE and UniSwap are so clean and always iterating and improving. Furthermore and perhaps most importantly, in the most adversarial environment imaginable with billions of dollars at stake, these apps have never been exploited.
*I hope I didn’t just jinx that😬🤞*
But since I have started using these applications, I have graduated from university as a software engineer and have a few years of experience under my belt, I no longer marvel at onchain apps. Now they pique my curiosity. What goes into creating an onchain app? What is the best way to build one? How much effort does it take to go from nothing to a URL that hosts a clean frontend that allows users to interact with a decentralised protocol? I needed to find out, so that’s why I built an onchain app.
Ultimately the idea doesn’t matter too much here. The purpose of this project is to understand how to build the thing, rather than building the thing itself. I know, I know if you are passionate about the application you are building, the odds of you completing it dramatically increase. But you know what, I am passionate about learning so that’ll suffice.
So what am I building?
Anyone who has attempted to develop anything onchain would have undoubtedly come across the man himself Patrick Collins. The content he has created is at the pinnacle of onchain development and security, I strongly recommend you check it out.
Shenanigans aside, I thought I would extend the capabilities of this project to scale to multiple users being able to create different fund-raises that anyone with a Metamask can contribute to. To build a Kickstarter-esque onchain application.
And with that decision made, it became time to select the tech stack I would use to create my new app, Go Fund Yourself.
In this day and age, there is certainly no shortage of frontend frameworks to choose from. I personally use VueJs at work, so I ruled it out as I wanted to try something new. Based on the docs for different onchain libraries (more on this later), NextJs and React seem to be the most popular. While these frameworks will undoubtedly boost your employability, the contrarian within me wouldn’t allow it. Also as someone who uses VueJs regularly, I really do enjoy the templating in a vue component as opposed to JSX, so that played a factor too.
I ultimately opted for SvelteKit. I get templating syntax which is my preference. Additionally, I wanted to try a meta-framework to better understand their strengths and weaknesses and familiarise myself with the server and client-side separations when developing components. Moreover, Svelte is consistently voted as one of the most admired frontend frameworks by developer surveys and I’m a big fan of Svelte’s philosophy:
“Svelte is a superset of HTML” - Rich Harris (Svelte Founder)
Some front-end frameworks stray far from the idiomatic HTML, JavaScript & CSS that I first used to create simple websites. It was with these languages that I first fell in love with coding. I wanted to see if Svelte made good on its promise of simplicity and idiomatic use of the aforementioned languages and could emulate that feeling of when I first started building websites.
For more info on Svelte, I strongly recommend checking out RIch’s interviews with the Primeagean and Prismic. Additionally, the man himself Patrick Collins made a stream for web3 front-end development and he was using SvelteKit, I saw this as a good omen, how could I not give Svelte a crack?
You might be thinking, what on Earth is an onchain library? These are JavaScript libraries that provide utilities for all types of interactions with blockchains. These libraries greatly simplify the process of reading/writing from/to smart contracts, managing wallet connections and updating the state of your application accordingly.
As far as I am aware, there are three major EVM libraries to consider:
Each has its pros and cons. There’s a fantastic article on Sveltekit.io that breaks down the different library alternatives when creating an onchain SvelteKit app. Strongly recommend you check it out.
But I’ll break down my decision for you here quickly:
Web3.js is the most mature of the three and offers a rich set of features. However, it is quite a large bundle and is not quite as performant as the other options.
Ethers.js I have worked with in the past and found the DX to be okay, it is more performant than Web3.js, but lacks certain utilities that are offered by Wagmi.
Wagmi has both good performance and a rich set of utilities. Furthermore, it is rapidly gaining in popularity and is used by some of the biggest projects in the onchain world.
I ultimately chose Wagmi. It’s important to note when using Svelte it will be the Wagmi core JS library that will power onchain interactions. There are specific libraries for React and Vue that offer hooks or composables, but these of course are of no use to us. However, there is an unofficial SvelteKit-specific library that has received high praise from Svelte developers. It offers Wagmi stores that simplify integrating Wagmi into your Svelte app, which I did take advantage of.
If you are developing anything that is connected to a blockchain you will need a RPC (Remote Procedure Call). At a high level, RPC is a protocol that allows a client (you or your app) to perform operations on a server (the blockchain).
There are two major service providers that I am aware of for this: Infura and Alchemy. I have used Alchemy previously and reused an RPC that I created previously, but I urge you to investigate both and choose the best option for you.
The backend for this app is the blockchain, obviously! But which one?
The first decision is whether to deploy the contracts to a testnet or mainnet. The former does not use real assets of value whereas the latter does. I decided for my first onchain app to deploy to a testnet while learning the ropes, ensuring my own or any potential user funds are not in jeopardy. After all, this is a learning exercise.
Next decision which testnet? For this I decided to stick with Ethereum Sepolia, as it has all the integrations with major service providers you can ask for, like Alchemy and Chainlink. Also procuring Sepolia testnet eth to make transactions is pretty straightforward as there are plenty of faucets available.
Finally, I decided that I did not want all the data this app collects to be stored onchain. I used an SQLite database to store the descriptions of why each user is raising funds for their fund-raise. Storing this information on a db saves the users on gas fees. Additionally, I wanted the experience of working with SvelteKit and SQLite. I wanted to learn the pitfalls and proper patterns involved in CRUD operations with a frontend meta-framework and a db.
“Work incredibly hard in order to be incredibly lazy“ - Patick Collins
I absolutely love this quote from Patrick. It captures the essence and ethos of software development so well. As a software engineer, you want to work exceedingly hard to automate your workflow as much as possible, so you can be lazy when developing. ‘Lazy’ meaning you can focus on only delivering value; as the tedious work that needs to be done around shipping is taken care of for you.
How does this translate to the Go Fund Yourself app?
I would like to set up the project so that any changes I push to the main branch of my repo are automatically deployed into production and accessible to users nearly immediately after I make these changes. This pertains to the changes made to the frontend, not the smart contracts which are immutable.
This raises the question of how am I hosting my frontend? After listening to the Lex Fridman podcast with Peter Levels, I was inspired to learn how to host my own applications on a VPS. There are a plethora of services that simplify the deployment and hosting process, however, according to this podcast it seems that Peter runs an entire empire using some VPS’ and Nginx. Furthermore, the hallmark of a great software engineer is the ability to rawdog it rather than using the latest abstracted solution.
So the DevOps requirement of this project is to spin up a VPS, set it up to run my SvelteKit application and then create a pipeline to allow the latest changes I have made to automatically be detected by the server, pulled in and then run so that they are accessible to the end users.
To achieve this I chose Hostinger for the VPS, Nginx for a reverse proxy, Certbot for SSL certificates to enable https and GitHub actions and Docker to create the pipeline.
The purpose of this article was to explain the motivation for building Go Fund Yourself and the reasoning that went into selecting the different technologies in the tech stack.
While this started as an exercise to understand the process of onchain app development, I admittedly increased the scope of the project to include aspects of Web2 development that I haven’t had much experience in yet. I could have stored all the information about fund-raises on the blockchain, however, I chose to include an SQLite db, because I have never worked with this database before. Additionally, I wanted to understand the process of using a front-end meta-framework with a db. For deployment, I could have used Vercel or another similar service, however, I wanted to understand what it took to configure your own server and pipelines to better comprehend why these abstracted solutions have gained so much popularity. Is setting up your own server worth the heartache or should you just use Vercel? What are the tradeoffs? These are the questions I was seeking to answer.
This is just the first article in a series I am working on. Now that you know my thought process, I look forward to sharing with you how I built Go Fund Yourself. In this series, I will explore the pitfalls and learnings of each stage of the development process. I hope you can use this series to gain a better understanding of onchain development, as a blueprint to build your own onchain app or even as a tutorial to add to your portfolio on GitHub.
Make sure you subscribe to ensure you do not miss new instalments of this series:
And please feel free to mint to show support:
Look forward to seeing you in the next article where I delve into SvelteKit and front-end development. 👋
Shenanigans aside, I thought I would extend the capabilities of this project to scale to multiple users being able to create different fund-raises that anyone with a Metamask can contribute to. To build a Kickstarter-esque onchain application.
And with that decision made, it became time to select the tech stack I would use to create my new app, Go Fund Yourself.
In this day and age, there is certainly no shortage of frontend frameworks to choose from. I personally use VueJs at work, so I ruled it out as I wanted to try something new. Based on the docs for different onchain libraries (more on this later), NextJs and React seem to be the most popular. While these frameworks will undoubtedly boost your employability, the contrarian within me wouldn’t allow it. Also as someone who uses VueJs regularly, I really do enjoy the templating in a vue component as opposed to JSX, so that played a factor too.
I ultimately opted for SvelteKit. I get templating syntax which is my preference. Additionally, I wanted to try a meta-framework to better understand their strengths and weaknesses and familiarise myself with the server and client-side separations when developing components. Moreover, Svelte is consistently voted as one of the most admired frontend frameworks by developer surveys and I’m a big fan of Svelte’s philosophy:
“Svelte is a superset of HTML” - Rich Harris (Svelte Founder)
Some front-end frameworks stray far from the idiomatic HTML, JavaScript & CSS that I first used to create simple websites. It was with these languages that I first fell in love with coding. I wanted to see if Svelte made good on its promise of simplicity and idiomatic use of the aforementioned languages and could emulate that feeling of when I first started building websites.
For more info on Svelte, I strongly recommend checking out RIch’s interviews with the Primeagean and Prismic. Additionally, the man himself Patrick Collins made a stream for web3 front-end development and he was using SvelteKit, I saw this as a good omen, how could I not give Svelte a crack?
You might be thinking, what on Earth is an onchain library? These are JavaScript libraries that provide utilities for all types of interactions with blockchains. These libraries greatly simplify the process of reading/writing from/to smart contracts, managing wallet connections and updating the state of your application accordingly.
As far as I am aware, there are three major EVM libraries to consider:
Each has its pros and cons. There’s a fantastic article on Sveltekit.io that breaks down the different library alternatives when creating an onchain SvelteKit app. Strongly recommend you check it out.
But I’ll break down my decision for you here quickly:
Web3.js is the most mature of the three and offers a rich set of features. However, it is quite a large bundle and is not quite as performant as the other options.
Ethers.js I have worked with in the past and found the DX to be okay, it is more performant than Web3.js, but lacks certain utilities that are offered by Wagmi.
Wagmi has both good performance and a rich set of utilities. Furthermore, it is rapidly gaining in popularity and is used by some of the biggest projects in the onchain world.
I ultimately chose Wagmi. It’s important to note when using Svelte it will be the Wagmi core JS library that will power onchain interactions. There are specific libraries for React and Vue that offer hooks or composables, but these of course are of no use to us. However, there is an unofficial SvelteKit-specific library that has received high praise from Svelte developers. It offers Wagmi stores that simplify integrating Wagmi into your Svelte app, which I did take advantage of.
If you are developing anything that is connected to a blockchain you will need a RPC (Remote Procedure Call). At a high level, RPC is a protocol that allows a client (you or your app) to perform operations on a server (the blockchain).
There are two major service providers that I am aware of for this: Infura and Alchemy. I have used Alchemy previously and reused an RPC that I created previously, but I urge you to investigate both and choose the best option for you.
The backend for this app is the blockchain, obviously! But which one?
The first decision is whether to deploy the contracts to a testnet or mainnet. The former does not use real assets of value whereas the latter does. I decided for my first onchain app to deploy to a testnet while learning the ropes, ensuring my own or any potential user funds are not in jeopardy. After all, this is a learning exercise.
Next decision which testnet? For this I decided to stick with Ethereum Sepolia, as it has all the integrations with major service providers you can ask for, like Alchemy and Chainlink. Also procuring Sepolia testnet eth to make transactions is pretty straightforward as there are plenty of faucets available.
Finally, I decided that I did not want all the data this app collects to be stored onchain. I used an SQLite database to store the descriptions of why each user is raising funds for their fund-raise. Storing this information on a db saves the users on gas fees. Additionally, I wanted the experience of working with SvelteKit and SQLite. I wanted to learn the pitfalls and proper patterns involved in CRUD operations with a frontend meta-framework and a db.
“Work incredibly hard in order to be incredibly lazy“ - Patick Collins
I absolutely love this quote from Patrick. It captures the essence and ethos of software development so well. As a software engineer, you want to work exceedingly hard to automate your workflow as much as possible, so you can be lazy when developing. ‘Lazy’ meaning you can focus on only delivering value; as the tedious work that needs to be done around shipping is taken care of for you.
How does this translate to the Go Fund Yourself app?
I would like to set up the project so that any changes I push to the main branch of my repo are automatically deployed into production and accessible to users nearly immediately after I make these changes. This pertains to the changes made to the frontend, not the smart contracts which are immutable.
This raises the question of how am I hosting my frontend? After listening to the Lex Fridman podcast with Peter Levels, I was inspired to learn how to host my own applications on a VPS. There are a plethora of services that simplify the deployment and hosting process, however, according to this podcast it seems that Peter runs an entire empire using some VPS’ and Nginx. Furthermore, the hallmark of a great software engineer is the ability to rawdog it rather than using the latest abstracted solution.
So the DevOps requirement of this project is to spin up a VPS, set it up to run my SvelteKit application and then create a pipeline to allow the latest changes I have made to automatically be detected by the server, pulled in and then run so that they are accessible to the end users.
To achieve this I chose Hostinger for the VPS, Nginx for a reverse proxy, Certbot for SSL certificates to enable https and GitHub actions and Docker to create the pipeline.
The purpose of this article was to explain the motivation for building Go Fund Yourself and the reasoning that went into selecting the different technologies in the tech stack.
While this started as an exercise to understand the process of onchain app development, I admittedly increased the scope of the project to include aspects of Web2 development that I haven’t had much experience in yet. I could have stored all the information about fund-raises on the blockchain, however, I chose to include an SQLite db, because I have never worked with this database before. Additionally, I wanted to understand the process of using a front-end meta-framework with a db. For deployment, I could have used Vercel or another similar service, however, I wanted to understand what it took to configure your own server and pipelines to better comprehend why these abstracted solutions have gained so much popularity. Is setting up your own server worth the heartache or should you just use Vercel? What are the tradeoffs? These are the questions I was seeking to answer.
This is just the first article in a series I am working on. Now that you know my thought process, I look forward to sharing with you how I built Go Fund Yourself. In this series, I will explore the pitfalls and learnings of each stage of the development process. I hope you can use this series to gain a better understanding of onchain development, as a blueprint to build your own onchain app or even as a tutorial to add to your portfolio on GitHub.
Make sure you subscribe to ensure you do not miss new instalments of this series:
And please feel free to mint to show support:
Look forward to seeing you in the next article where I delve into SvelteKit and front-end development. 👋
No activity yet