Member-only story
Time to Split Your Monorepo? Our Take on Structuring Web3 Project
Why we split our monorepo and how we handle smart contracts
First things first, I think it’s totally fine to put all code into one place, especially at the start of the project. Just get things done. Don’t overcomplicate it. However, eventually, things get complicated. Dealing with smart contracts is tricky because once deployed, they are out there, and updating isn’t always easy. Moreover, other parts of your dApp need a contract code to interact with them. This article will present our code structure used in FELToken, which will hopefully make things scalable and easy to maintain.
Main Components
Each dApp usually consists of 2 main components: smart contracts and a web application communicating with them. Often additional libraries are communicating with smart contracts as well. To interact with smart contracts, you always need the contract’s address and ABI.
The dependency structure isn’t complicated. All components depend on smart contracts that store deployment addresses and contract’s ABI.
Why not Monorepo?
Looking at the above structure, it’s clear that we will have to handle the exchange of necessary files if we split the components. So why would we want to separate things? Why go through this extra struggle while we can keep everything in one place?
The biggest case against monorepo is probably the versioning. If we update one component, we often have to update other parts as well. We either have to always make large updates at once or get used to the fact that often things are broken in our main branch. When more people start contributing, this becomes an issue because we need a working project for testing things.
Moreover, different components have often different versioning cycles, e.g. smart contracts usually don’t go through as many updates as a web application. Keeping everything in one place makes it difficult to differentiate between these updates.
