Frequently Asked Questions

SubQuery là gì?

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.

Mạng SubQuery

The SubQuery Network allows developers to completely decentralise their infrastructure stack. It is the most open, performant, reliable, and scalable data service for dApps. Mạng SubQuery lập chỉ mục và dữ liệu dịch vụ cho cộng đồng toàn cầu theo cách được khuyến khích và có thể xác minh. Sau khi xuất bản dự án của bạn lên Mạng SubQuery, bất kỳ ai cũng có thể lập chỉ mục và lưu trữ nó - cung cấp dữ liệu cho người dùng trên toàn thế giới nhanh hơn và đáng tin cậy hơn.

More information here.

Cách tốt nhất để bắt đầu với SubQuery là gì?

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.

Làm cách nào để tôi có thể đóng góp hoặc đưa ra phản hồi cho SubQuery?

Chúng tôi rất mong nhận được ý kiến đóng góp và phản hồi từ cộng đồng. To contribute the code, fork the repository of your interest and make your changes. Sau đó hãy sử dụng chức năng Pull Request hay gọi tắt là PR. Don't forget to test as well. Also check out our contributions guidelines.

To give feedback, contact us at hello@subquery.network or jump onto our discord channel.

Chi phí để lưu trữ dự án của tôi trong SubQuery là bao nhiêu?

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 wss://kusama.api.onfinality.io/public-ws.

What is the endpoint for the Polkadot mainnet network?

The network.endpoint for the Polkadot network is wss://polkadot.api.onfinality.io/public-ws.

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 startBlock.

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 totalCount without 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.
  • Use api.queryMulti() to optimise Polkadot API calls inside mapping functions and query them in parallel. This is a faster way than a loop.
  • Use 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 extrinsic/transaction/event data.
• Use worker threads to 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.stringify doesn’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 modulo filter 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.