開発者 FAQ

Reading time: 7 min

This page summarizes some of the most common questions for developers building on The Graph.

A subgraph is a custom API built on blockchain data. Subgraphs are queried using the GraphQL query language and are deployed to a Graph Node using The Graph CLI. Once deployed and published to The Graph's decentralized network, Indexers process subgraphs and make them available for subgraph consumers to query.

To successfully create a subgraph, you will need to install The Graph CLI. Review the Quick Start to get started. For detailed information, see Creating a Subgraph.

It is highly recommended that you structure your smart contracts to have events associated with data you are interested in querying. Event handlers in the subgraph are triggered by contract events and are the fastest way to retrieve useful data.

If the contracts you work with do not contain events, your subgraph can use call and block handlers to trigger indexing. However, this is not recommended, as performance will be significantly slower.

No. Once a subgraph is created, the associated GitHub account cannot be changed. Please make sure to carefully consider this before creating your subgraph.

You can deploy a new version of your subgraph to Subgraph Studio using the CLI. This action maintains your subgraph private, but once you’re happy with it, you can publish to Graph Explorer. This will create a new version of your subgraph that Curators can start signaling on.

サブグラフを再デプロイする必要がありますが、サブグラフの ID（IPFS ハッシュ）が変わらなければ、最初から同期する必要はありません。

Take a look at Access to smart contract state inside the section AssemblyScript API.

Not currently, as mappings are written in AssemblyScript.

One possible alternative solution to this is to store raw data in entities and perform logic that requires JS libraries on the client.

サブグラフ内では、複数のコントラクトにまたがっているかどうかにかかわらず、イベントは常にブロックに表示される順序で処理されます。

Templates allow you to create data sources quickly, while your subgraph is indexing. Your contract might spawn new contracts as people interact with it. Since you know the shape of those contracts (ABI, events, etc.) upfront, you can define how you want to index them in a template. When they are spawned, your subgraph will create a dynamic data source by supplying the contract address.

データソース・テンプレートのインスタンス化」のセクションをご覧ください: Data Source Templates

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 a new dataSource.

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.

以下のコマンドを実行してください:

docker pull graphprotocol/graph-node:latest

もし、イベント中に 1 つのエンティティしか作成されず、他に利用できるものがなければ、トランザクションハッシュ＋ログインデックスがユニークになります。Bytes に変換してcrypto.keccak256に通すことで難読化することができますが、これでは一意性は高まりません。

Yes, you can delete and transfer your subgraph.

対応ネットワークの一覧はこちらで確認できます。

はい、以下の例のように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.

Yes. dataSources.source.startBlock in the subgraph.yaml file specifies the number of the block that the dataSource starts indexing from. In most cases, we suggest using the block where the contract was created: Start blocks

Yes, you should take a look at the optional start block feature to start indexing from the block where the contract was deployed: Start blocks

はい、あります。organization/subgraphName」を公開先の組織とサブグラフの名前に置き換えて、以下のコマンドを実行してみてください:

curl -X POST -d '{ "query": "{indexingStatusForCurrentVersion(subgraphName: \"organization/subgraphName\") { chains { latestBlock { hash number }}}}"}' https://api.thegraph.com/index-node/graphql

By default, query responses are limited to 100 items per collection. If you want to receive more, you can go up to 1000 items per collection and beyond that, you can paginate with:

someCollection(first: 1000, skip: <number>) { ... }

Currently, the recommended approach for a dapp is to add the key to the frontend and expose it to end users. That said, you can limit that key to a hostname, like yourdapp.io and subgraph. The gateway is currently being run by Edge & Node. Part of the responsibility of a gateway is to monitor for abusive behavior and block traffic from malicious clients.

Federation is not supported yet. At the moment, you can use schema stitching, either on the client or via a proxy service.

• graph-node
• graph-tooling
• graph-docs
• graph-client