Desenvolvimento de subgrafos locais para economia de tempo e sanidade

image

Se você está pensando em adicionar um subgrafo para seu Dapp por meio do The Graph ou já o fez, mas seu ciclo de desenvolvimento envolve a implantação em uma rede de teste em execução para testar seus contratos e/ou alterações de subgráfico, convém considerar a execução da pilha localmente.

Executando um Truffle, Ganache & pilha de subgrafos localmente deve acelerar o desenvolvimento de Dapp à medida que os resultados de suas mudanças de Dapp surgem mais rapidamente. Com tempos de implantação mais rápidos, blocos sendo minerados instantaneamente, você deve ver um fluxo de dados mais rápido para o subgráfico do seu Dapp e, por extensão, para sua API ou front-end.

Há uma série de etapas envolvidas na configuração desta pilha local que vamos percorrer com você, bem como alguns pensamentos sobre como o processo pode ser melhorado. Os passos abaixo seguem os documentos oficiais do Graph que podem ser encontrados aqui.

Pré-requisitos

São 3 pré-requisitos para este tutorial que é você ter um blockchain Ganache Ethereum local, Docker instalado e um projeto de subgráfico já inicializado para o seu dapp.

Existem 2 opções quando se trata de Ganache, um aplicativo com uma boa interface do usuário e um aplicativo CLI que podemos executar a partir do terminal / prompt de comando. Para os fins deste tutorial, usaremos a CLI. Se você deseja usar o aplicativo, apenas certifique-se de que ele esteja configurado com os mesmos parâmetros que a CLI.

Primeira ordem de negócios, instale a CLI globalmente se você ainda não tiver:

npm install -g ganache-cli

Instruções de instalação do Docker: https://docs.docker.com/get-docker/

Criando um projeto de subgrafo: https://thegraph.com/docs/define-a-subgraph#create-a-subgraph-project

Etapa 1: Ganache e parâmetros necessários

Com instalado, podemos girar uma cadeia local com o seguinte comando:ganache-cli

ganache-cli -h 0.0.0.0

Isso deve ser tudo o que você precisa para começar esta pilha em andamento. Por padrão, o host é normalmente, mas substituindo isso para nós vinculamos o serviço a todas as interfaces, o que significa que nosso nó gráfico local, que é executado em um contêiner docker, será capaz de falar com nosso blockchain local.127.0.0.10.0.0.0

Devido ao desenvolvimento regular com o , eu executo a CLI com mais opções da seguinte maneira:ganache-cli

ganache-cli -h 0.0.0.0 -m "MNEMONIC_HERE" -i 5777

As 2 opções extras envolvem passar um ID mnemônico e de cadeia, respectivamente. Isso me permite importar as chaves privadas de qualquer conta uma vez para a metamask e o ID da cadeia me permite ter uma configuração estática para minha cadeia local dentro da metamask — a CLI tende a gerar uma nova ID de cadeia toda vez que o contrário.

Você saberá se a CLI está em execução quando a seguinte for uma das últimas mensagens impressas no console:

Listening on 0.0.0.0:8545

Com isso confirmado, agora você precisa migrar/implantar seus contratos na cadeia local com o comando apropriado.truffle migrate

Etapa 2: Executando um nó gráfico local

Este pouco pode ser um pouco temperamental, então despojado com ele - você pode precisar de algumas tentativas antes de começar isso.

O objetivo é abrir um nó Graph usando um arquivo docker-compose. O arquivo docker-compose necessário pode ser encontrado aqui.

version: '3'
services:
  graph-node:
    image: graphprotocol/graph-node
    ports:
      - '8000:8000'
      - '8001:8001'
      - '8020:8020'
      - '8030:8030'
      - '8040:8040'
    depends_on:
      - ipfs
      - postgres
    extra_hosts:
      - host.docker.internal:host-gateway
    environment:
      postgres_host: postgres
      postgres_user: graph-node
      postgres_pass: let-me-in
      postgres_db: graph-node
      ipfs: 'ipfs:5001'
      ethereum: 'mainnet:http://host.docker.internal:8545'
      GRAPH_LOG: info
  ipfs:
    image: ipfs/kubo:v0.14.0
    ports:
      - '5001:5001'
    volumes:
      - ./data/ipfs:/data/ipfs
  postgres:
    image: postgres:14
    ports:
      - '5432:5432'
    command:
      [
        "postgres",
        "-cshared_preload_libraries=pg_stat_statements",
        "-cmax_connections=200"
      ]
    environment:
      POSTGRES_USER: graph-node
      POSTGRES_PASSWORD: let-me-in
      POSTGRES_DB: graph-node
      # FIXME: remove this env. var. which we shouldn't need. Introduced by
      # <https://github.com/graphprotocol/graph-node/pull/3511>, maybe as a
      # workaround for https://github.com/docker/for-mac/issues/6270?
      PGDATA: "/var/lib/postgresql/data"
      POSTGRES_INITDB_ARGS: "-E UTF8 --locale=C"
    volumes:
      - ./data/postgres:/var/lib/postgresql/data

Se você for um usuário do Linux (ignore o fato de que o macOS é baseado em UNIX se você for um usuário do Mac), será necessário executar o script adicional para que o nó do gráfico funcione corretamente.setup.sh

