graphql-spec icon indicating copy to clipboard operation
graphql-spec copied to clipboard

Formalize Global Object Identification.

Open nrbnlulu opened this issue 2 years ago • 0 comments

Preface

The Global Object Identification introduces a "best practice" for a GraphQL server implementation.

The problem is that it is not very strict and it makes hard to write codegen-clients that assume the server comply with these specifications.

Examples

The following are the major spec-lacks I encountered while trying to build a client code-gen.

  • It is not clear what field stability says about lists / union / interface

If a field is queried on both objects, the result of querying that field on the first object must be equal to the result of querying that field on the second object.

  • If the field returns a scalar, equality is defined as is appropriate for that scalar.
  • If the field returns an enum, equality is defined as both fields returning the same enum value.
  • If the field returns an object, equality is defined recursively as per the above.
  • It is not clear whether field stability should consider field arguments as well. Although it is kind of implied by the Plural identifying root fields (even though they does not implement Node) section it is not a strict requirement.

NOTE Spec-compliant servers may expose root fields that are not plural identifying root fields; the spec-compliant client will just be unable to use those fields as root fields in its queries.

This basically means I have nothing to do with it (automatic wise...) Note that AFAIK relay-graphql caches fields by arguments.

Suggestion

Create a more strict version of Global Object Identification spec so that client libraries won't need to have their own servers requirements or wrong assumptions.

nrbnlulu avatar Jun 21 '23 07:06 nrbnlulu