Skip to content

How to add a feature?

The project structure

In this section we will walk you through the main files and folders of the project. In the following tree you'll find the main documents to pay attention to, the rest of the files and folders might be automatically generated or a bit advanced for this guide:

📦smart-contracts
┣ 📂contracts
┃ ┗ 📜CaseRegistry.sol
┣ 📂deploy
┃ ┗ 📜rinkeby.js
┣ 📂deployments
┃ ┗ 📂rinkeby
┃ ┃ ┣ 📂solcInputs
┃ ┃ ┣ 📜.chainId
┃ ┃ ┗ 📜CaseRegistry.json
┣ 📂test
┃ ┗ 📜CaseResgistry.js
┣ 📜.env
┣ 📜.env.example
┣ 📜.gitignore
┣ 📜hardhat.config.js
┗ 📜package.json

/contracts/CaseRegistry.sol

The smart contract used to store the cases data.

/test/CaseRegistry.js

The tests for the smart contract.

/deploy/rinkeby/CaseRegistry.json

The resulting json file from deployment. Contains the abi, receipt, owner address and more.

/deployments/rinkeby.js

The deploy script.

/hardhat.config.js

Configuration file for hardhat plugins, accounts, providers and networks.

/.env

Secrets file to inject through environment variables.

Developing smart contracts

For local development of smart contracts we use the Hardhart framework. The main difference between Hardhat and other frameworks like Truffle is that Hardhat is modular and agnostic of the workflow, therefore it is an open framework that embracess the development of plugins by the community so that each project can use the technologies they want. Thats why Hardhat has a built in package manager (similar to npm), yo can find the available plugins in the plugins page of the documentation. We use Ethers.js (hardhat-ethers plugin ) along with Waffle as a testing framework (@nomiclabs/hardhat-waffle plugin) which uses Mocha to structure the tests (describe, it, etc.) and Chai as an assertion library (expect, to, equal, etc.). Complete introduction to Hardhat tutorial, very recommended.

The flow for this process is:

  1. Write/edit the smart contract, smart-contracts/contracts/Contract.sol.
  2. Write/update the tests, smart-contracts/test/Contract.js.
  3. Run the tests in a local development blockchain using Hardhat. Run the command npx hardhat test.

Once we have tested our smart contract in a local blockchain, its time to deploy it in a public one. There are two ways to do this:

  • Have a node of a public blockchain, Ethereum in our case, and deploy the sc through it.

  • Connect to the blockchain through a provider.

In this case we are going to use Infura, a very well known provider from the blockchain ecosystem. In order to do so we first need to sign up in the Infura platform so we can create a new project, find more information in this guide: Getting started with Infura. Projects in Infura help you tracking the requests made by your dApp to the network. The platform provides an APIkey and Id for the project so that every time a request gets to the provider the client has to authenticate.

Once you have created a project, you have to configure Hardhat. You can add multiple providers to the config file and Hardhat will automatically switch from one to another in case of connection loss. In the section 7 of the Hardhat tutorial you'll find more info about configuring a provider.

You also need to specify the target network, Rinkeby in our case, and the deployer account. For the Ethereum account (EOA) we use Metamask as wallet.

In order to get some funds for the testnet you need to request them through a faucet. For the Rinkeby network you can use:

Last but not least, it is very important not to publish sensitive information like your Infura project ID or APIkey aswell as your wallet secrets. In order to avoid that we use the dotenv library to write our secrets in a local file (.env) that will load the info in Hardhat. In the dotenv package description page you'll find the necessary information to use it. Use .gitignore to avoid tracking the file and publishing it to your git repo.

  1. Write/update the deploy script, smart-contracts/deploy/target-network.js.
  2. Prepare the .env file with APIkeys and secrets aswell as the hardhat.config.js file. Both in the smart-contracts folder.
  3. Deploy the smart contract. Run npx hardhat deploy. The resulting .json of the deploy is stored in smart-contracts/deployments/target-network/.

Creating a test subgraph

The Graph is a p2p network in which nodes index events from smart contracts deployed in the Ethereum network. The Graph can be thought as a protocol to decentralize this task, therefore decentralizing some of the functionalities given by Etherscan for example read more about it in this article.

The first thing we need to do is to register a subgrah, this can be done thre the Subgraph Studio platform. Once the subgraph is registered we can start initializing it through the command line. Check this guide for Publishing subgraphs in Subgraph Studio.

Una vez inicializado el proyecto debemos realizar algunas configuraciones básicas. Un detalle importante a recordar es que el subgrafo tiene un parámetro para configurar el bloque desde el que empieza a indexar, este parámetro debemos fijarlo en el bloque en el que desplegamos nuestro contrato, podemos consultar en Etherscan metiendo la dirección del contrato desplegado en el buscador de la red pertinente, en nuestro caso Rinkeby.

A continuación, definimos las entidades y funciones encargadas de indexar los datos de los eventos. En concreto, las funciones encargadas de indexar los eventos a través de entidades, se encuentran en el archivo src → mappings.ts y están escritos en AssemblyScript, una pequeña capa de abstracción sobre WebAssembly para conseguir una sintaxis más familiar. Se trata de un lenguaje en proceso de desarrollo (a Julio 2021) ya que depende totalmente de WebAssembly que también está en una fase poco madura. Por ello, a la hora de desarrollar el subgrafo es más sencillo limitarse a ejemplos ya testeados.

Finalmente obtenemos nuestro subgrafo.

Last update: 2022-05-23