SubQuery announces version 3 of its core SubQuery SDK, the leading open-source indexer used by developers across more than 100 ecosystems to provide custom data APIs to their applications. SubQuery is a fast, flexible, open-source indexer that also runs on the decentralised SubQuery network, providing its customers with a superior and faster development experience.
Version 3.0 adds some major improvements to SubQuery that have been requested and developed in partnership with key customers in the SubQuery ecosystem. It centres on SubQuery’s goals of providing the fastest, most reliable, easiest to develop, and most fully featured decentralised data indexer in web3.
Project Codegeneration and Scaffolding
In our recent announcement, we introduced the beta version of our newest feature designed to enhance efficiency for developers — project scaffolding. With the release of v3 of our SDK, this feature has undergone meticulous bug fixes and enhancements, ensuring its readiness for seamless integration into production environments.
The scaffolding feature lets developers autogenerate the key boilerplate for an entire SubQuery project off a single smart contract definition.
SubQuery will generate a project manifest and function facades for the selected events or transaction types from your smart contracts during setup, saving you from writing a boilerplate. It simplifies the process and ensures type safety in your project, making it a game-changer for SubQuery developers.
Changing the project manifest from yaml to typescript
With the number of new features we are adding to SubQuery, and the slight differences between each chain that mostly occur in the manifest, we looked for a way to make it easier for developers to understand, try out new features and push the boundaries of what they index.
Rather than a complex yaml file that is easy to make errors in, we’ve decided to embrace the safety of typescript.
The manifest in version 3 is now written in Typescript by default, which includes better type safety, more advanced settings (more on that below), and documentation to make it easier for developers to update and edit without having to consult our documentation.
This step makes the development experience easier for developers of SubQuery, and also improves the discovery and documentation of new features and configuration options, it’s a relatively major change to our SDK that is surprisingly easy to make to your projects. For example, with typescript in your favourite code editor, you can see documentation and types for each field as you code your manifest file — easy!
Improved Store Methods for retrieving data
Many customers have requested improved data retrieval store operations so they have more flexibility when accessing their data from the store database from within their mapping functions.
We’ve listened and added a new getter that is highly flexible and allows an unlimited amount of AND filters to get the exact data you need for your mapping functions. Read more about this here
https://academy.subquery.network/build/mapping/store.html#get-records-by-field
For example with the following query, you can now retrieve all TransactionEntities that exist for a given account on a given chainID.
Configuration and project upgrades in the Project Manifest
Previously, developers of SubQuery projects on the SubQuery Network or in the Managed Service would have to configure the settings of SubQuery each time they make the changes. They would also have to trust that third-party indexers do the same and maintain the same configuration.
We wanted to let SubQuery developers enforce certain running parameters, e.g. unsafe mode or historical indexing, so that when a third-party indexer runs the project, they run it in the exact same way as the developer intended for it to be.
Summary
Codegeneration rapidly shortens the development time of each SubQuery project, and means new users can get started with correct boilerplate for their custom contracts in seconds. With the change of our manifest to typescript, we are able to add more advanced configuration to our projects while making it easier for new developers to use and experiment with. With advanced store functions, developers can also make more optimal queries from within their mapping functions, e.g. when aggreating historical data for a given type. Finally, allowing developers to define project configuration and scheduled upgrades gives developers the confidence that indexers will run the project in the exact way they require it.
These four new key features, including many other bug fixes, rewrites, and others come together to contribute to web3’s most flexible and performant decentralised data indexer.