Time to Split Your Monorepo? Our Take on Structuring Web3 Project | by Břetislav Hájek | Apr, 2022

Why we cut up our monorepo and the way we deal with good contracts

First issues first, I believe it’s completely wonderful to place all code into one place, particularly at the beginning of the mission. Simply get issues executed. Don’t overcomplicate it. Nonetheless, ultimately, issues get difficult. Coping with good contracts is difficult as a result of as soon as deployed, they’re on the market, and updating isn’t all the time simple. Furthermore, different elements of your dApp want a contract code to work together with them. This text will current our code construction utilized in FELToken, which is able to hopefully make issues scalable and simple to keep up.

Every dApp often consists of two most important parts: good contracts and an internet software speaking with them. Typically further libraries are speaking with good contracts as nicely. To work together with good contracts, you all the time want the contract’s handle and ABI.

Dependency construction of many of the Web3 functions.

The dependency construction isn’t difficult. All parts rely on good contracts that retailer deployment addresses and contract’s ABI.

Wanting on the above construction, it’s clear that we should deal with the change of mandatory information if we cut up the parts. So why would we wish to separate issues? Why undergo this additional battle whereas we will hold every little thing in a single place?

The most important case in opposition to monorepo might be the versioning. If we replace one part, we regularly must replace different elements as nicely. We both must all the time make giant updates without delay or get used to the truth that typically issues are damaged in our most important department. When extra folks begin contributing, this turns into a problem as a result of we’d like a working mission for testing issues.

Furthermore, completely different parts have typically completely different versioning cycles, e.g. good contracts often don’t undergo as many updates as an internet software. Holding every little thing in a single place makes it tough to distinguish between these updates.

By splitting the code into a number of repositories, we will be sure that issues work at each improvement level. Moreover, we will use git tags for referencing right variations between repositories. For instance, after we replace good contracts, the net software can nonetheless reference the older model till it’s up to date. This method ensures that extra folks can work concurrently with out breaking issues.

We use Brownie for handing good contracts deployments. We additionally determined to make use of GitHub to change good contracts’ information (addresses and ABIs). It’s simple to create GitHub motion, which is able to robotically deploy good contracts and retailer the required information within the GitHub repo:

Then within the internet software, we will fetch mandatory information from GitHub based mostly on a tag. Tremendous easy proper? Effectively, there’s one final difficult half: native improvement.

Resolution for Native Improvement

Operating native Ganache blockchain is the each day bread of Web3 improvement. Operating good contracts and the net software concurrently is unavoidable. We have to be sure that we don’t complicate this by splitting code into a number of repositories.

We determined to unravel this utilizing a neighborhood file server. It’d sound a bit an excessive amount of, but it surely solves every little thing properly. So on the finish of our deployment script, we run a file server. Operating a file server in Python is straightforward as:

Then on the finish of the deployment script, we have to run server_build_directory(). Ensure that to run this perform on the absolute finish because it blocks the execution. You possibly can learn our full deployment script right here: deploy_dev.py. As soon as the server is operating, we will fetch the information the identical means as from GitHub. We simply want to interchange GitHub URL with http://localhost:8100. The construction of information stays the identical!

The beauty of this method is that Brownie robotically clears the native improvement information. Subsequently we don’t commit any of thelocal information into git.

Our method isn’t the one right one. I noticed folks use completely different methods to retailer good contracts, for instance, preserving them as an NPM bundle. This bundle is then put in into an internet software utilizing NPM. It’s fairly neat so long as all of your parts use JavaScript. The problem is that we now have each JavaScript and Python libraries speaking with good contracts, which makes language-specific options impractical.

Don’t overlook to observe for extra tutorials for those who discover this useful. I write about our web3 expertise all through the event of FELToken mission, making a privacy-preserving AI resolution.

More Posts