Absinthe: Non-null by default

Created on 27 Nov 2019  路  4Comments  路  Source: absinthe-graphql/absinthe

I find myself having non_null calls all over my schemas. Can this be the default? For example, these snippets could be equivalent:

Proposed new API
defmodule GraphqlSchema.Types.Alert do
  use Absinthe.Schema.Notation,
    non_null: true

  object :alert_mutations do
    field :delete_alerts, type: :deletion_result do
      arg :ids, list_of(:integer)

      resolve &GraphqlSchema.Resolvers.Alert.delete_alerts/3
    end
  end

  object :alert do
    field :description, nullable(:string)
  end
end
Equivalent current API
defmodule GraphqlSchema.Types.Alert do
  use Absinthe.Schema.Notation

  object :alert_mutations do
    field :delete_alerts, type: non_null(:deletion_result) do
      arg :ids, non_null(list_of(non_null(:integer)))

      resolve &GraphqlSchema.Resolvers.Alert.delete_alerts/3
    end
  end

  object :alert do
    field :description, :string
  end
end

Most helpful comment

Sorry, I didn't even notice the configuration option on use Absinthe.Schema.Notation

A few tiny macros could accomplish this with the existing syntax, so I'm not sure we'd want alter Absinthe itself to have multiple "modes" that a schema can be running under, especially since people can break up their schema definitions into many modules - that could lead to complexity if an included module is in a different "mode"... All of the schema stuff is done at compile time using module attribute accumulators, so it's fairly complex on the inside already.

Also with 1.5 you can define schemas using GraphQL SDL notation, so it'd look like this:

type Mutation {
  deleteAlerts(ids: [Int!]!): DeletionResult!
}

All 4 comments

I suggest you create a macro to make non null fields easier in your projects.

E.g. to stick with graphql SDL syntax

arg :ids, list_of!(:integer)

Macros look like a great solution here, this would be far to significant of a breaking change...

I did not propose a breaking change, but fine.

Sorry, I didn't even notice the configuration option on use Absinthe.Schema.Notation

A few tiny macros could accomplish this with the existing syntax, so I'm not sure we'd want alter Absinthe itself to have multiple "modes" that a schema can be running under, especially since people can break up their schema definitions into many modules - that could lead to complexity if an included module is in a different "mode"... All of the schema stuff is done at compile time using module attribute accumulators, so it's fairly complex on the inside already.

Also with 1.5 you can define schemas using GraphQL SDL notation, so it'd look like this:

type Mutation {
  deleteAlerts(ids: [Int!]!): DeletionResult!
}
Was this page helpful?
0 / 5 - 0 ratings