Does one typically use the graph-cli to generate your schema.graphql

[salieflewis]

Hi, question is essentially in the title.

Curious about what tools people use to autogenerate their schema.graphql.

Follow up question would be, when does it make sense to build that schema from scratch?

[typedarray]

The Ponder codegen command (which also runs continuously while the dev server is running via dev) emits a file at generated/schema.graphql. This is the actual schema that the GraphQL server is using (including all root types and argument types etc). Is this what you're looking for?

Another, related, question is how to make these schema types available in your frontend codebase - is that what you're asking about? If so, graphql-codegen is a good option. We should add an explicit recommendation in the docs, and an repo in examples/ that wires this up end-to-end using e.g. Next.js.

Thanks for asking this question @salieflewis!

[salieflewis]

My understanding is that the graph-cli generates the actual entities one may want for their subgraph automatically. Not just the actual file and example entities that come as a result of the Ponder codegen. So I was asking instead of writing those entities by scratch, have people looked towards using the graph-cli and then copying over the schemas that it creates for you.

And yes I agree, that that recommendation and example repo would be extremely helpful.

cc: @0xOlias

[typedarray]

Are you suggesting that Ponder should have an equivalent for the graph init and/or graph add commands? In other words, a helper/tool that "guesses" what the app's schema.graphql should look like based on the ABIs of the contracts that are added? Here's the relevant code from graph-cli.

If yes, I haven't given this much thought but agree that it's a problem. FWIW, I'm generally not a fan of CLI commands that modify version controlled files, so I'm wary of going down the same exact path as graph-cli. One idea would be a tiny web tool where you can paste an ABI and it spits out a recommended schema.graphql.

It's also worth noting that Ponder shines most in scenarios where it's actually not useful to autogenerate a schema.graphql because the application schema is not a 1:1 copy of the ABI event schema. See this tip in the docs for more perspective on this.

Finally, one low-hanging-fruit idea would be to add some one-size-fits all static documentation as comments on the top of the schema.graphql file that gets generated when you run npm create ponder. Could just be an abridged version of the "Design your schema" docs page.

Appreciate any feedback/ideas!

[salieflewis]

Thanks for the thoughtful response! That was what I was referring to yes, and I had a hunch that the answer to this question would revolve around the tip that you've pointed out in the docs.

The web tool is an interesting idea, but if you're suggesting that the process is application dependent then maybe it doesn't make sense to provide anything which allows these schemes to be created in an automatic fashion.

In addition to the static documentation living inside of the file, it could be helpful to just point to more instances of what these schema's look like in practice. I'll definitely try to outline my thought process as I refine the one I'm working on.

[typedarray]

Awesome, look forward to hearing your thought process. Added an issue for this. Great opp for a first contribution 👀