|
| 1 | +--- |
| 2 | +title: Enhance Your Subgraph Build Using Subgraph Composition with Sushiswap v3 on Base |
| 3 | +sidebarTitle: 'Using Subgraph Composition with Sushiswap v3 on Base' |
| 4 | +--- |
| 5 | + |
| 6 | +Leverage Subgraph composition to speed up development time. Create a base Subgraph with essential data, then build additional Subgraphs on top of it. |
| 7 | + |
| 8 | +> Important Reminders: |
| 9 | +> |
| 10 | +> - Subgraph composition is built into the CLI, and you can deploy with [Subgraph Studio](https://thegraph.com/studio/). |
| 11 | +> - You can use existing Subgraphs, but they must be redeployed with `specVersion` 1.3.0, which doesn't require you to write new code. |
| 12 | +> - You may want to restructure your Subgraph to split out the logic as you move to a composable Subgraph world. |
| 13 | +
|
| 14 | +## Introduction |
| 15 | + |
| 16 | +Composable Subgraphs enable you to combine multiple Subgraphs' data sources into a new Subgraph, facilitating faster and more flexible Subgraph development. Subgraph composition empowers you to create and maintain smaller, focused subgraphs that collectively form a larger, interconnected dataset. |
| 17 | + |
| 18 | +### Benefits of Composition |
| 19 | + |
| 20 | +Subgraph composition is a powerful feature for scaling, allowing you to: |
| 21 | + |
| 22 | +- Reuse, mix, and combine existing data |
| 23 | +- Streamline development and queries |
| 24 | +- Use multiple data sources (up to five source Subgraphs) |
| 25 | +- Speed up your Subgraph's syncing speed |
| 26 | +- Handle errors and optimize the resync |
| 27 | + |
| 28 | +## Architecture Overview |
| 29 | + |
| 30 | +The setup for this example involves two Subgraphs: |
| 31 | + |
| 32 | +1. **Source Subgraph**: Tracks event data as entities. |
| 33 | +2. **Dependent Subgraph**: Uses the source Subgraph as a data source. |
| 34 | + |
| 35 | +You can find these in the `source` and `dependent` directories. |
| 36 | + |
| 37 | +- The **source Subgraph** is a basic event-tracking Subgraph that records events emitted by relevant contracts. |
| 38 | +- The **dependent Subgraph** references the source Subgraph as a data source, using the entities from the source as triggers. |
| 39 | + |
| 40 | +While the source Subgraph is a standard Subgraph, the dependent Subgraph uses the Subgraph composition feature. |
| 41 | + |
| 42 | +### Source Subgraph |
| 43 | + |
| 44 | +The source Subgraph tracks events from the Sushiswap v3 Subgraph on the Base chain. This Subgraph's configuration file is `source/subgraph.yaml`. |
| 45 | + |
| 46 | +> The `source/subgraph.yaml` employs the advanced Subgraph feature, [declarative `eth_calls`](https://thegraph.com/docs/en/subgraphs/developing/creating/advanced/#declared-eth_call). To review the code for this `source/subgraph.yaml`, check out the [source Subgraph example repo](https://github.com/incrypto32/subgraph-composition-sample-subgraph/blob/a5f13cb4b961f92d5c5631dca589c54feb1c0a19/source/subgraph.yaml). |
| 47 | +
|
| 48 | +### Dependent Subgraph |
| 49 | + |
| 50 | +The dependent Subgraph is in the `dependent/subgraph.yaml` file, which specifies the source Subgraph as a data source. This Subgraph uses entities from the source to trigger specific actions based on changes to those entities. |
| 51 | + |
| 52 | +> To review the code for this `dependent/subgraph.yaml`, check out the [dependent Subgraph example repo](https://github.com/incrypto32/subgraph-composition-sample-subgraph/blob/main/dependant/subgraph.yaml). |
| 53 | +
|
| 54 | +## Get Started |
| 55 | + |
| 56 | +The following is a guide that illustrates how to use one Subgraph as a data source for another. This example uses: |
| 57 | + |
| 58 | +- Sushiswap v3 Subgraph on Base chain |
| 59 | +- Two Subgraphs (but you can use up to **5 source** Subgraphs in your own development). |
| 60 | + |
| 61 | +### Step 1. Set Up Your Source Subgraph |
| 62 | + |
| 63 | +To set the source Subgraph as a data source in the dependent Subgraph, include the following in `subgraph.yaml`: |
| 64 | + |
| 65 | +```yaml |
| 66 | +specVersion: 1.3.0 |
| 67 | +schema: |
| 68 | + file: ./schema.graphql |
| 69 | +dataSources: |
| 70 | + - kind: subgraph |
| 71 | + name: Factory |
| 72 | + network: base |
| 73 | + source: |
| 74 | + address: 'QmdXu8byAFCGSDWsB5gMQjWr6GUvEVB7S1hemfxNuomerz' |
| 75 | + startBlock: 82522 |
| 76 | +``` |
| 77 | +
|
| 78 | +Here, `source.address` refers to the Deployment ID of the source Subgraph, and `startBlock` specifies the block from which indexing should begin. |
| 79 | + |
| 80 | +### Step 2. Define Handlers in Dependent Subgraph |
| 81 | + |
| 82 | +Below is an example of defining handlers in the dependent Subgraph: |
| 83 | + |
| 84 | +```typescript |
| 85 | +export function handleInitialize(trigger: EntityTrigger<Initialize>): void { |
| 86 | + if (trigger.operation === EntityOp.Create) { |
| 87 | + let entity = trigger.data |
| 88 | + let poolAddressParam = Address.fromBytes(entity.poolAddress) |
| 89 | +
|
| 90 | + // Update pool sqrt price and tick |
| 91 | + let pool = Pool.load(poolAddressParam.toHexString()) as Pool |
| 92 | + pool.sqrtPrice = entity.sqrtPriceX96 |
| 93 | + pool.tick = BigInt.fromI32(entity.tick) |
| 94 | + pool.save() |
| 95 | +
|
| 96 | + // Update token prices |
| 97 | + let token0 = Token.load(pool.token0) as Token |
| 98 | + let token1 = Token.load(pool.token1) as Token |
| 99 | +
|
| 100 | + // Update ETH price in USD |
| 101 | + let bundle = Bundle.load('1') as Bundle |
| 102 | + bundle.ethPriceUSD = getEthPriceInUSD() |
| 103 | + bundle.save() |
| 104 | +
|
| 105 | + updatePoolDayData(entity) |
| 106 | + updatePoolHourData(entity) |
| 107 | +
|
| 108 | + // Update derived ETH price for tokens |
| 109 | + token0.derivedETH = findEthPerToken(token0) |
| 110 | + token1.derivedETH = findEthPerToken(token1) |
| 111 | + token0.save() |
| 112 | + token1.save() |
| 113 | + } |
| 114 | +} |
| 115 | +``` |
| 116 | + |
| 117 | +In this example, the `handleInitialize` function is triggered when a new `Initialize` entity is created in the source Subgraph, passed as `EntityTrigger<Initialize>`. The handler updates the pool and token entities based on data from the new `Initialize` entity. |
| 118 | + |
| 119 | +`EntityTrigger` has three fields: |
| 120 | + |
| 121 | +1. `operation`: Specifies the operation type, which can be `Create`, `Modify`, or `Remove`. |
| 122 | +2. `type`: Indicates the entity type. |
| 123 | +3. `data`: Contains the entity data. |
| 124 | + |
| 125 | +Developers can then determine specific actions for the entity data based on the operation type. |
| 126 | + |
| 127 | +## Key Takeaways |
| 128 | + |
| 129 | +- Use this powerful tool to quickly scale your Subgraph development and reuse existing data. |
| 130 | +- The setup includes creating a base source Subgraph and referencing it in a dependent Subgraph. |
| 131 | +- You define handlers in the dependent Subgraph to perform actions based on changes in the source Subgraph's entities. |
| 132 | + |
| 133 | +This approach unlocks composability and scalability, simplifying both development and maintenance efficiency. |
| 134 | + |
| 135 | +## Additional Resources |
| 136 | + |
| 137 | +To use other advanced features in your Subgraph, check out [Subgraph advanced features](/developing/creating/advanced/) and [this Subgraph composition example repo](https://github.com/incrypto32/subgraph-composition-sample-subgraph). |
| 138 | + |
| 139 | +To learn how to define three source Subgraphs, check out [this Subgraph composition example repo](https://github.com/isum/subgraph-composition-example). |
0 commit comments