O arquivo de composição girará 3 contêineres no total, um para o nó, outro para um nó IPFS e um contêiner Postgres final. Postgres é a camada de persistência para o nó do gráfico e, ao girar esse contêiner, ele gerará um diretório. Os dados armazenados incluem informações sobre o blockchain, ou seja, altura do bloco, etc., que são usadas para determinar se um log de eventos foi analisado, por exemplo.data/

Um “Gotcha” comum — Se você fosse reiniciar seu blockchain local, o DB do seu nó ficaria fora de sincronia com o estado atual de sua cadeia e, portanto, você precisaria derrubar seu DB e começar de novo.

A razão pela qual estou aborrecendo você com todas essas informações é para impedi-lo de sentir dor quando você não entende por que um dia sua pilha local funcionou e depois outro, não funcionou. Felizmente, desenvolvemos um script simples para facilitar a rotação de um nó local:

#!/bin/bash

docker-compose down -v;

if [ -d "data" ]
then
  echo "Found old data for the graph node - deleting it";
  # we need to sudo this to remove system locked files
  sudo rm -rf data/;
fi

docker-compose up;

Se você salvou esse script no mesmo diretório que o arquivo docker-compose e deu a ele privilégios de execução, você encontrará uma maneira fácil e repetível de girar um nó de gráfico depois de iniciar um novo blockchain.

Agora, hora de executar o script acima para começar as coisas!

Tudo indo bem, os 3 recipientes devem girar felizes (você pode precisar dar um minuto ou dois para girar completamente). Se tudo estiver funcionando corretamente, você verá o seguinte sendo impresso repetidamente do seu :ganache-cli

$ eth_getBlockByNumber

Isso significa que o nó do Graph está sondando sua cadeia em busca de todas as informações necessárias para operar. Se isso não estiver acontecendo, verifique se algo deu errado ao girar o nó do gráfico observando os logs do docker do contêiner que está sendo impresso no terminal. Como alternativa, revisite as etapas acima para ver onde você pode ter errado.

Etapa 3: Implantando no nó do gráfico local

Se você implantou um subgráfico Rinkeby ou mainnet, saberá que, antes de implantar, você precisa criar um projeto por meio do painel. Localmente, você ainda precisa criar um projeto para implantar e a maneira como você faz isso é por meio do seguinte comando:

yarn create-local

Desde que o nó do Graph esteja em execução e configurado corretamente, um projeto deve ter sido criado. Esta é uma operação única para cada projeto, toda vez que você inicia um nó Graph local.

A partir daqui, você pode simplesmente implantar no nó. Novamente, há scripts locais que você precisa chamar em vez daqueles com os quais você pode estar acostumado. Por exemplo:

yarn build && yarn deploy-local

Irá construir e implantar localmente seu subgrafo em seu subgrafo local. Algumas coisas a serem observadas para que o nó funcione corretamente:

  • A rede para todos os contratos definidos no arquivo deve ser mesmo que você esteja implantando em um nó local. Isso não interagirá com a rede Ethereum principal - é apenas a maneira que precisa ser configurada para o seu nó local. Aprendi da maneira mais difícil…subgraph.yml mainnet subgraph.yml
  • Você provavelmente já se antecipou a isso, mas todos os seus endereços de contrato no arquivo precisam corresponder aos endereços de implantação das migrações que você executou em seu blockchain local.subgraph.yml

Essas são as principais pegadinhas que podem te desanimar.

Desde que tudo corra bem, você deve ser informado de que a implantação foi bem-sucedida e receber um ponto de extremidade http para permitir que você consulte entidades. Isso, é claro, dependerá de os dados estarem em cadeia, etc., o que você pode conseguir executando em migrações adicionais, fazendo alterações de estado ou fazendo alterações de estado no seu dapp por meio de alguma UX sofisticada que você projetou para um front-end (configurando metamáscara conforme descrito acima)

Conclusão

Ao executar uma pilha completa de Ganache + subgrafo localmente, abrimos a capacidade de iterar muito mais rápido graças a implantações locais mais rápidas, confirmações instantâneas de blocos, etc. No entanto, você pode ver (e ter experimentado) que existem alguns pontos problemáticos envolvidos em fazer a pilha funcionar. Fizemos uma tentativa de melhorar a sequência de inicialização do nó com nosso script bash, mas ainda há uma série de aros para pular para começar. Você pode automatizar ainda mais tendo um script que irá girar uma blockchain local, migrar seus contratos para essa cadeia, iniciar um nó gráfico etc. e é algo que podemos considerar para ajudar nosso desenvolvimento local. No entanto, não há como fugir do fato de que a solução pronta para uso tem suas peculiaridades e é um caso de pesar o tempo necessário para configurar a pilha local versus talvez implantar no Rinkeby. Quaisquer que sejam seus pensamentos sobre isso, em geral nós amamos o Graph aqui na BlockRocket e temos tido cada vez mais clientes integrando isso em sua pilha. Será interessante ver como a pilha Dapp continua a se desenvolver a partir deste ponto.

Autor: Vincent de Almeida

Artigo Original