Thanks for hosting this, and providing a glimpse of the future at datapalooza.
The separation of Extraction, transformation, Loading and Querying data seems to be key to accelerating the availability and flexibility of the data provided by the graph. Sam’s announcement of bringing clickhouse SQL to the graph really excites me, as I’m currently wasting a lot of time writing/maintaining code to make aggregations over data as part of the transform step, instead of aggregating at query-time.
What can we expect to see for the rollout of clickhouse SQL on the graph?
Since this is dependent on substreams, which in turn depend on firehose, what steps are needed to get substreams working on OP stack chains?
Will there be a way to get an “event substream” without call handlers shipped earlier than the full firehose implementation for OP stack chains, as this can be done with just an RPC instead of instrumenting OP-geth or OP-reth?
Thanks for hosting this, and providing a glimpse of the future at datapalooza.
The separation of Extraction, transformation, Loading and Querying data seems to be key to accelerating the availability and flexibility of the data provided by the graph. Sam’s announcement of bringing clickhouse SQL to the graph really excites me, as I’m currently wasting a lot of time writing/maintaining code to make aggregations over data as part of the transform step, instead of aggregating at query-time.
What can we expect to see for the rollout of clickhouse SQL on the graph?
Since this is dependent on substreams, which in turn depend on firehose, what steps are needed to get substreams working on OP stack chains?
Will there be a way to get an “event substream” without call handlers shipped earlier than the full firehose implementation for OP stack chains, as this can be done with just an RPC instead of instrumenting OP-geth or OP-reth?
Thanks.