Provide full `graphql` schema of node for local development

[KholdStare]

We want to generate typescript types from the GraphQL schema and our queries, however just the schema.graphql for subgraph is obviously not enough.

One can get the full schema from a deployed subgraph by following something like this: https://stackoverflow.com/questions/60451843/how-can-one-get-a-complete-graphql-schema-from-an-apollo-server-endpoint

However, that means already having a full graph deployed on a node (even if it's local) in order to get the full schema.

There should be a way to autogenerate this schema locally without having to deploy an entire node.

In the end we want to use tools like https://the-guild.dev/graphql/codegen to be able to generate types and functions for our backend/frontend to interact with our subgraphs in a typesafe and up-to-date manner.

[azf20]

Hi @KholdStare thanks - @dotansimha @ardatan this one could be interesting for graph-client?

[ardatan]

Graph Client already generates types, fully-typed SDK and so on for you by using GraphQL Codegen. It also generates schema.graphql so you can use it with other tools.

[azf20]

@ardatan I think that relies on the deployed subgraph endpoint? (I think @KholdStare is looking to take a graph-node schema.graphql to generate types directly, without deploying the subgraph)

[dotansimha]

@azf20 that's an interesting one. I guess we'll need to replicate (or, reuse somehow? 🤓 ) the schema generation part that lives today in graph-node? And have it available somehow for graph-cli or other tools?

[rdotterer09]

I just wanted to thank all of you for your dedication and hard work, all I ever wanted was access to my contract and couldn't find anyone to help me, RhondaDotterer

[KholdStare]

@ardatan I think that relies on the deployed subgraph endpoint? (I think @KholdStare is looking to take a graph-node schema.graphql to generate types directly, without deploying the subgraph)

Yes, you're right - we're thinking about local development. For example as we develop the next iteration of our subgraph, writing new tests with matchstick, changing the API, etc. it would be nice to see how that affects e.g. the frontend so we don't need to deploy a full-blown node to know the final schema.

It's also something useful for reproducibility of commits and CI - If we need to put a "live" node in our config, CI builds may fail due to connectivity issues, if we revert to an older commit, the tests may no longer work because the schema was different at the time the commit was authored etc.

I think this isn't really unique to the graph protocol - I see putting a live node as the source of the schema as "Standard practice" in frontend GraphQL circles, so it's an uphill battle.

[azf20]

👍 makes sense - as @dotansimha says I think there isn't an easy fix here without porting the Graph Node schema generation from Graph Node

[KholdStare]

@azf20 I see, that's understandable. I wonder if perhaps as a "middle ground" the node itself can do the transformation and spit out the schema without starting up. Then graph-cli can have an option like "If you have the graph-node installed, we can generate the schema for you" where it invokes the graph-node. Alternatively, just having such a "codegen" option on the graph-node will be enough