Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add much more GraphQL schema validation #1046

Closed
13 tasks done
ra0x3 opened this issue Jun 30, 2023 · 0 comments · Fixed by #1318
Closed
13 tasks done

Add much more GraphQL schema validation #1046

ra0x3 opened this issue Jun 30, 2023 · 0 comments · Fixed by #1318
Assignees
Labels
documentation Improvements or additions to documentation P: Medium

Comments

@ra0x3
Copy link
Contributor

ra0x3 commented Jun 30, 2023

  • We have a GraphQLSchemaValidator in fuel_indexer_lib::graphql::validator
  • This object is responsible for making sure users aren't writing GraphQL schema that will throw the indexer in a weird state (whether at compile time or runtime)
  • We need to add a lot more rules to this validator, since currently, users can do some wacky stuff that puts the service into weird states

Some rules I can think of off the top of my head are:

  • No nested lists in schema
  • No nested foreign key references
  • All id field names must be of ID
  • Virtual types (tagged with a @virtual directive) can't have id: ID fields
  • Can't use reserved names
  • Can't have TypeDefinition with too long of name
  • Can't have FieldDefinition with too long of a name
  • Can't use unique directive @unique on a foreign key field
  • Can't use @unique directive on any TypeDefinition that is already @virtual
  • If using ::new() apparently can't include a u64 foreign key as the first arg?
  • Within the context of list types, that any Vec that could possibly be empty is typed as [Foo!] or [Foo] (where the outer list is optional)
  • Can't have a TypeDefinition with many-to-many relationships that exceed MAX_MANY_TO_MANY_RELATIONSHIPS = 10
  • Can't have a FieldDefinition that is a many-to-many relationship, where the FK is explicit (i.e., the FK points to anything other than an ID type on the child TypeDefintion)

(We can add to this list as we think of more things)

Additional context:

  • These rules should also be clearly document in the book
@ra0x3 ra0x3 added documentation Improvements or additions to documentation enhancement P: Medium labels Jun 30, 2023
@ra0x3 ra0x3 removed book labels Aug 8, 2023
@ra0x3 ra0x3 self-assigned this Aug 30, 2023
@ra0x3 ra0x3 linked a pull request Aug 31, 2023 that will close this issue
8 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation P: Medium
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant