The ability to represent empty objects

[MOZGIII]

Based on this: graphql/graphql-js#937 (comment)

Currently we can't represent an empty object type:

type Mutation {
  createUser(email: String!, password: String!): CreateUserPayload!
}

type UserWithEmailAlreadyExists
type WeakPassword
type AuthPayload {
  user: User!
  token: AccessToken!
}
union CreateUserPayload = UserWithEmailAlreadyExists | WeakPassword | AuthPayload

This fails with graphql-js with the following error:

Error: Type UserWithEmailAlreadyExists must define one or more fields.

Type WeakPassword must define one or more fields.
    at assertValidSchema (/Users/skainswo/dev/kumo/newer-world/api/node_modules/graphql/type/validate.js:71:11)
    at Object.validate (/Users/skainswo/dev/kumo/newer-world/api/node_modules/graphql/validation/validate.js:55:35)
    at doRunQuery (/Users/skainswo/dev/kumo/newer-world/api/node_modules/apollo-server-core/src/runQuery.ts:181:30)
    at /Users/skainswo/dev/kumo/newer-world/api/node_modules/apollo-server-core/src/runQuery.ts:80:39
    at process._tickCallback (internal/process/next_tick.js:68:7)

The usecase is legit though.

There is an explicit check to disallow types with zero fields at graphql-js:
https://github.com/graphql/graphql-js/blob/4116e2fc4fe36688f683258388f4a2d52076d199/src/type/validate.js#L273-L278

How about explicitly allowing empty fields in the spec? It's super useful for implementing algebraic types.

[stubailo]

I think one interesting aspect of this is that you would still be able to query __typename on it, so it wouldn't break the query language to have an empty type! Like

fragment Something on WeakPassword {
  __typename
}

Side note having empty types is also useful if you want to declare a type for the sole purpose of using extend type on it later.

[MOZGIII]

The problem is it doesn't allow you define a schema with an empty value.

Currently the workaround is to do the following:

type A {
  _: Boolean
}

[MOZGIII]

Type extension with extend type works already btw:

type Query

extend type Query {
  a: Boolean;
}

[stubailo]

Yes - I'm agreeing with you!

[alamothe]

What does it take to fix this issue?

I found that simply commenting out the check, everything just works.

(I'm using Apollo on the client and graphql-java on the server)

[IvanGoncharov]

What does it take to fix this issue?

It's a spec change so somebody should champion it and move through all of the stages:
https://github.com/graphql/graphql-spec/blob/master/CONTRIBUTING.md#rfc-contribution-champions

[victorandree]

For background, the requirement to have at least one field was introduced to the spec by 0599414. This change references graphql/graphql-js#368 where this was previously discussed (and then rejected).

The main argument for rejection in that issue seems to me to have been:

Since GraphQL always requires you to select fields down to scalar values, an Object type without any defined fields cannot be accessed in any way in a query. This could be even more problematic for Input Objects where a required input object argument with no fields could result in a field that is impossible to query without producing an error.

In my opinion:

• Because of __typename, you can always select fields down to scalar values" if we consider __typename a scalar field.

• With regards to input objects, I don't see why passing an empty object would not be allowed. The following seems to parse fine:

  mutation {
    update(input: {}) {
      name
    }
  }

Allowing empty object/input object types has concrete use cases:

• To support "well-known" introspection extensions types (see Expose user-defined meta-information via introspection API in form of directives #300 (comment))
• To support not having query as a root operation type (see Proposal: Do not require query as a root operation type #490)
• To support algebraic data types (as explained in this issue)

I'd be happy to submit a PR to simply remove this validation from the spec, as a strawman or proposal (edit: see #606).