Auto-generate GraphQL schema using contract ABI

[ra0x3]

• When you create a new indexer project with forc index new your schema, lib module, and manifest are auto-generated
• As of today, a user has to open their GraphQL schema file to add even their basic schema
• It would be cool if the GraphQL schema could be initially populated automagically
  • After all, we know the types from looking at contract ABI

Additional context

• This would be something that a user opts into
  • Some type of flag --auto-graphql-types (or some such) passed to forc index new
    • This flag means the user wants to just copy the types exactly from the ABI, into their GraphQL equivalents
• This won't be possible (without some hacks) until we separate ABI structs and GraphQL structs into different namespaces
  • Currently, if you have a Foo struct in your Sway contract and a Foo in your GraphQL schema - the types will clash
  • Namespacing is cool, but also will require users to use types such as my_abi::Foo and my_graphql::Foo instead of just Foo (due to the naming collision).

[ra0x3]

cc @rvmelkonian @deekerno @lostman

This is definitely something we should think about. However, not really worth starting work on until we can discuss a way around the namespacing issue. Either some prefix or suffix or something on these type names. From what I've seen so far, users expect the Foo in their contract to be usable as a GraphQL type as well (not possible).

[0xmovses]

@ra0x3 prefixing with Entity seems pretty intuitive if we are happy to implement this.

[AlicanC]

I've taken a step towards this: FuelLabs/sway#4847

A roadmap for this issue could be:

• Reach consensus on how to refer to ABIs across teams. A contract has an "ABI", Forc generates a JSON representation of it called a "JSON ABI", and if we were to generate a schema for it then it would be called a "GraphQL ABI".
• Find out where to do this best. I think it makes sense for Forc to generate the GQL ABI too.
• Start with just generating types.
• Find out how to make these types available to an indexer project.
• ...

[ra0x3]

@AlicanC Thanks for looking into this

• So "JSON ABI" vs "ABI" - yes good point - this issue specifically relates to the JSON ABI generated by forc build
• I do think this is specifically an indexer issue -- meaning that this should have nothing to do with Sway or anything else
• So we already generate a default schema file within forc index new
• However, the contents of this schema file are more of a placeholder, and the user has to manually create the the new GraphQL type definitions to match what is is their Sway contract (if they're using a contract at all)
• How I envisioned this, is to merely accept the user's JSON ABI filepath when the user invokes forc index new or forc index init
  • So: forc index new shoutbox --namespace fuel --json-abi /path/to/abi.json
• With this --json-abi option the user can say "Generate my GraphQL schema using this JSON ABI file"
• From there, we would implement this by parsing the type definitions in the JSON ABI that we support, and using some meta-programming to convert these JSON ABI type definitions into GraphQL type definitions
  • This ☝🏽 is maybe 95% of this issue - converting from Sway JSON ABI type definitions to GraphQL type definitions

If you were to start implementing this:

• I think it might be good to set some parameters on what we can't support with this JSON ABI <> GraphQL conversion
  • For example, the indexer can't support Sway Vec types (probably all heap types), so there's one constraint
  • We also don't allow certain patterns in our GraphQL schema, so there's another constraint
    • See Add much more GraphQL schema validation #1046 for more info on this

I say all of this to say:

• This is something that would be really beneficial forc index new shout_box --namespace fuel --json-abi /path/to/abi.json, but I think it might be good to scope it down to something smaller/iterative/mergable

I hope some of this blabbing made sense

[ra0x3]

• Just commenting here for transparency that @AlicanC is working on both the derivation of TypeDefinitions (as the original issue doe/doesn't mention) and generating various metadata associated with the use/query'ing of those TypeDefinitions.
• This additional metadata can be used to help simplify the execution process involved in Integrate web server, GraphQL layer, and data layer #1145