Endpoints / Playground UIs¶
The graphql API endpoints also serve a playground UI to browsers for convenience. This UI is useful for rapid experimentation and iteration of queries as well as just getting some results, features include:
- real-time query results
- query editor:
- auto-complete & validation via schema introspection
- can store multiple, named queries
- supports graphql variables
- local persistence of query editor contents
- schema reference
- graphql docs reference
|Network||API / Playground URL|
The graphql API relies heavily on postgraphile (as a library) to resolve graphql requests.
It is recommended to prefer using pagination operators by default (e.g.
first: <limit>) to avoid unnecessary delays in query responses.
Filtering is facilitated by postgraphile and its plugins. For specifics on supported operators and how to use them, please refer to their documentation:
NativeTransfers for a given sender address:
Messages from a given sender address:
Eventss within a given timeframe and with a given type:
Order by / Sorting¶
Each entity, by default, can be sorted by any of its respective fields.
Additional support for ordering by certain fields on related entities is facilitated by custom ordering plugins generated from
makeAddPgTableOrderByPlugin (see: postgraphile-docs).
Any entity which relates to
Block can be ordered by a related block's
Contract Code ID¶
contract entity can be sorted by
codeId through the
Each of these custom orders are implemented in both directions, ascending and descending. These directions are accessed through the ending characters of the order enum, by choosing either
Aggregation is facilitated by the pg-aggregates plugin. Features include:
- calculating aggregates
- grouped aggregates
- applying conditions to grouped aggregates
- ordering by relational aggregates
- filtering by the results of aggregates on related connections
Tests as examples¶
Additional examples of queries and use cases can be found in the end-to-end test suite.
Entities tracked by the indexer exist at varying levels of abstraction. "Lower-level" entities include the primitives (i.e. blocks, transactions, messages, and events), upon which "higher-level" entities are constructed (e.g. LegacyBridgeSwaps).
Some entities are derived from objects which do not correspond to any network state change (e.g. failed transactions and their messages). In the case of failed transactions, it is desirable to index the associated data for end-user reference. This notion may also apply to other objects but should be considered carefully to avoid storing invalid or useless data.
- event attributes
Entity relationship diagrams¶
The versions of both the GraphQL API and the Indexer itself can be retrieved simply using the following query on the GraphQL playground.
Each of these version numbers are stored as the value to the key
"version" within their relevant module
package.json file. These files can be found in the
subql/packages/query/ directories for the Indexer and GraphQL versions, respectively.
_metadata entity has further utility beyond the scope of the example query given prior. Using any of the relevant fields from the type definition below, internal states and config information can be retrieved with ease.
If a developer was curious about the
chain-id or whether the Indexer has passed any health checks, using
indexerHealthy, these values can be returned within the playground or otherwise connected projects.