Write queries that keep working as your data grows. Every Subgraph has its own GraphQL schema, and GraphOps serves it through the standard Subgraph query interface, so the entity names, filters, and ordering fields you can use come from the Subgraph, not from GraphOps.
Schema model
A Subgraph schema defines entities and relationships. For example, a decentralized exchange Subgraph
may expose entities such as pool, token, swap, position, or factory. A governance
Subgraph may expose proposals, votes, delegates, and token holders.
Use introspection or the schema published with the Subgraph to discover the exact entity names, fields, filters, and relationships for the Subgraph you query.
Query features
GraphOps supports standard Subgraph GraphQL query behavior for the Subgraphs it serves:
| Feature | Behavior |
|---|---|
| Entity selection | Query entity collections and single entities exposed by the Subgraph schema. |
| Filtering | Use standard generated where filters for fields supported by the schema. |
| Ordering | Use orderBy and orderDirection when generated for the entity. |
| Pagination | Use first and skip; prefer cursor-like pagination by stable fields for large scans. |
| Metadata | Query _meta for deployment, block, and indexing-error metadata. |
| Introspection | Use GraphQL introspection when enabled for the Subgraph endpoint. |
Design production queries
Good production queries:
- Request only the fields the application needs.
- Page through large entity sets.
- Use stable ordering.
- Include
_metawhen the application needs to display freshness or diagnose indexing lag. - Treat GraphQL errors as partial or failed application responses, not transport success.
Next steps
Last updated