The Solution to Maintaining Clean Web3 Code
Separate Front-End and Smart Contracts Code
I have come across many examples of Web3 dApps where both front-end code and smart contract code are put together, in the same repository. I am here to tell you that this is a bad idea. Especially if you are looking to write maintainable quality code as a software developer.
Both the front-end application and smart contracts are different sides of the same coin, they both have to work in harmony. But, both are different beasts with different requirements.
Common Pitfalls
Think of your smart contracts as your back-end code, which needs to interact with your front-end application.
Putting both the back-end code and front-end code in the same repository can cause a lot of maintainability and scalability issues in the future. Avoid these pitfalls.
Bottleneck
Assuming that you are a wonderful developer and are writing tests for both your front-end app and smart contracts. If front-end tests are broken, now the development of your smart contracts has halted. The same can be said the other way around.
Even though both your front-end app and smart contracts need to work in harmony for your dApp, they can be treated as two separate entities. They both have different requirements and grow at different rates. Keep them separate.
Scalability
As you develop successful dApps and would like to expand to other chains, you will need to change your smart contracts. This new chain may not be an EVM chain, perhaps you’ll need to write smart contracts in Rust which is a completely different language.
With this above scenario, you will run into scalability issues as you try to grow your dApp with this infrastructure. It would be far better to separate smart contracts in a different repository.
Your front-end app can remain constant, though flexible enough to point to different smart contracts depending on the selected chain. Smart contracts can differ a lot from chain to chain. Best to keep them separate.
Unnecessary Clutter
Last but not least, your code is carrying unnecessary weight. Your front-end code has all the smart contract code it doesn’t need, and your smart contract app is unnecessarily bloated because of the front-end code.
You need to focus on creating nimble apps and cutting unnecessary weight. This will give you maintainable apps and help grow your app faster as more developers join your team.
How to Separate the Two
The ideal setup would be to have 2 separate repositories, one for your front-end app and one for your smart contracts. Both should be packaged separately.
Initial Setup
This is probably the tricky part. First, you need to pick which NPM Registry you are going to use. You can use the public npm registry, GitHub registry, or any of your liking.
The flow is this:
- Package smart contract artifact
- Push smart contract artifact to the Registry
- Use the smart contract artifact in your front-end app as a dependency. This is where you will need to use the ABIs
- Package front-end artifact
- Push front-end artifact to the Registry
If you do use GitHub, then it would make sense to use their Registry service as well. Below is a visual illustration of how it would work.
GitHub the Easy Answer
I would strongly recommend setting up GitHub repositories and using the GitHub Registry to store your artifacts. It’s free and the flow becomes very simple.
Set up GitHub actions to build artifacts and push them to the GitHub Registry. I would suggest for both repositories, setting up this entire pipeline. Once you have this working, the next steps will become much easier.
Use Smart Contracts in Front-End
Just like you use any other NPM dependency in your front-end app, you will use your smart contract artifact as a dependency.
The only difference here is that you will be pulling the smart contract artifact from your own GitHub Registry. Here is the full GitHub guide.
Now what?
Now you have successfully set up your pipeline in GitHub. You are using GitHub Registry to store your artifacts. The Smart Contract artifact is a dependency for your front-end application, from which you pull and use the ABIs.
In conclusion, your front-end app and smart contracts should be packaged separately. These are 2 individual parts that run separately in different environments. It is the interaction of the two that results in a dApp.
The separation of the two packages keeps software development simple and refined. These packages can also be reused and repurposed in the future as needed.
Happy building maintainable dApps!
