開発者 FAQ
Reading time: 12 min
サブグラフは、ブロックチェーンデータを基に構築されたカスタムAPIです。サブグラフはGraphQLクエリ言語を使ってクエリされ、Graph CLIを使ってGraph Nodeにデプロイされます。デプロイされ、The Graphの分散型ネットワークに公開されると、インデクサーはサブグラフを処理し、サブグラフの消費者がクエリできるようにします。
一度作成したサブグラフの削除はできません。
一度作成したサブグラフの名前を変更することはできません。サブグラフを作成する際には、他の dapps から検索しやすく、識別しやすい名前になるよう、よく考えてから作成してください。
一度作成したサブグラフに関連する GitHub のアカウントは変更できません。サブグラフを作成する前に、この点をよく考えてください。
スマートコントラクトを構成して、クエリしたいデータに関連するイベントを持つことを強くお勧めします。サブグラフ内のイベントハンドラは、コントラクトのイベントによってトリガされ、有用なデータを取得するための圧倒的に速い方法です。
使用しているコントラクトにイベントが含まれていない場合、サブグラフはコールハンドラとブロックハンドラを使用してインデックス作成をトリガすることができます。しかし、パフォーマンスが大幅に低下するため、これは推奨されません。
複数のネットワークには別々の名前が必要です。同じ名前で異なるサブグラフを持つことはできませんが、単一のコードベースで複数のネットワークに対応する便利な方法があります。詳しくはドキュメントをご覧ください:
テンプレートは、サブグラフがインデックスを作成している間に、その場でデータソースを作成することができます。また、コントラクトの形状（ABI、イベントなど）を前もって知っているので、テンプレートでどのようにインデックスを作成するかを定義することができ、コントラクトが作成されると、サブグラフはコントラクトのアドレスを供給することで動的なデータソースを作成します。
データソース・テンプレートのインスタンス化」のセクションをご覧ください:
以下のコマンドを実行してください:
docker pull graphprotocol/graph-node:latest
注: docker / docker-compose は、最初に実行したときにプルされた graph-node のバージョンを常に使用しますので、最新版の graph-node を使用していることを確認するために、このコマンドを実行することが重要です。
Take a look at Access to smart contract state inside the section .
10. 2 つのコントラクトを持つ graph-cli から graph init を使用してサブグラフをセットアップすることは可能ですか?または、graph init を実行した後、subgraph.yaml に別のデータソースを手動で追加する必要がありますか?
Yes. On graph init command itself you can add multiple datasources by entering contracts one after the other. You can also use graph add command to add new datasource.
もし、イベント中に 1 つのエンティティしか作成されず、他に利用できるものがなければ、トランザクションハッシュ＋ログインデックスがユニークになります。Bytes に変換してcrypto.keccak256に通すことで難読化することができますが、これでは一意性は高まりません。
サブグラフ内では、複数のコントラクトにまたがっているかどうかにかかわらず、イベントは常にブロックに表示される順序で処理されます。
14. Is it possible to differentiate between networks (mainnet, Sepolia, local) from within event handlers?
はい、以下の例のようにgraph-tsをインポートすることで可能です。
import { dataSource } from '@graphprotocol/graph-ts'dataSource.network()dataSource.address()
Yes. Sepolia supports block handlers, call handlers and event handlers. It should be noted that event handlers are far more performant than the other two handlers, and they are supported on every EVM-compatible network.
マッピングは AssemblyScript で書かれているため、現在はできません。代替案としては、生データをエンティティに格納し、JS ライブラリを必要とするロジックをクライアントで実行することが考えられます。
Yes. dataSources.source.startBlock in the subgraph.yaml file specifies the number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created:
はい、コントラクトがデプロイされたブロックからインデックス作成を開始するオプションのスタートブロック機能をご利用ください:
はい、あります。organization/subgraphName」を公開先の組織とサブグラフの名前に置き換えて、以下のコマンドを実行してみてください:
curl -X POST -d '{ "query": "{indexingStatusForCurrentVersion(subgraphName: \"organization/subgraphName\") { chains { latestBlock { hash number }}}}"}' https://api.thegraph.com/index-node/graphql
サブグラフを再デプロイする必要がありますが、サブグラフの ID（IPFS ハッシュ）が変わらなければ、最初から同期する必要はありません。
将来的にはサポートしたいと考えていますが、フェデレーションはまだサポートされていません。現時点でできることは、クライアント上またはプロキシサービス経由でスキーマステッチを使用することです。
デフォルトでは、クエリの応答は 1 つのコレクションにつき 100 アイテムに制限されています。それ以上の数を受け取りたい場合は、1 コレクションあたり 1000 アイテムまで、それ以上は以下のようにページネーションすることができます:
someCollection(first: 1000, skip: <number>) { ... }
24. dapp フロントエンドがクエリに The Graph を使用する場合、クエリ キーをフロントエンドに直接書き込む必要がありますか? ユーザーにクエリ料金を支払う場合はどうなりますか? 悪意のあるユーザーによってクエリ料金が非常に高くなることはありますか?
現在、dapp の推奨されるアプローチは、キーをフロントエンドに追加し、それをエンド ユーザーに公開することです。とはいえ、そのキーを yourdapp.io や subgraph.ゲートウェイは現在 Edge & によって実行されています。ノード。ゲートウェイの責任の一部は、不正行為を監視し、悪意のあるクライアントからのトラフィックをブロックすることです。
自分または他の人がホストされたサービスにデプロイしたサブグラフを見つけるには、ホストされたサービスに移動します。 でご覧いただけます。
Graph は、ホストされるサービスに対して料金を請求することはありません。 Graph は分散型プロトコルであり、集中型サービスに対する課金は The Graph の価値観と一致していません。ホスト型サービスは常に、分散型ネットワークにアクセスするための一時的なステップでした。開発者には、快適に分散ネットワークにアップグレードするのに十分な時間があります。
If you’re a subgraph developer, you can deploy a new version of your subgraph to Subgraph Studio using the CLI. It’ll be private at that point, but if you’re happy with it, you can publish to the decentralized Graph Explorer. This will create a new version of your subgraph that Curators can start signaling on.
Event and call handlers are first ordered by transaction index within the block. Event and call handlers within the same transaction are ordered using a convention: event handlers first then call handlers, each type respecting the order they are defined in the manifest. Block handlers are run after event and call handlers, in the order they are defined in the manifest. Also these ordering rules are subject to change.
When new dynamic data source are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.