6 minutos
Como Implantar um Subgraph em Várias Redes
This page explains how to deploy a Subgraph to multiple networks. To deploy a Subgraph you need to first install the Graph CLI. If you have not created a Subgraph already, see Creating a Subgraph.
Deploying the Subgraph to multiple networks
In some cases, you will want to deploy the same Subgraph to multiple networks without duplicating all of its code. The main challenge that comes with this is that the contract addresses on these networks are different.
Como usar o graph-cli
Tanto o graph build
(desde a v0.29.0
) quanto o graph deploy
(desde a v0.32.0
) aceitam duas novas opções:
1Options:23 ...4 --network <name> Configuração de rede para usar no arquivo de config de redes5 --network-file <path> Local do arquivo de config de redes (padrão: "./networks.json")
You can use the --network
option to specify a network configuration from a json
standard file (defaults to networks.json
) to easily update your Subgraph during development.
Nota: O comando init
agora irá gerar um networks.json
automaticamente, com base na informação fornecida. Daí, será possível atualizar redes existentes ou adicionar redes novas.
Caso não tenha um arquivo networks.json
, você deve criar o mesmo manualmente, com a seguinte estrutura:
1{2 "network1": { // nome da rede3 "dataSource1": { // nome do dataSource4 "address": "0xabc...", // endereço do contrato (opcional)5 "startBlock": 123456 // bloco inicial (opcional)6 },7 "dataSource2": {8 "address": "0x123...",9 "startBlock": 12344410 }11 },12 "network2": {13 "dataSource1": {14 "address": "0x987...",15 "startBlock": 12316 },17 "dataSource2": {18 "address": "0xxyz..",19 "startBlock": 45620 }21 },22 ...23}
Nota: Não é necessário especificar quaisquer dos templates
(se tiver) no arquivo de configuração, apenas as dataSources
. Se houver templates
declarados no arquivo subgraph.yaml
, sua rede será automaticamente atualizada à especificada na opção --network
.
Now, let’s assume you want to be able to deploy your Subgraph to the mainnet
and sepolia
networks, and this is your subgraph.yaml
:
1# ...2dataSources:3 - kind: ethereum/contract4 name: Gravity5 network: mainnet6 source:7 address: '0x123...'8 abi: Gravity9 mapping:10 kind: ethereum/events
O seu arquivo de config de redes deve ficar assim:
1{2 "mainnet": {3 "Gravity": {4 "address": "0x123..."5 }6 },7 "sepolia": {8 "Gravity": {9 "address": "0xabc..."10 }11 }12}
Agora podemos executar um dos seguintes comandos:
1# Usar o arquivo networks.json padrão2yarn build --network sepolia34# Usar arquivo com nome personalizado5yarn build --network sepolia --network-file local/do/config
The build
command will update your subgraph.yaml
with the sepolia
configuration and then re-compile the Subgraph. Your subgraph.yaml
file now should look like this:
1# ...2dataSources:3 - kind: ethereum/contract4 name: Gravity5 network: sepolia6 source:7 address: '0xabc...'8 abi: Gravity9 mapping:10 kind: ethereum/events
Agora está tudo pronto para executar o yarn deploy
.
Nota: Como anteriormente mencionado, desde o graph-cli 0.32.0
, dá para executar diretamente o yarn deploy
com a opção --network
:
1# Usar o arquivo networks.json padrão2yarn deploy --network sepolia34# Usar arquivo com nome personalizado5yarn deploy --network sepolia --network-file local/do/config
Como usar o template subgraph.yaml
Uma forma de parametrizar aspetos, como endereços de contratos, com versões mais antigas de graph-cli
é: gerar partes dele com um sistema de modelos como o Mustache ou o Handlebars.
To illustrate this approach, let’s assume a Subgraph should be deployed to mainnet and Sepolia using different contract addresses. You could then define two config files providing the addresses for each network:
1{2 "network": "mainnet",3 "address": "0x123..."4}
e
1{2 "network": "sepolia",3 "address": "0xabc..."4}
Além disso, dá para substituir o nome da rede e os endereços no manifest com variáveis temporários {{network}}
and {{address}}
e renomear o manifest para, por exemplo, subgraph.template.yaml
:
1# ...2dataSources:3 - kind: ethereum/contract4 name: Gravity5 network: mainnet6 network: {{network}}7 source:8 address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'9 address: '{{address}}'10 abi: Gravity11 mapping:12 kind: ethereum/events
Para poder gerar um manifest para uma rede, pode-se adicionar mais dois comandos ao package.json
com uma dependência no mustache
:
1{2 ...3 "scripts": {4 ...5 "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",6 "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"7 },8 "devDependencies": {9 ...10 "mustache": "^3.1.0"11 }12}
To deploy this Subgraph for mainnet or Sepolia you would now simply run one of the two following commands:
1# Mainnet:2yarn prepare:mainnet && yarn deploy34# Sepolia:5yarn prepare:sepolia && yarn deploy
Veja um exemplo funcional aqui.
Observe: Este método também pode ser aplicado a situações mais complexas, onde é necessário substituir mais que endereços de contratos e nomes de redes, ou gerar mapeamentos e ABIs de templates também.
This will give you the chainHeadBlock
which you can compare with the latestBlock
on your Subgraph to check if it is running behind. synced
informs if the Subgraph has ever caught up to the chain. health
can currently take the values of healthy
if no errors occurred, or failed
if there was an error which halted the progress of the Subgraph. In this case, you can check the fatalError
field for details on this error.
Subgraph Studio Subgraph archive policy
A Subgraph version in Studio is archived if and only if it meets the following criteria:
- A versão não foi publicada na rede (ou tem a publicação pendente)
- A versão foi criada há 45 dias ou mais
- The Subgraph hasn’t been queried in 30 days
In addition, when a new version is deployed, if the Subgraph has not been published, then the N-2 version of the Subgraph is archived.
Every Subgraph affected with this policy has an option to bring the version in question back.
Checking Subgraph health
If a Subgraph syncs successfully, that is a good sign that it will continue to run well forever. However, new triggers on the network might cause your Subgraph to hit an untested error condition or it may start to fall behind due to performance issues or issues with the node operators.
Graph Node exposes a GraphQL endpoint which you can query to check the status of your Subgraph. On the hosted service, it is available at https://api.thegraph.com/index-node/graphql
. On a local node, it is available on port 8030/graphql
by default. The full schema for this endpoint can be found here. Here is an example query that checks the status of the current version of a Subgraph:
1{2 indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {3 synced4 health5 fatalError {6 message7 block {8 number9 hash10 }11 handler12 }13 chains {14 chainHeadBlock {15 number16 }17 latestBlock {18 number19 }20 }21 }22}
This will give you the chainHeadBlock
which you can compare with the latestBlock
on your Subgraph to check if it is running behind. synced
informs if the Subgraph has ever caught up to the chain. health
can currently take the values of healthy
if no errors occurred, or failed
if there was an error which halted the progress of the Subgraph. In this case, you can check the fatalError
field for details on this error.