Use required on input, nullable on output to determine GraphQL nullability#3
Draft
steverice wants to merge 2 commits into
Draft
Use required on input, nullable on output to determine GraphQL nullability#3steverice wants to merge 2 commits into
required on input, nullable on output to determine GraphQL nullability#3steverice wants to merge 2 commits into
Conversation
…llability In GraphQL, fields are either wrapped in a `GraphQLNonNull` (type ends with `!`) or not. In input types, a field with `GraphQLNonNull` type [must be present and must not be `null`](https://spec.graphql.org/October2021/#sec-Non-Null.Input-Coercion) In output types, a field with `GraphQLNonNull` type [cannot return a `null` value](https://spec.graphql.org/October2021/#sec-Value-Completion) The OpenAPI spec is [not clear on the meaning of "required"](https://swagger.io/docs/specification/data-models/data-types/#required) but the JSON schema specification that OpenAPI 3.0 uses [is clearer](https://json-schema.org/specification-links#draft-5) > An object instance is valid against this keyword if its property set contains all elements in this keyword's array value. Essentially, we can interpret "required" as "must be present in the object." The OpenAPI spec also [provides a "nullable" property](https://swagger.io/docs/specification/data-models/data-types/#null) > [nullable: true will] specify that the value may be null Essentially, we can interpret "nullable" as "may be `null` (if present)." In OpenAPI, the same component schema can be used as both input and output types. So we must interpret "required" and "nullable" differently. For input types, we must interpret "required" as `GraphQLNonNull` and ignore "nullable" (since `GraphQLNonNull` implies non-nullable). For output types, we must interpret "nullable" as `GraphQLNonNull` and ignore "required" (since presence in output is determined by the query).
`Connection` can vary depending on the test-environment; `content-length` should be more consistent.
steverice
changed the title
required on input, nullable on output to determine GraphQL nu…required on input, nullable on output to determine GraphQL nullability
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In GraphQL, fields are either wrapped in a
GraphQLNonNull(type ends with!) or not. In input types, a field withGraphQLNonNulltype must be present and must not benullIn output types, a field withGraphQLNonNulltype cannot return anullvalueThe OpenAPI spec is not clear on the meaning of "required" but the JSON schema specification that OpenAPI 3.0 uses is clearer
The OpenAPI spec also provides a "nullable" property
In OpenAPI, the same component schema can be used as both input and output types. So we must interpret "required" and "nullable" differently. For input types, we must interpret "required" as
GraphQLNonNulland ignore "nullable" (sinceGraphQLNonNullimplies non-nullable). For output types, we must interpret "nullable" asGraphQLNonNulland ignore "required" (since presence in output is determined by the query).