You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.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.
The text was updated successfully, but these errors were encountered: