[Feature] Expose utility to generate "full" API schema from entities GQL schema

[monitz87]

Description

As it is, the only way to get the "true" GQL API schema is to deploy a subgraph and perform an introspection query. This is very painful for tooling and codegen purposes. It would be very nice to be able to generate the full schema locally from the "entities" schema.

I noticed this is relatively easy to isolate, as it is being done here: https://github.com/graphprotocol/graph-node/blob/252e9129588b0b022bcaf50bbe365287db18241b/graphql/examples/schema.rs

I'm actually in the process of creating a docker image that does exactly that. I basically cloned this repo, added a build target for that script and created a dockerfile that runs it, but it is not a very elegant solution. I'll still share it here once it's up in case someone else needs it.

I know this is more of a feature request for the CLI, but since the relevant code resides in this repo, and the CLI repo doesn't have a "Feature Request" template, I thought I'd open the issue here.

Are you aware of any blockers that must be resolved before implementing this feature? If so, which? Link to any relevant GitHub issues.

No response

Some information to help us out

• Tick this box if you plan on implementing this feature yourself.
• I have searched the issue tracker to make sure this issue is not a duplicate.

[monitz87]

For anyone who's interested in a temporary workaround:

As I said, I created a docker image that takes the entities schema as input and outputs the full subgraph GQL API schema

Dockerhub repo: https://hub.docker.com/repository/docker/monitz87/graphprotocol-schema-generator/general
Github repo (basically a fork of this one): https://github.com/monitz87/graph-node-schema-generator

[github-actions]

Looks like this issue has been open for 6 months with no activity. Is it still relevant? If not, please remember to close it.

[monitz87]

Yup, still relevant. Just updated the image to be in sync with the current graph node master btw

[azf20]

thanks @monitz87 - @saihaj @lutter any thoughts here?

[saihaj]

For GraphQL Codegen purposes just providing the URL should work by giving the subgraph URL.

I do like this proposal, I also need something similar in CLI where we can provide the Subgraph definition and generate a Schema graph-node will generate.

We did start exploring to create utilities which can be exposed in a new crate we publish and we can consume using NAPI in CLI. So once we do get NAPI setup working for validation in CLI we can also expose a helper in CLI for this but yeah if it is just a crate users should be able to use in Rust code as is

[monitz87]

For GraphQL Codegen purposes just providing the URL should work by giving the subgraph URL.

The idea is to be able to iterate and develop locally without having to actually deploy a subgraph

[saihaj]

For GraphQL Codegen purposes just providing the URL should work by giving the subgraph URL.

The idea is to be able to iterate and develop locally without having to actually deploy a subgraph

👍🏼 so the latter part I am talking about building out NAPI utilities (if it works) we can expose via cli

[lutter]

The code to do this would be very easy on the graph-node side. There's an example that does just that. You can run it with cargo run --example schema <subgraph schema> The big question how this should be exposed in the end. If we ever get N-API working against graph-node, doing it from graph-cli would probably be the easiest for users.

[azf20]

checking in on feasibility of this? agree that graph-cli is probably the place from a developer experience perspective