From the spec: The GraphQL Object type (ObjectTypeDefinition)… is inappropriate for re‐use [as an input], because Object types can contain fields that define arguments or contain references to interfaces and unions, neither of which is appropriate for use as an input argument. For this reason, input objects have a separate type in the system. That’s … Read more
It’s possible but generally not a good idea because: It breaks the spec. From section 6.3.1: Because the resolution of fields other than top‐level mutation fields must always be side effect‐free and idempotent, the execution order must not affect the result, and hence the server has the freedom to execute the field entries in whatever … Read more
From the spec: Fields may accept arguments to configure their behavior. These inputs are often scalars or enums, but they sometimes need to represent more complex values. A GraphQL Input Object defines a set of input fields; the input fields are either scalars, enums, or other input objects. This allows arguments to accept arbitrarily complex … Read more
In GraphQL, an input cannot be used as a type and a type cannot be used as an input. Unfortunately, even if the fields appear identical to an existing type, you always have to define a separate input to use as an argument. Try something like this: const NotebookDetailsInput = new GraphQLInputObjectType({ name: ‘NotebookDetailsInput’, fields: … Read more
In the context of that example, login should be a Query instead of a Mutation assuming its resolver has no side-effects, at least according to the spec. However, there’s a couple of reasons you probably won’t see that done in the wild: If you’re implementing authentication, you’ll probably want to log your users’ account activity, … Read more
From the docs: If a mutation updates a single existing entity, Apollo Client can automatically update that entity’s value in its cache when the mutation returns. To do so, the mutation must return the id of the modified entity, along with the values of the fields that were modified. Conveniently, mutations do this by default … Read more
From the docs: A GraphQL object type has a name and fields, but at some point those fields have to resolve to some concrete data. That’s where the scalar types come in: they represent the leaves of the query. GraphQL requires that you construct your queries in a way that only returns concrete data. Each … Read more
GraphQL relies on both the server and the client knowing ahead of time what fields are available available for each type. In some cases, the client can discover those fields (via introspection), but for the server, they always need to be known ahead of time. So to somehow dynamically generate those fields based on the … Read more
I’ve come up with a middle-ground solution. Rather than trying to push this complexity onto GraphQL, I’m opting to just use the String type and JSON.stringifying my data before setting it on the field. So everything gets stringified, and later in my application when I need to consume this field, I JSON.parse the result to … Read more
Apollo exposes two kinds of errors through its API: GraphQL errors, which are returned as part of the response as errors, alongside data, and network errors which occur when a request fails. A network error will occur when a server can’t be reached or if the response status is anything other than 200 — queries … Read more