子图

Reading time: 3 min

A subgraph is a custom, open API that extracts data from a blockchain, processes it, and stores it so it can be easily queried via GraphQL.

• Access Data: Subgraphs enable the querying and indexing of blockchain data for web3.
• Build: Developers can build, deploy, and publish subgraphs to The Graph Network. To get started, check out the subgraph developer Quick Start.
• Index & Query: Once a subgraph is indexed, anyone can query it. Explore and query all subgraphs published to the network in Graph Explorer.

The subgraph manifest, subgraph.yaml, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.

The subgraph definition consists of the following files:

• subgraph.yaml: Contains the subgraph manifest

• schema.graphql: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL

• mapping.ts: AssemblyScript Mappings code that translates event data into entities defined in your schema

To learn more about each subgraph component, check out creating a subgraph.

Here is a general overview of a subgraph’s lifecycle:

1. Create a subgraph
2. Deploy a subgraph
3. Test a subgraph
4. Publish a subgraph
5. Signal on a subgraph

Great subgraphs start with a local development environment and unit tests. Developers use Graph CLI, a command-line interface tool for building and deploying subgraphs on The Graph. They can also use Graph TypeScript and Matchstick to create robust subgraphs.

Once defined, a subgraph can be deployed to Subgraph Studio. In Subgraph Studio, you can do the following:

• Use its staging environment to index the deployed subgraph and make it available for review.
• Verify that your subgraph doesn't have any indexing errors and works as expected.

When you're happy with your subgraph, you can publish it to The Graph Network.

• This is an on-chain action, which registers the subgraph and makes it discoverable by Indexers.
• Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can transfer the subgraph's ownership by sending the NFT.
• Published subgraphs have associated metadata, which provides other network participants with useful context and information.

Published subgraphs are unlikely to be picked up by Indexers without curation signal. To encourage indexing you should add signal to your subgraph. Learn more about signaling and curating on The Graph.

• Signal is locked GRT associated with a given subgraph. It indicates to Indexers that a given subgraph will receive query volume and it contributes to the indexing rewards available for processing it.
• Third-party Curators may also signal on a given subgraph, if they deem the subgraph likely to drive query volume.

Subgraphs on The Graph Network receive 100,000 free queries per month, after which point developers can either pay for queries with GRT or a credit card.

Learn more about querying subgraphs.

To update your subgraph with bug fixes or new functionalities, initiate a transaction to point it to the new version. You can deploy new versions of your subgraphs to Subgraph Studio for development and testing.

• If you selected "auto-migrate" when you applied the signal, updating the subgraph will migrate any signal to the new version and incur a migration tax.
• This signal migration should prompt Indexers to start indexing the new version of the subgraph, so it should soon become available for querying.

If you no longer need a published subgraph, you can delete or transfer it. Deleting a subgraph returns any signaled GRT to Curators.