# GraphOps Subgraphs

Source: https://docs.graphops.xyz/subgraphs

Build dashboards, activity views, and application APIs from indexed blockchain entities. GraphOps
Subgraphs serves the open Subgraph standard over GraphQL, so you can query an existing deployment
on The Graph Network or a Subgraph you publish yourself, and let GraphOps keep your own Subgraph
indexed.

## Subgraphs at a glance

_New blocks are indexed as they arrive. Your app's GraphQL queries are answered from that index._

- Your app: GraphQL
- Subgraphs: Index
- Chain: New blocks
- [Run the Subgraphs quickstart](/subgraphs/getting-started)
- [Open the Subgraphs reference](/subgraphs/api)

## Where to start

- [Query an existing Subgraph](/subgraphs/getting-started): Create an API key, choose a Deployment CID, and run your first GraphQL query.

- [Choose your setup](/subgraphs/choose-a-setup): Decide what happens to your queries when a new version is released.

- [Keep your Subgraph indexed](/subgraphs/managed-subgraphs): Let GraphOps run indexing and promote new versions when they are ready.

*Your application sends one GraphQL query. GraphOps answers from the indexed entities and reports the block behind the answer in _meta. The pairs shown are illustrative.*

```graphql
pools(first: 3,
  orderBy: totalValueLockedUSD,
  orderDirection: desc) {
  token0 { symbol }
  token1 { symbol }
}
_meta { block { number } }
```

- Response: USDC / WETH, WBTC / WETH, USDC / USDT, with _meta.block.number: N.

Each Subgraph defines its own schema of entities and relationships. GraphOps answers your query from
the latest indexed block and reports that block in `_meta`. Everything after the response belongs to
your application: which fields you request, how you page through results, and how you present
freshness to users.

## What you can build

* **Views that read entities, not node calls.** Show the largest pools, recent swaps, or open
positions with one query. See [Query a Subgraph](/subgraphs/guides/query-a-subgraph).
* **Exports and sync jobs over large collections.** Walk every entity in bounded pages that a
worker can resume. See [Paginate results](/subgraphs/guides/paginate-results).
* **Freshness checks with every answer.** Detect indexing lag and errors before stale data reaches
users. See [Monitor sync health](/subgraphs/guides/monitor-sync-health).
* **Releases behind a stable URL.** Test each new version of your Subgraph, then move your
application to it without changing its endpoint. See
[Develop and release a Subgraph](/subgraphs/guides/develop-and-release).

## Choose Subgraphs when

Use Subgraphs when your application needs entities and their relationships, such as pools,
positions, or votes, and an existing GraphQL schema fits or you can build one with Graph CLI.

Use another GraphOps service when your job is different:

| Need                                                                  | Use                       |
| --------------------------------------------------------------------- | ------------------------- |
| Direct contract reads at an explicit block, or transaction submission | [RPC](/rpc)               |
| Block-by-block history or an ordered stream into your own storage     | [Substreams](/substreams) |

## Choose how you address a Subgraph

Every query goes to one of three endpoint shapes. The choice decides who moves your application to
a new version:

| Identifier                | Endpoint shape                       | Who changes the version                                                                    |
| ------------------------- | ------------------------------------ | ------------------------------------------------------------------------------------------ |
| Deployment CID            | `/v1/deploymentCID/<DEPLOYMENT_CID>` | No one. It always serves the same deployment.                                              |
| Graph Network Subgraph ID | `/v1/subgraphId/<SUBGRAPH_ID>`       | The Subgraph owner, by publishing on The Graph Network, before the new version is indexed. |
| Endpoint Alias            | `/v1/alias/<ALIAS>`                  | Your organization, through the Endpoint Alias target.                                      |

An Endpoint Alias can also target a Managed Subgraph, which moves only after a new version is
indexed and promoted. [Choose your Subgraph setup](/subgraphs/choose-a-setup) recommends a setup
from a few questions, and [Identifiers and Endpoint Aliases](/subgraphs/concepts/identifiers-and-aliases)
explains what each one does during an upgrade.
Query access covers Subgraphs available through The Graph Network, on every network it serves;
managed indexing runs on a smaller set. [Supported networks](/subgraphs/networks) lists
both.

## Plan for production

Before you rely on query results:

* Include `_meta` on important reads and design for indexing lag. Recent data can be corrected by
a chain reorganization.
* Treat a GraphQL `errors` array as a failure even when the HTTP status is `200`.
* Use an Endpoint Alias for production clients so a release does not require an application
change. Target a Managed Subgraph when new versions should reach clients only once indexed.

Queries and managed indexing use the rates on [Usage and limits](/subgraphs/usage-and-limits).

## Next steps

* [Query your first Subgraph](/subgraphs/getting-started): Read pools from an existing deployment and check its freshness.
* [Managed Subgraphs](/subgraphs/managed-subgraphs): Keep your Subgraph indexed and promote new versions on your schedule.
* [Discover Subgraphs](/subgraphs/guides/discover-public-subgraphs): Find a dataset, inspect its schema, and get an endpoint.