Bir Subgraph'i Birden Fazla Ağda Dağıtma

Reading time: 5 min

Bu sayfa, bir subgraph'i birden fazla ağda nasıl dağıtacağınızı açıklar. Bir subgraph'i dağıtmak için öncelikle Graph CLI'yi yüklemeniz gerekir. Henüz bir subgraph oluşturmadıysanız, Subgraph Oluşturma bölümüne bakın.

Bazı durumlarda, tüm kodu tekrarlamak zorunda olmadan aynı subgraph'i birden fazla ağda yayına almak isteyebilirsiniz. Bunu yapmaktaki temel zorluk, sözleşme kodu tamamen aynı olsa dahi, farklı ağlardaki sözleşme adreslerinin farklı olmasıdır.

Hem graph build (v0.29.0'dan itibaren) hem de graph deploy (v0.32.0'dan itibaren) komutları iki yeni seçeneği kabul eder:

Seçenekler:

      ...
      --network <name>          Ağ yapılandırmasını networks config dosyasını kullanarak yapmak için
      --network-file <path>     Ağ yapılandırma dosya yolu (varsayılan: "./networks.json")

--network seçeneğini, geliştirme sırasında subgraph'inizi kolayca güncellemek amacıyla, bir json standart dosyası kullanarak bir ağ yapılandırması belirlemek için kullanabilirsiniz. (Varsayılan olarak networks.json dosyasını kullanır.)

Eğer bir networks.json dosyanız yoksa, aşağıdaki yapı ile manuel olarak oluşturmanız gerekecek:

{
    "network1": { // ağ adı
        "dataSource1": { //veri kaynağı adı
            "address": "0xabc...", // sözleşme adresi (isteğe bağlı)
            "startBlock": 123456 // başlangıç bloku (isteğe bağlı)
        },
        "dataSource2": {
            "address": "0x123...",
            "startBlock": 123444
        }
    },
    "network2": {
        "dataSource1": {
            "address": "0x987...",
            "startBlock": 123
        },
        "dataSource2": {
            "address": "0xxyz..",
            "startBlock": 456
        }
    },
    ...
}

Şimdi, subgraph'inizi mainnet ve sepolia ağlarında dağıtmak istediğinizi varsayalım ve subgraph.yaml dosyanız aşağıdaki gibi olsun`:

# ...
dataSources:
  - kind: ethereum/contract
    name: Gravity
    network: mainnet
    source:
      address: '0x123...'
      abi: Gravity
    mapping:
      kind: ethereum/events

Ağ yapılandırma dosyanız şu şekilde olmalıdır:

{
  "mainnet": {
    "Gravity": {
      "address": "0x123..."
    }
  },
  "sepolia": {
    "Gravity": {
      "address": "0xabc..."
    }
  }
}

Şimdi aşağıdaki komutlardan birini çalıştırabilirsiniz:

# Varsayılan networks.json dosyasını kullanarak
yarn build --network sepolia

# Özel adlandırılmış bir dosya kullanarak
yarn build --network sepolia --network-file path/to/config

build komutu, subgraph.yaml dosyanızı sepolia yapılandırmasıyla güncelleyip ardından subgraph'i yeniden derleyecektir. subgraph.yaml dosyanız artık şöyle görünmelidir:

# ...
dataSources:
  - kind: ethereum/contract
    name: Gravity
    network: sepolia
    source:
      address: '0xabc...'
      abi: Gravity
    mapping:
      kind: ethereum/events

Artık yarn deploy komutunu çalıştırmaya hazırsınız.

# Varsayılan networks.json dosyasını kullanarak
yarn deploy --network sepolia

# Özel adlandırılmış bir dosya kullanarak
yarn deploy --network sepolia --network-file path/to/config

Daha eski graph-cli sürümlerini kullanarak kontrat adresleri gibi unsurları parametrize etmenin bir yolu, bunların bir kısmını Mustache veya Handlebar gibi bir şablonlama sistemiyle oluşturmaktır.

Bu yaklaşımı açıklamak için, bir subgraph'in mainnet ve Sepolia ağlarına farklı sözleşme adresleri ile dağıtılması gerektiğini varsayalım. Her ağ için adresleri sağlayan iki yapılandırma dosyası tanımlayabilirsiniz:

{
  "network": "mainnet",
  "address": "0x123..."
}

ve

{
  "network": "sepolia",
  "address": "0xabc..."
}

Bununla birlikte, ağ adını ve adresleri manifesto içinde {{network}} ve {{address}} gibi değişken yer tutucularla değiştirir ve manifestoyu örneğin subgraph.template.yaml olarak yeniden adlandırırsınız:

# ...
dataSources:
  - kind: ethereum/contract
    name: Gravity
    network: mainnet
    network: {{network}}
    source:
      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
      address: '{{address}}'
      abi: Gravity
    mapping:
      kind: ethereum/events

Her iki ağ için de bir manifesto oluşturmak amacıyla, package.json dosyasına mustache gereksinimiyle birlikte iki ek komut ekleyebilirsiniz:

{
  ...
  "scripts": {
    ...
    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",
    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"
  },
  "devDependencies": {
    ...
    "mustache": "^3.1.0"
  }
}

Bu subgraph'i mainnet veya Sepolia üzerinde yayına almak için artık aşağıdaki iki komuttan birini çalıştırabilirsiniz:

# Mainnet:
yarn prepare:mainnet && yarn deploy

# Sepolia:
yarn prepare:sepolia && yarn deploy

Bunun çalışan bir örneğini burada bulabilirsiniz.

Not: Bu yaklaşım, sözleşme adresleri ve ağ adlarının ötesinde daha fazla değişiklik yapmanın, veya şablonlardan mapping ya da ABI'ler oluşturmanın gerekli olduğu, daha karmaşık durumlara da uygulanabilir.

Bu işlem, subgraph'inizin geride kalıp kalmadığını kontrol etmek için chainHeadBlock değerini subgraph'inizdeki latestBlock ile karşılaştırmanızı sağlar. synced, subgraph'in zincire daha önce hiç yetişip yetişmediğini belirtir. health ise şu anda hata olmadığında healthy ve bir hata nedeniyle subgraph'in ilerlemesi durduğunda failed değerlerini alabilir. Bu durumda, hataya dair ayrıntılar için fatalError alanını kontrol edebilirsiniz.

Studio’daki bir subgraph sürümü yalnızca aşağıdaki kriterleri karşılaması durumunda arşivlenir:

• Sürüm ağa yayımlanmamıştır (veya yayım askıda kalmıştır)
• Sürüm, 45 gün veya daha uzun bir süre önce oluşturulmuştur
• Subgraph son 30 gündür sorgulanmamıştır

Ek olarak, yeni bir sürüm yayına alındığında, eğer subgraph yayımlanmadıysa, subgraph’in N-2 sürümü arşivlenir.

Bu politika kapsamında etkilenen her subgraph, ilgili sürümü geri getirme seçeneğine sahiptir.

Bir subgraph'in başarıyla senkronize olması, sonsuza kadar sorunsuz çalışmaya devam edeceğine dair iyi bir işarettir. Ancak, ağdaki yeni tetikleyiciler subgraph'inizin test edilmemiş bir hata durumuna düşmesine neden olabilir, veya performans sorunları ya da düğüm operatörlerindeki sorunlar nedeniyle subgraph geride kalmaya başlayabilir.

Graph Düğümü, subgraph'inizin durumunu kontrol etmek için sorgu yapabileceğiniz bir GraphQL uç noktası sunar. Sağlayıcı hizmetinde bu uç nokta https://api.thegraph.com/index-node/graphql adresinde bulunmaktadır. Yerel bir düğümde ise varsayılan olarak 8030/graphql portunda erişilebilir. Bu uç noktanın tam şemasına buradan ulaşabilirsiniz. İşte bir subgraph'in güncel sürümünün durumunu kontrol eden örnek bir sorgu:

{
  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {
    synced
    health
    fatalError {
      message
      block {
        number
        hash
      }
      handler
    }
    chains {
      chainHeadBlock {
        number
      }
      latestBlock {
        number
      }
    }
  }
}

Bu işlem, subgraph'inizin geride kalıp kalmadığını kontrol etmek için chainHeadBlock değerini subgraph'inizdeki latestBlock ile karşılaştırmanızı sağlar. synced, subgraph'in zincire daha önce hiç yetişip yetişmediğini belirtir. health ise şu anda hata olmadığında healthy ve bir hata nedeniyle subgraph'in ilerlemesi durduğunda failed değerlerini alabilir. Bu durumda, hataya dair ayrıntılar için fatalError alanını kontrol edebilirsiniz.