Shadow
  • 🌗Overview
  • 🏁Quickstart
  • 🎯Use cases
  • ⛓️Supported chains
  • MODIFY CONTRACTS
    • Versioning
    • How to's
      • Proxy contracts
      • Using oracles
      • Factory contracts
      • Interdependent shadow contracts
  • GETTING DATA
    • Shadow RPC
    • Database syncs
    • Recurring exports
    • One-off exports
    • API Keys
  • Integrations
    • Postgres
    • GCS / S3
    • Dune
  • Product Guide
    • Catalog
    • Test runs
    • Subgraphs
  • Tips
    • Proxy contracts
    • Solidity beginners
      • Recommended tools
  • Resources
    • 📚Concepts
    • ❓FAQs
Powered by GitBook
On this page
  • Why use Shadow with subgraphs?
  • Integrations
  • Local Graph Node
Export as PDF
  1. Product Guide

Subgraphs

PreviousTest runsNextProxy contracts

Last updated 7 months ago

Shadow RPCs support the read methods required by most subgraph services.

You can run a local subgraph pointed to a Shadow RPC today, and we're actively working on integrations with hosted subgraph providers.

Why use Shadow with subgraphs?

You can significantly reduce the time to resync your subgraph by moving pieces of indexing logic into custom shadow events. For example, if your subgraph currently:

  • Uses bindings to call contract view functions for state data

  • Uses any callHandlers

  • Recreates contract logic in AssemblyScript to arrive at required values

Then you'll be able to make your subgraph sync much faster with Shadow.

Instead of making slow and expensive RPC calls, relying on function tracing, or writing complex logic in AssemblyScript, you can move everything into simple eventHandlers with custom shadow events.

Moving indexing logic into Solidity also makes your subgraph more end-to-end testable, reducing the engineering time for releasing new features and debugging indexing problems.

Our team can pair with you to evaluate potential subgraph performance improvements. If you're interested in getting direct support from our engineering team on this, please email .

Integrations

Local Graph Node

Configure your local node to use your Shadow RPC URL as a provider for your desired chain and include your Shadow API key as part of the provider details by using the `X-SHADOW-API-KEY` custom header. For more info, see The Graph's documentation on .

Step-by-step instructions on setting up a local graph node pointed to your Shadow RPC.

  1. Migrate your shadow contracts to a local solidity project where you can compile the base contract as well as generate respective ABI bindings (e.g. Foundry, Hardhat)

    • Points to the appropriate local contract dependencies (i.e, abi.json, source path)

    • Contains the shadow events in the eventHandlers mapping

    • Uses the correct onchain address

  2. Create and deploy your local subgraph to your local node; e.g:

  3. Verify that your shadow logs are being indexed by verifying your postgres db. There should be sgd* database schema with unique tables per each contract event id. (e.g, sgd0/transfer)

a local graph node instance; requirements:

URL

Local instance

access (local/remote)

Graph

subgraph project using your local shadow contract instead of pointing to an Etherscan explorer

Verify that your subgraph.yaml :

graph create --node SUBGRAPH_NAME

graph deploy SUBGRAPH_NAME --ipfs --node

fast@shadow.xyz
local Graph Node configuration
Spin up
Shadow fork
IPFS
Postgres
CLI
Initialize
manifest
http://127.0.0.1:8020
http://127.0.0.1:5001
http://127.0.0.1:8020