add substreams config provider #3897
Conversation
mangas
force-pushed
the
filipe/add-substreams-cfg-provider
branch
from
e93862d to
1e94c0d
Compare
|
LGTM, is anything missing here? |
|
See discussion here: https://forum.thegraph.com/t/substreams-into-subgraphs-a-simple-integration/3542 |
mangas
force-pushed
the
filipe/add-substreams-cfg-provider
branch
from
bcfda90 to
01b19c6
Compare
mangas
force-pushed
the
filipe/add-substreams-cfg-provider
branch
from
01b19c6 to
8590513
Compare
| @@ -334,10 +319,12 @@ async fn main() { | |||
| node_id.clone(), | |||
| metrics_registry.clone(), | |||
| firehose_networks_by_kind.get(&BlockchainKind::Ethereum), | |||
| substreams_networks_by_kind.get(&BlockchainKind::Ethereum), | |||
There was a problem hiding this comment.
This will start to be interesting because this force a substreams right not be for a "known" network. substreams brings the possibility to support an infinite number of chain as long as an substreams endpoint exist.
Going full free form raises interesting question though. I think it would be a good subject for Wednesday weekly call.
There was a problem hiding this comment.
For querying there are some aspects like block resolution that require the block cache to be populated. This is why we've gone this way. By being an endpoint type, we can require the chain to be ingested and thus we can rely on the ChainStore for block resolution and "close to head" status
There was a problem hiding this comment.
Otherwise we'd need a "substreams" ingestor if that makes sense
Adds substreams as a provider type rather than a protocol.