On the decentralized network, retrieving the necessary data is pretty straightforward. Information about subgraphs, their versions and deployments, and the networks they're deployed to can all be queried directly from the Graph Network Subgraph.

However, information about versions, deployments, and networks for subgraphs on the hosted service cannot be queried in a similar manner. Rather, it must be retrieved using subscriptions.

Disclaimer: Due to stability concerns, subscriptions are currently discouraged from being used by developers building with The Graph. The Guild is working on a more robust solution.

Anyway, subscriptions use an endpoint URL similar to queries (api.thegraph.com/explorer/graphql), but with a "wss://" scheme. WebSockets facilitate a persistent connection between a client and server for exchanging information.

There are three requests that need to be made to retrieve hosted service subgraph and deployment data:

1. Initializing the connection.

{
    "type": "connection_init",
    "payload": {}
}

2. Requesting subgraph data using an account and subgraph name pair.

{
    "id": "1",
    "type": "start",
    "payload": {
        "variables": {
            "accountName": "graphprotocol",
            "subgraphName": "graph-network-mainnet"
        },
        "extensions": {},
        "operationName": "subgraph",
        "query": "subscription subgraph($accountName: String!, $subgraphName: String!) {\n  subgraph(accountName: $accountName, subgraphName: $subgraphName) {\n    id\n    draft\n    featured\n    name\n    displayName\n    description\n    image\n    createdAt\n    githubUrl\n    currentVersion {\n      id\n      __typename\n    }\n    pendingVersion {\n      id\n      __typename\n    }\n    __typename\n  }\n}\n"
    }
}

3. Requesting subgraph version data using the resultant subgraph ID, as well as the account and subgraph name pair.

{
    "id": "2",
    "type": "start",
    "payload": {
        "variables": {
            "id": "968da282401fef9f0cd3306a6cca246c",
            "subgraphName": "graphprotocol\/graph-network-mainnet",
            "useSubgraphName": true
        },
        "extensions": {},
        "operationName": "subgraphVersion",
        "query": "subscription subgraphVersion($id: ID!, $subgraphName: String!, $useSubgraphName: Boolean!) {\n  subgraphVersion(id: $id, subgraphName: $subgraphName, useSubgraphName: $useSubgraphName) {\n    id\n    createdAt\n    description\n    repository\n    deployment\n    ethereumNetwork\n    status\n    processedEthereumBlocks\n    totalEthereumBlocks\n    endpoints {\n      query\n      subscription\n      __typename\n    }\n    __typename\n  }\n}\n"
    }
}

The server response after step three should look something like this:

{
    "type": "data",
    "id": "2",
    "payload": {
        "data": {
            "subgraphVersion": {
                "id": "968da282401fef9f0cd3306a6cca246c",
                "createdAt": "2022-05-14T23:30:43.000Z",
                "description": "The Graph Network Smart Contracts on Ethereum",
                "repository": "https:\/\/github.com\/graphprotocol\/graph-network-subgraph",
                "deployment": "QmUwkN7HRoY8VcmqkW9f1hEPftdCQCwtr5thDnXFPrTvWR",
                "ethereumNetwork": "mainnet",
                "status": "SYNCED",
                "processedEthereumBlocks": "15111035",
                "totalEthereumBlocks": "15111035",
                "endpoints": {
                    "query": "https:\/\/api.thegraph.com\/subgraphs\/name\/graphprotocol\/graph-network-mainnet",
                    "subscription": "wss:\/\/api.thegraph.com\/subgraphs\/name\/graphprotocol\/graph-network-mainnet",
                    "__typename": "SubgraphVersionEndpoints"
                },
                "__typename": "SubgraphVersion"
            }
        }
    }
}

The “ethereumNetwork” field, of course, specifies the network for a subgraph deployed to the hosted service.