Subscribe to Zeeve
ZeeveThe Hottest Rollup Framework in 2025? Here’s What to Know
Whether we talk about Rollups’ state in 2024 or the current year, L2 rollups have gained unrealistic growth & adoption with $10.22B TVL, $31.25B TVS, and close to 400 chains launched already. Ethereum’s pro-dank sharding upgrade, Stage-1 decentralization, Dencun upgrade, Optimism’s Bedrock upgrade, Polygon’s AggLayer, and Elastic Network from ZKSYNC are the major reasons behind this tremendous growth. Due to such popularity, choosing the Rollups framework can be really a challenge, especially...
ZeeveUse Cases To Make Room For Blockchain To Evolve in the BFSI Segment
e momIn the last article “ The Industrialization of Blockchain in Banking, Financial Services, and Insurance” a lengthy discussion ideally anchored blockchain as the force multiplier or a problem solver for the BFSI sector. But merely anchoring blockchain as the silver bullet in the BFSI sector will not be enough unless tangible impacts can be accounted for. In this piece, some of the use-cases with real time impact will provide tangible proof that blockchain is indeed changing the face of BF...
ZeeveOvercoming Historical Light Client Limitations in L2 rollups with Alt DA layers
Rollups are suffering under one grave problem where they need to be highly interoperable with other ecosystems for not diluting the liquidity. However, in order to do that, they need cost-efficient data availability solutions for validation, which should be decentralized and secure. That’s where the light nodes/clients are making a difference. In this piece, we shall deep dive to understand how light nodes/clients are allowing the rollups to maintain the integrity of the network without compr...
<100 subscribers
ZeeveThe Hottest Rollup Framework in 2025? Here’s What to Know
Whether we talk about Rollups’ state in 2024 or the current year, L2 rollups have gained unrealistic growth & adoption with $10.22B TVL, $31.25B TVS, and close to 400 chains launched already. Ethereum’s pro-dank sharding upgrade, Stage-1 decentralization, Dencun upgrade, Optimism’s Bedrock upgrade, Polygon’s AggLayer, and Elastic Network from ZKSYNC are the major reasons behind this tremendous growth. Due to such popularity, choosing the Rollups framework can be really a challenge, especially...
ZeeveUse Cases To Make Room For Blockchain To Evolve in the BFSI Segment
e momIn the last article “ The Industrialization of Blockchain in Banking, Financial Services, and Insurance” a lengthy discussion ideally anchored blockchain as the force multiplier or a problem solver for the BFSI sector. But merely anchoring blockchain as the silver bullet in the BFSI sector will not be enough unless tangible impacts can be accounted for. In this piece, some of the use-cases with real time impact will provide tangible proof that blockchain is indeed changing the face of BF...
ZeeveOvercoming Historical Light Client Limitations in L2 rollups with Alt DA layers
Rollups are suffering under one grave problem where they need to be highly interoperable with other ecosystems for not diluting the liquidity. However, in order to do that, they need cost-efficient data availability solutions for validation, which should be decentralized and secure. That’s where the light nodes/clients are making a difference. In this piece, we shall deep dive to understand how light nodes/clients are allowing the rollups to maintain the integrity of the network without compr...
Share Dialog
Share Dialog
Whether you are building a dApp or you want to enhance the functionality of your existing web3 applications– you must need indexed on-chain data from a range of blockchains and decentralized networks. However, querying data out of the blockchain’s distributed ledger is a complex task. To provide a solution, The Graph protocol simplifies data querying and indexing with its powerful data indexing infrastructure and Subgraph.
Want to know more about how data indexing and querying work on the Graph network and Subgraph? Read our comprehensive guide on this below:
How to query Web3 data using The Graph Protocol and Subgraphs
This guide provides you step-by-step process of how to deploy custom Subgraph with the Graph protocol’s hosted service.
A lot of web3 projects want to perform customized data queries because general-purpose queries do not cater to their specific data needs. For example, some dApps many not just want to leverage Ethereum standards like ERC-721 or ERC. Instead, they want to pull only the data which is highly relevant. These specific types of data requirements can be fulfilled by deploying custom Subgraphs that are designed to run customized GraphQL queries. Custom Subgraphs are frequently used across DeFi, NFTs, gaming, DAOs, and other web3 projects that need very specific blockchain data to streamline their operations.
This guide explains how you can deploy custom Subgraphs on the hosted service. Leveraging this service, you don't need Graph node, GRT tokens for staking, or infrastructure to maintain your Subgraph. Also, The Graph decentralized network currently supports limited networks, while the hosted service is supported for a range of networks. Let’s see the entire process.
Your Subgraph will contain three main files–
subgraph.yaml: A file defining Subgraph manifest,
schema.graphql: GraphQL schema for defining what type of data needs to be stored in your Subgraph, and how it can be queries via GraphQL, and finally the
AssemblyScript Mappings: code for translating event data to all the entities you define in the schema.
Assuming that you have completed the above process, let’s start deploying your custom Subgraph.
Create your Subgraph first. Visit the dashboard and proceed to ‘Add Subgraph’ option. Further, you need to provide some information for initialization such as image, Subgraph name, account, subtitle, description, Github url, and hide. Once you provide all the details, save your Subgraph. Upon this, a screen will appear that will explains you the process of installing the Graph CLI and generating scaffolding of your new Subgraph. You can learn about both these processes here.
To initiate the deployment of your subgraph, you'll be using the 'yarn deploy' command. This action involves the uploading of the subgraph files created through 'yarn build' to IPFS. Simultaneously, it notifies the Graph Explorer to commence the indexing process on your subgraph using these uploaded files.
Once the subgraph deployment is complete, the Graph Explorer will transition to displaying the synchronization status of your subgraph. The time taken for synchronization varies based on factors like the volume of data and the quantity of events to be extracted from historical blocks, commencing with the genesis block. This synchronization process can range from a few minutes to several hours.The subgraph status will switch to 'Synced' once the Graph Node has successfully extracted all data from historical blocks.
If you make modifications to your subgraph definition, such as correcting the entity mapping issues, you should re-run the 'yarn deploy' command to deploy the updated version of your subgraph. Any update to a subgraph necessitates the Graph Node to reindex the entire subgraph once more, starting from the genesis block.
Incase you have previously deployed a subgraph that is still in the 'Syncing' status, it will be promptly replaced by the newly deployed version. However, if the prior version has already achieved full synchronization, the Graph Node will designate the newly deployed version as the 'Pending Version.' It will initiate background syncing and will only replace the presently deployed version with the new one once the synchronization of the new version has been completed. This approach ensures that you have a functional subgraph to work and in the meantime a new version is syncing.
With you deployed Subgraph, visit the Hosted Service, that will open a GraphQL interface. From here, you can explore the deployed GraphQL API of your Subgraph through issuing the queries and viewing its schema.
Note that the Graph hosted service has begun sunsetting, and it will become unavailable to users soon. However, as we know, there are a lot of benefits to using a hosted service. For example, you don’t need to manage nodes, stake GRT tokens, manage infrastructure, and so on. That’s where the Zeeve-managed Subgraph hosted service comes in. Let’s learn more about it.
The Subgraph hosted service at Zeeve allows you to deploy your custom Subgraph on all the leading blockchain networks, including ones that are not yet supported on the Graph hosted service. For that, again you do not need to run nodes or stake tokens which you are suppped to do while deploying on The Graph. With this approach, Zeeve-managed services will cut down your Subgraph and deployment and maintenance cost significantly.
Now, let’s learn about the Subgraph deployment process on Zeeve. To build your custom Subgraph with Zeeve platform, you first need to login or sign up on the Zeeve dashboard.
Go to ‘Hosted Subgraphs’ under ‘Buy Services’ and select the quantity of Subgraph units you need. If you want, you can add-on API units and queries as required. Click on Buy Now and complete payment to get subscription for your Subgraph/Subgraphs.
You can either ‘go to dashboard’ or directly ‘setup subgraph’. Alternatively, go to the ‘Manage Services’ and click on ‘Hosted Subgraph’. Create new subgraph from here.
Provide all the necessary information about the Subgraph such as Subgraph name, workspace, blockchain network, and plan type. Zeeve supports different networks such as Avalanche and Ethereum. Also, there’s a option of custom netwo
Provide all the necessary information about the Subgraph such as Subgraph name, workspace, blockchain network, and plan type. Zeeve supports different networks such as Avalanche and Ethereum. Also, there’s a option of custom network where you can add the RPC endpoint of your desired blockchain network and add it to the platform.
rk where you can add the RPC endpoint of your desired blockchain network and add it to the platform.
Now, click on ‘Add Subgraph’ to complete the deployment. It will open a details page where the status of your Subgraph will by default visible as ‘Not Deployed’. On this same page, you will get Deployment command URL and Query URL. With this, again go to the Graph CLI and deploy your Subgraph. Once deployed, the status will change to ‘Deployed’ and your Subgraph will be ready to query the web3 data.
Regarding the Query URL, you can use it on PostSQL to check the entire query requests made in the past 24 hours and the total API consumption units.
Zeeve provides completely monitored and managed nodes. Zeeve proactively monitor your deployed Subgraph, check the logs, and check errors if any. The monitoring is done on critical parameters such as Info, Debug, Warning, and Error. Plus, the upgrades are released automatically.
As discussed, the Graph protocol offers a fully a powerful, and highly efficient infrastructure to deploy custom Subgraphs for retrieving data from a range of blockchains. However, you can discuss all your concerns with Subgraph development and the Graph network with the blockchain experts at Zeeve. We are happy to assist you. Drop your queries via email on this page or you can also schedule one-to-one call with our consultants.
Whether you are building a dApp or you want to enhance the functionality of your existing web3 applications– you must need indexed on-chain data from a range of blockchains and decentralized networks. However, querying data out of the blockchain’s distributed ledger is a complex task. To provide a solution, The Graph protocol simplifies data querying and indexing with its powerful data indexing infrastructure and Subgraph.
Want to know more about how data indexing and querying work on the Graph network and Subgraph? Read our comprehensive guide on this below:
How to query Web3 data using The Graph Protocol and Subgraphs
This guide provides you step-by-step process of how to deploy custom Subgraph with the Graph protocol’s hosted service.
A lot of web3 projects want to perform customized data queries because general-purpose queries do not cater to their specific data needs. For example, some dApps many not just want to leverage Ethereum standards like ERC-721 or ERC. Instead, they want to pull only the data which is highly relevant. These specific types of data requirements can be fulfilled by deploying custom Subgraphs that are designed to run customized GraphQL queries. Custom Subgraphs are frequently used across DeFi, NFTs, gaming, DAOs, and other web3 projects that need very specific blockchain data to streamline their operations.
This guide explains how you can deploy custom Subgraphs on the hosted service. Leveraging this service, you don't need Graph node, GRT tokens for staking, or infrastructure to maintain your Subgraph. Also, The Graph decentralized network currently supports limited networks, while the hosted service is supported for a range of networks. Let’s see the entire process.
Your Subgraph will contain three main files–
subgraph.yaml: A file defining Subgraph manifest,
schema.graphql: GraphQL schema for defining what type of data needs to be stored in your Subgraph, and how it can be queries via GraphQL, and finally the
AssemblyScript Mappings: code for translating event data to all the entities you define in the schema.
Assuming that you have completed the above process, let’s start deploying your custom Subgraph.
Create your Subgraph first. Visit the dashboard and proceed to ‘Add Subgraph’ option. Further, you need to provide some information for initialization such as image, Subgraph name, account, subtitle, description, Github url, and hide. Once you provide all the details, save your Subgraph. Upon this, a screen will appear that will explains you the process of installing the Graph CLI and generating scaffolding of your new Subgraph. You can learn about both these processes here.
To initiate the deployment of your subgraph, you'll be using the 'yarn deploy' command. This action involves the uploading of the subgraph files created through 'yarn build' to IPFS. Simultaneously, it notifies the Graph Explorer to commence the indexing process on your subgraph using these uploaded files.
Once the subgraph deployment is complete, the Graph Explorer will transition to displaying the synchronization status of your subgraph. The time taken for synchronization varies based on factors like the volume of data and the quantity of events to be extracted from historical blocks, commencing with the genesis block. This synchronization process can range from a few minutes to several hours.The subgraph status will switch to 'Synced' once the Graph Node has successfully extracted all data from historical blocks.
If you make modifications to your subgraph definition, such as correcting the entity mapping issues, you should re-run the 'yarn deploy' command to deploy the updated version of your subgraph. Any update to a subgraph necessitates the Graph Node to reindex the entire subgraph once more, starting from the genesis block.
Incase you have previously deployed a subgraph that is still in the 'Syncing' status, it will be promptly replaced by the newly deployed version. However, if the prior version has already achieved full synchronization, the Graph Node will designate the newly deployed version as the 'Pending Version.' It will initiate background syncing and will only replace the presently deployed version with the new one once the synchronization of the new version has been completed. This approach ensures that you have a functional subgraph to work and in the meantime a new version is syncing.
With you deployed Subgraph, visit the Hosted Service, that will open a GraphQL interface. From here, you can explore the deployed GraphQL API of your Subgraph through issuing the queries and viewing its schema.
Note that the Graph hosted service has begun sunsetting, and it will become unavailable to users soon. However, as we know, there are a lot of benefits to using a hosted service. For example, you don’t need to manage nodes, stake GRT tokens, manage infrastructure, and so on. That’s where the Zeeve-managed Subgraph hosted service comes in. Let’s learn more about it.
The Subgraph hosted service at Zeeve allows you to deploy your custom Subgraph on all the leading blockchain networks, including ones that are not yet supported on the Graph hosted service. For that, again you do not need to run nodes or stake tokens which you are suppped to do while deploying on The Graph. With this approach, Zeeve-managed services will cut down your Subgraph and deployment and maintenance cost significantly.
Now, let’s learn about the Subgraph deployment process on Zeeve. To build your custom Subgraph with Zeeve platform, you first need to login or sign up on the Zeeve dashboard.
Go to ‘Hosted Subgraphs’ under ‘Buy Services’ and select the quantity of Subgraph units you need. If you want, you can add-on API units and queries as required. Click on Buy Now and complete payment to get subscription for your Subgraph/Subgraphs.
You can either ‘go to dashboard’ or directly ‘setup subgraph’. Alternatively, go to the ‘Manage Services’ and click on ‘Hosted Subgraph’. Create new subgraph from here.
Provide all the necessary information about the Subgraph such as Subgraph name, workspace, blockchain network, and plan type. Zeeve supports different networks such as Avalanche and Ethereum. Also, there’s a option of custom netwo
Provide all the necessary information about the Subgraph such as Subgraph name, workspace, blockchain network, and plan type. Zeeve supports different networks such as Avalanche and Ethereum. Also, there’s a option of custom network where you can add the RPC endpoint of your desired blockchain network and add it to the platform.
rk where you can add the RPC endpoint of your desired blockchain network and add it to the platform.
Now, click on ‘Add Subgraph’ to complete the deployment. It will open a details page where the status of your Subgraph will by default visible as ‘Not Deployed’. On this same page, you will get Deployment command URL and Query URL. With this, again go to the Graph CLI and deploy your Subgraph. Once deployed, the status will change to ‘Deployed’ and your Subgraph will be ready to query the web3 data.
Regarding the Query URL, you can use it on PostSQL to check the entire query requests made in the past 24 hours and the total API consumption units.
Zeeve provides completely monitored and managed nodes. Zeeve proactively monitor your deployed Subgraph, check the logs, and check errors if any. The monitoring is done on critical parameters such as Info, Debug, Warning, and Error. Plus, the upgrades are released automatically.
As discussed, the Graph protocol offers a fully a powerful, and highly efficient infrastructure to deploy custom Subgraphs for retrieving data from a range of blockchains. However, you can discuss all your concerns with Subgraph development and the Graph network with the blockchain experts at Zeeve. We are happy to assist you. Drop your queries via email on this page or you can also schedule one-to-one call with our consultants.
No comments yet