In the last few quarters, the liquidX studio’s engineering team has built and shipped several smart contracts and web3 apps for our community. This journey has been challenging since the product, our team, and the technology are all new and evolving.
During development, we had to make choices among the technology, the architecture, the libraries, and the infrastructure. Like most engineering choices, all of these decisions involve tradeoffs that affect the effectiveness and efficiency of the engineering team and the organization as a whole. We have primarily considered quality, speed, and cost during our decision-making process.
Although quality is on the top of the list of any software product, it is critical for web3 apps. The functionalities and bugs often have negative impact on the consumers’ confidence and valuation of the products. Furthermore, due to the financial nature of the transactions, critical bugs and hacks that negatively impact the transactions translate into real-world loss of financial assets. So, our first goal was to promote testability and high QoS across all of our apps, services, and smart contracts.
Startups tend to try out a lot of ideas and refine / extend such ideas in a fast-paced manner. Our goal was to shorten the go-to-market time with our engineering team.
Optimizing the cost of building an engineering team, development, maintenance, and infrastructure remains a top priority for us. We have chosen language/framework that allowed us to choose from a large pool of engineers thereby easing our team formation process. Furthermore, we have chosen the infrastructure design that keeps the cost down during development and the overall lifecycle of our products.
For building the web apps and services we primarily use Typescript for the following reasons:
For writing smart contracts, we use Solidity. The smart contracts are developed and tested in the Hardhat environment. All smart contracts that are shipped are audited by third party vendor Solidity Finance.
We have chosen Github for storing our codebase. Our code lives on a main branch with a trunk-based model. The pull-requests to update the main branch abide by the branch protection rules that specify the number of required reviewers and allows us to connect the CI/CD workflows that run the unit tests to preserve code coverage.
We have chosen to use AWS public cloud to host our services. Our infrastructure has been designed that provides a delivery/upgrade pipeline that is easy to maintain, high availability, and optimized cost.
We follow the GitOps model of building the CI/CD pipeline. When a change is made within our main branch the CircleCI workflow pipeline is triggered. That pipeline builds the app image which is downloaded by ArgoCD server to the Kubernetes container.