Frequently Asked Questions
Frequently Asked Questions
SubQuery is an open source blockchain data indexer for developers that provides fast, flexible, reliable, and decentralised APIs to power leading multi-chain apps.
Our goal is to save developers' time and money by eliminating the need of building their own indexing solution. Now, they can fully focus on developing their applications. SubQuery helps developers create the decentralised products of the future.
SubQuery Managed Service
SubQuery also provides free, production grade hosting of projects for developers. Our Managed Service removes the responsiblity of managing infrastructure, so that developers do what they do best — build. Find out more here.
The SubQuery Network
The SubQuery Network allows developers to completely decentralise their infrastructure stack. It is the most open, performant, reliable, and scalable data service for dApps. The SubQuery Network indexes and services data to the global community in an incentivised and verifiable way. After publishing your project to the SubQuery Network, anyone can index and host it - providing data to users around the world faster and reliably.
More information here.
The best way to get started with SubQuery is to try out our Hello World tutorial. This is a simple 5 min walk through exercise. Download the starter template, build the project, use Docker to run a node on your localhost, and run a simple query.
私たちはコミュニティからの貢献とフィードバックが大好きです。 To contribute the code, fork the repository of your interest and make your changes. 次に PR または Pull リクエストを送信します。 Don't forget to test as well. Also check out our contributions guidelines.
To give feedback, contact us at firstname.lastname@example.org or jump onto our discord channel.
自分のプロジェクトを SubQuery Projects で公開するにはどのくらいの費用がかかりますか？
This service is being provided to the community with a generous free tier! You can host your first two SubQuery projects for absolutely free!
What are deployment slots?
Deployment slots are a feature in SubQuery Managed Service that is the equivalent of a development environment. For example, in any software organisation there is normally a development environment and a production environment as a minimum (ignoring localhost that is). Typically additional environments such as staging and pre-prod or even QA are included depending on the needs of the organisation and their development set up.
SubQuery currently has two slots available. A staging slot and a production slot. This allows developers to deploy their SubQuery to the staging environment and all going well, "promote to production" at the click of a button.
What is the advantage of a staging slot?
The main benefit of using a staging slot is that it allows you to prepare a new release of your SubQuery project without exposing it publicly. You can wait for the staging slot to reindex all data without affecting your production applications.
The staging slot is not shown to the public in the Explorer and has a unique URL that is visible only to you. And of course, the separate environment allows you to test your new code without affecting production.
What are Polkadot's Extrinsics?
If you are already familiar with blockchain concepts, you can think of extrinsics as comparable to transactions. More formally though, an extrinsic is a piece of information that comes from outside the chain and is included in a block. There are three categories of extrinsics. They are inherents, signed transactions, and unsigned transactions.
Inherent extrinsics are pieces of information that are not signed and only inserted into a block by the block author.
Signed transaction extrinsics are transactions that contain a signature of the account that issued the transaction. They stands to pay a fee to have the transaction included on chain.
Unsigned transactions extrinsics are transactions that do not contain a signature of the account that issued the transaction. Unsigned transactions extrinsics should be used with care because there is nobody paying a fee, becaused they are not signed. Because of this, the transaction queue lacks economic logic to prevent spam.
For more information, click here.
What is the endpoint for the Kusama network?
The network.endpoint for the Kusama network is
What is the endpoint for the Polkadot mainnet network?
The network.endpoint for the Polkadot network is
How do I iteratively develop my project schema?
A known issue with developing a changing project schema is that when lauching your Subquery node for testing, the previously indexed blocks will be incompatible with your new schema. In order to iteratively develop schemas the indexed blocks stored in the database must be cleared, this can be achieved by launching your node with the
--force-clean flag. For example:
subql-node -f . --force-clean --subquery-name=<project-name>
Note that it is recommended to use
--force-clean when changing the
startBlock within the project manifest (
project.yaml) in order to begin reindexing from the configured block. If
startBlock is changed without a
--force-clean of the project, then the indexer will continue indexing with the previously configured
How can I optimise my project to speed it up?
Performance is a crucial factor in each project. Fortunately, there are several things you could do to improve it. Here is the list of some suggestions:
- Avoid using block handlers where possible.
- Query only necessary fields.
- Try to use filter conditions to reduce the response size. Create filters as specific as possible to avoid querying unnecessary data.
- For large data tables, avoid querying
totalCountwithout adding conditions.
- Add indexes to entity fields for query performance, this is especially important for historical projects.
- Set the start block to when the contract was initialised.
- Always use a dictionary (we can help create one for your new network).
- Optimise your schema design, keep it as simple as possible.
- Try to reduce unnecessary fields and columns.
- Create indexes as needed.
- Use parallel/batch processing as often as possible.
api.queryMulti()to optimise Polkadot API calls inside mapping functions and query them in parallel. This is a faster way than a loop.
Promise.all(). In case of multiple async functions, it is better to execute them and resolve in parallel.
- If you want to create a lot of entities within a single handler, you can use
store.bulkCreate(entityName: string, entities: Entity). You can create them in parallel, no need to do this one by one.
- Making API calls to query state can be slow. You could try to minimise calls where possible and to use
worker threadsto move block fetching and block processing into its own worker thread. It could speed up indexing by up to 4 times (depending on the particular project). You can easily enable it using the
-workers=<number>flag. Note that the number of available CPU cores strictly limits the usage of worker threads. For now, it is only available for Substrate and Cosmos and will soon be integrated for Avalanche.
- Note that
JSON.stringifydoesn’t support native
BigInts. Our logging library will do this internally if you attempt to log an object. We are looking at a workaround for this.
- Use a convenient
modulofilter to run a handler only once to a specific block. This filter allows handling any given number of blocks, which is extremely useful for grouping and calculating data at a set interval. For instance, if modulo is set to 50, the block handler will run on every 50 blocks. It provides even more control over indexing data to developers and can be implemented like so below in your project manifest.