I have a type that needs to be like the following
type ActivityPayload {
action: String!
extra: AnythingAtAll
}
Where AnythingAtAll is an arbitrary JSON format. So that's as far as I get because all the tutorials I see expect you to have a type AnythingAtAll with fields defined inside of it. How do I allow {}, or {any properties in json format no matter what the property names and values are}
Use graphql-scalars:
A library of custom GraphQL scalar types for creating precise type-safe GraphQL schemas.
This library offers also the scalar type JSON:
The JSON scalar type represents JSON values as specified by ECMA-404.
Then you can do the following:
type ActivityPayload {
action: String!
extra: JSON
}
See also graphql-type-json (JSON is based on this one).
Related
I am trying to set up a GraphQL endpoint in Spring Boot, and when I try to run my App, I get the following error:
Expected type 'Order' to be a GraphQLInputType, but it wasn't! Was a type only permitted for object types incorrectly used as an input type, or vice-versa?
Here is my models.graphqls:
type Order {
id: String!
storeOrderId: String
connectionId: String
}
type Mutation {
createOrder(order: Order): Order
}
This is happening because you're trying to use a type for an input, which isn't allowed.
type Order {
Should be...
input Order {
So that the whole thing looks like:
I am trying to set up a GraphQL endpoint in Spring Boot, and when I try to run my App, I get the following error:
Expected type 'Order' to be a GraphQLInputType, but it wasn't! Was a type only permitted for object types incorrectly used as an input type, or vice-versa?
Here is my models.graphqls:
input Order {
id: String!
storeOrderId: String
connectionId: String
}
type Mutation {
createOrder(order: Order): Order
}
if it still does't work after use a input type, There may be other problems here.
the input java types should have public getters,
the input java types should also implement Serializable interface
How can I add JSON type to lighthouse?
I've seen this package but I don't know how to use it and there's not any documentations available for it: https://github.com/mll-lab/graphql-php-scalars
Once you installed it, in your schema.graphql define every Scalar you want to use, like:
scalar JSON #scalar(class: "MLL\\GraphQLScalars\\JSON")
# Then just use it, like:
type User {
id: ID!
meta: JSON!
}
what's the difference between schema and documents in Graphql?
schema is like this:
type Query {
fo: String
}
but the document is like:
query SomeQuery {
foo {
bar
}
}
the spec is really confusing https://graphql.github.io/graphql-spec/June2018/#sec-Language.Document
I always use schema but for client-side type generation in graphql-code-generator it needs document file. https://graphql-code-generator.com/docs/getting-started/documents-field
A document is really any string containing valid GraphQL syntax. According to the spec, a document contains one or more definitions, where a definition could be:
an operation definition
query UsersQuery {
users {
id
email
}
}
a fragment definition
fragment UserFragment on User {
id
email
}
a type system definition
type User {
id: ID!
email: String!
}
a type system extension
extend type User {
name: String
}
Operation and fragment definitions are known as executable definitions. Documents sent to a GraphQL service must only contain executable definitions. Type system definitions and extensions are used in describing a schema -- that's why we commonly call them Schema Definition Language (SDL). A schema is a GraphQL service's "collective type system capabilities" -- it's basically a collection of types and directives that represent everything your GraphQL service can do.
A schema may be described using type system definitions, but it's not really accurate to say that the type definitions are the schema because the schema itself also includes the actual field resolution logic as well.
In the type definition below, is there a way to require name or model, instead of name and model?
type Starship {
id: ID!
name: String!
model: String!
length(unit: LengthUnit = METER): Float
}
I may have name or model due to some legacy data limitations. I would rather enforce this at the GraphQL validation layer, rather than in code.
EDIT:
There is some good discussion about adding validation to the graphQL spec, which you can read here: https://github.com/graphql/graphql-js/issues/361
There are also a couple of libraries to extend validation:
https://github.com/xpepermint/graphql-type-factory
https://github.com/stephenhandley/graphql-validated-types
I'm going to stick with validating the types in code, at least until they add better support.
You could try to use union to represent name or model concept . As union only works with object type now , that means you have also model name and model as object type first.
Code wise the schema looks like :
type Name {
value : String!
}
type Model {
value : String!
}
union NameOrModel = Name | Model
type Starship {
id: ID!
nameOrModel : NameOrModel!
length(unit: LengthUnit = METER): Float
}
It is very ugly IMO as it introduces many unnecessary noise and complexity to the schema .So I would prefer to stick with your original schema and do that check manually in the backend.
From the spec:
By default, all types in GraphQL are nullable; the null value is a valid response for all of the above types. To declare a type that disallows null, the GraphQL Non‐Null type can be used. This type wraps an underlying type, and this type acts identically to that wrapped type, with the exception that null is not a valid response for the wrapping type. A trailing exclamation mark is used to denote a field that uses a Non‐Null type like this: name: String!.
An individual field may be nullable or non-nullable. Non-null validation happens at the field level, independent of other fields. So there is no mechanism for validating whether some combination of fields are or are not null.
I have an input type in my schema that specifies lots of attributes, as it's intended to do. The issue is that what I'm sending to the mutation that will persist these objects is an object with arbitrary fields that may change. As it stands, if I send attributes not specified in the schema, I get the error:
Validation error of type WrongType: argument 'input' with value (...)
contains a field not in 'BotInput': 'ext_gps' # 'setBot'
Concretely, my input type did not specify the attribute exp_gps, and that field was provided.
My Question
Is there a way to make it so the input validation simply ignores any attributes not in the schema, so that it continues to perform the mutation with only whatever was specified in the schema? It'll be often that I don't want to persist the additional attributes, so dropping them is fine, as long as the other attributes get added.
GraphQL does not support arbitrary fields, there is a RFC to support a Map type but it has not been merged/approved into the specification.
I see two possible workarounds that both require to change your schema a little bit.
Say you have the following schema:
type Mutation {
saveBot(input: BotInput) : Boolean
}
input BotInput {
id: ID!
title: String
}
and the input object is:
{
"id": "123",
"title": "GoogleBot",
"unrelated": "field",
"ext_gps": "else"
}
Option 1: Pass the arbitrary fields as AWSJSON
You would change your schema to:
type Mutation {
saveBot(input: BotInput) : Boolean
}
input BotInput {
id: ID!
title: String
arbitraryFields: AWSJSON // this will contain all the arbitrary fields in a json string, provided your clients can pluck them from the original object, make a map out of them and json serialize it.
}
So the input in our example would be now:
{
"id": "123",
"title": "GoogleBot",
"arbitraryFields": "{\"unrelated\": \"field\", \"ext_gps\": \"else\"}"
}
In your resolver, you could take the arbitraryFields string, deserialize it, and hydrate the values on the BotInput object before passing it to the data source.
Option 2: Pass the input as AWSJSON
The principle is the same but you pass the entire BotInput as AWSJSON.
type Mutation {
saveBot(input: AWSJSON) : Boolean
}
You don't have to do the resolver hydration and you don't have to change your client, but you lose the GraphQL type validation as the whole BotInput is now a blob.