Substreams-powered subgraphs cookbook #401
Conversation
📦 Next.js Bundle Analysis for @graphprotocol/docsThis analysis was generated by the Next.js Bundle Analysis action. 🤖
|
| Page | Size (compressed) |
|---|---|
global |
639.95 KB (🟡 +72 B) |
Details
The global bundle is the javascript bundle that loads alongside every page. It is in its own category because its impact is much higher - an increase to its size means that every page on your website loads slower, and a decrease means every page loads faster.
Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis
If you want further insight into what is behind the changes, give @next/bundle-analyzer a try!
New Page Added
The following page was added to the bundle from the code in this PR:
| Page | Size (compressed) | First Load | % of Budget (350 KB) |
|---|---|---|---|
/en/cookbook/substreams-powered-subgraphs |
65.63 KB |
705.59 KB | 201.60% |
One Page Changed Size
The following page changed size from the code in this PR compared to its base branch:
| Page | Size (compressed) | First Load | % of Budget (350 KB) |
|---|---|---|---|
/en/querying/graph-client/[[...slug]] |
62.74 KB |
702.69 KB | 200.77% (🟡 +0.03%) |
Details
Only the gzipped size is provided here based on an expert tip.
First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If next/link is used, subsequent page loads would only need to download that page's bundle (the number in the "Size" column), since the global bundle has already been downloaded.
Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis
The "Budget %" column shows what percentage of your performance budget the First Load total takes up. For example, if your budget was 100kb, and a given page's first load size was 10kb, it would be 10% of your budget. You can also see how much this has increased or decreased compared to the base branch of your PR. If this percentage has increased by 20% or more, there will be a red status indicator applied, indicating that special attention should be given to this. If you see "+/- <0.01%" it means that there was a change in bundle size, but it is a trivial enough amount that it can be ignored.
|
|
||
| In order to serve Substreams-powered subgraphs, Graph Node must be configured with a Substreams provider for the relevant network, as well as a Firehose or RPC to track the chain head. These providers can be configured via a `config.toml` file: | ||
|
|
||
| ```js |
There was a problem hiding this comment.
| ```js | |
| ```toml |
|
|
||
| imports: | ||
| eth: 'https://github.com/streamingfast/sf-ethereum/releases/download/v0.10.2/ethereum-v0.10.4.spkg' | ||
| entity: 'https://github.com/streamingfast/substreams-entity-change/releases/download/v0.2.1/substreams-entity-change-v0.2.1.spkg' |
There was a problem hiding this comment.
There's a more recent version of this package: https://github.com/streamingfast/substreams-entity-change/releases/tag/v1.1.0
| Given the above, subgraph developers can use Graph CLI >=0.51.0 to build and deploy this Substreams-powered subgraph. | ||
|
|
||
| ```bash | ||
| graph build |
There was a problem hiding this comment.
Does graph build detect that it is working with substreams? Compiling & packing it into the spkg?
I've been doing cargo build + substreams pack + graph deploy all this time 😅
There was a problem hiding this comment.
ah - good catch, graph build actually isn't necessary in this step (you have been doing the right thing).
There was a problem hiding this comment.
But with substreams-js... we actually could build the spkg as part of the Graph CLI in the future (?)
There was a problem hiding this comment.
If that doesn't work, I'd add a note to remind people of building and packing for their changes to be reflected in the subgraph they deploy (or to work at all the first time).
But with substreams-js... we actually could build the spkg as part of the Graph CLI in the future (?)
This could be good :)
Simple integration using a contract-tracking substreams package and the latest
Tableshelper, this is an end-to-end exampleDepends on: graphprotocol/graph-tooling#1371