You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The postgres sink could get a port of the WASM Query layer from the sink-kv, and expose the pg_query() method to the WASM VM, where results could be packed in a general protobuf for response. (the sink-kv WASM Query is based on gRPC + Connect Web).
This means one could craft any SQL query, and specify the indexes necessary in the sink configuration, to satisfy requests that are baked into the WASM.
In this case, the protocol is (at start) gRPC, but could grow to be GraphQL, REST, or whatever we want to pack in the WASM server literally. We can think of exposing even an http request/response mechanism inside the WASM.. so you'd have your router there in, etc.. packed as a deployable unit (which is critical for permissionless The Graph Network deployment).
HasuraQuery layer
would mean we build a proto file that packs all of the configuration for Hasura, and the sink would be able to configure hasura and take care of writing to postgres from a Substreams module.
PostgraphileQuery
same thing as with Hasura, but fronted by Postgraphile... with its config packed in an spkg and deployed to the network as a deployable unit.
NativePostgresConnection
This would expose the port with native pg protocol allowing you to plug the endpoint directly in Looker or other BI tools. That's obviously database specific
RegexpQuery
This could expose a simple well-defined REST interface, that accepts a simple query=SELECT * FROM $1¶m=table, filtered through a predefined regexp list of queries specified in the Query Layer config protobuf object (packed into the spkg).
Here's a top-level design draft of new query layers on top of the this
postgres
sink:Prior art
The KV Sink has a WASM Query and GenericQuery sink configurations. Here are the configuration structures. Here is an example usage.
sink-kv
, and expose thepg_query()
method to the WASM VM, where results could be packed in a general protobuf for response. (the sink-kv WASM Query is based on gRPC + Connect Web).This means one could craft any SQL query, and specify the indexes necessary in the sink configuration, to satisfy requests that are baked into the WASM.
In this case, the protocol is (at start) gRPC, but could grow to be GraphQL, REST, or whatever we want to pack in the WASM server literally. We can think of exposing even an http request/response mechanism inside the WASM.. so you'd have your router there in, etc.. packed as a deployable unit (which is critical for permissionless The Graph Network deployment).
would mean we build a proto file that packs all of the configuration for Hasura, and the sink would be able to configure hasura and take care of writing to postgres from a Substreams module.
same thing as with Hasura, but fronted by Postgraphile... with its config packed in an
spkg
and deployed to the network as a deployable unit.This would expose the port with native pg protocol allowing you to plug the endpoint directly in Looker or other BI tools. That's obviously database specific
This could expose a simple well-defined REST interface, that accepts a simple
query=SELECT * FROM $1¶m=table
, filtered through a predefined regexp list of queries specified in the Query Layer config protobuf object (packed into thespkg
).The text was updated successfully, but these errors were encountered: