Subsquid Basics — What is a Squid?
Developing a successful Web3 application isn’t easy. For one, most of the ever-expanding global blockchain ecosystem remains fragmented, with dozens of popular networks competing for dominance. Information stored on these various chains is difficult to access for individual DApps, and cross-chain data silos seem insurmountable to many developers.
Even when building on a single blockchain, DApp developers need to deploy some kind of backend server to store data for rapid queries, thereby ensuring a better user experience. This process, however, can be time-consuming and expensive. Web3 builders want to focus on creating groundbreaking tech, but instead are forced to devote resources to the development, testing, deployment, and maintenance of middleware.
Subsquid exists to make on-chain data easily and quickly accessible to Web3 builders and the users of their applications. Built on multi-layer architecture, and managed through decentralised governance, Subsquid’s API framework has been envisaged to accelerate the development of natively multichain, fully-scalable, and easy-to-deploy backends — called Squids — that can plug into virtually any app.
What is a Squid?
In simple terms, a Squid is a tailor-made API that collects and processes data — previously retrieved from one or multiple blockchains — in such a way that fits the needs of a particular application. Squids are designed to be customisable, upgradeable, and easy to set up. They are built on top of robust, decentralised, architecture that ensures reduced downtime risk and minimalised opportunity for third-party interference.
All Squids consist of three essential components: a GraphQL server, a database, and one or more Processors. They are fed data by Subsquid’s decentralised network of Archives, specialised software that ‘converts’ on-chain information into something that Squids can ‘digest.’
How do Squids work?
When a request is made for data through an application built on top of a Squid, the request is accepted through the GraphQL server. Thanks to the way that Subsquid’s workflow is configured, the requested data would have already been previously saved in the database. This means that the information can be instantly sent back to the user.
From a technical perspective, the design of this whole system is quite clever. Basically, all the data, which has been pre-processed by Archives, comes to Squids in a format that they can easily understand. When building their Squid, developers indicate exactly what kind of information they would like to receive from chains and define how that data will be transformed.
Once deployed, the Squid’s Processor takes these parameters into account and looks through archives to find exactly the data that had been specified and apply the configured business logic. To make sure the information is available for future requests, the data is then saved to the database.
Each Processor can query Archive data from a single blockchain. For maximum network interoperability, developers can choose to install multiple processors into their Squids. The entities most commonly tracked in current implementations of Squid Processors include blocks, events, extrinsics, as well as EVM logs (on EVM-compatible chains).
The process of defining parameters for data processing is extremely simple. It only takes a few minutes to have a basic Squid up and running, then usually less than a day of development time to customise it. This is truly the easiest way to get Web3 applications off the ground.
The ultimate back-end API for Web3
Some astute observers may remark that Subsquid is not the only blockchain data processing solution on the market and that Squids are not the only API framework that is native to Web3. It’s worth outlining, therefore, just a few of the technology’s competitive advantages:
- Multichain support
Subsquid and its community is deploying Archives on all major Substrate chains, and plans are already in place to expand outside that ecosystem. - Support for EVM-based parachains
Squids feature native support for EVM contract mappings, which means they can process parachains like Moonriver, Astar, and Acala. - Runtime upgrades
The Subsquid solution abstracts the complexity of updates on underlying blockchain networks by providing type-safe, automatically generated, TypeScript wrappers that handle Runtime changes. - Customisability
Squids can be developed to meet the needs of virtually any app. Set up a simple Squid in minutes, or create a highly-customised API using sophisticated and unique parameters. Even following deployment, these parameters can be changed at any time. - Full-text search
The GraphQL servers that are built into Squids inherently support full-text searches. - Union types
It is possible to define new types as a Union of others. Therefore, these Union types can return results of any and all types that have been included within them. - Interfaces
Like in object-oriented programming, Interfaces define fields that multiple object types can use by implementing them. For this reason, querying an Interface can return different fields depending on the implementation type of the result. - JSON fields
If the field of an object cannot be mapped to a fixed schema, it can be captured as a JSON field.
Join our Community!
Want to find out more about Subsquid? Join us on our Discord server, visit our website, or check out one of these resources:
Website, Twitter, Discord, Telegram, Subsocial, Reddit, Facebook, Instagram
