@spec concrete_types(t(), Absinthe.Type.t()) :: [Absinthe.Type.t()]

Get all concrete types for union, interface, or object

@spec directives(t()) :: [Absinthe.Type.Directive.t()]

List all directives on a schema

@spec implementors(t(), Absinthe.Type.identifier_t() | Absinthe.Type.Interface.t()) ::
  [
    Absinthe.Type.Object.t()
  ]

List all implementors of an interface on a schema

@spec introspect(schema :: t(), opts :: Absinthe.run_opts()) :: Absinthe.run_result()

Run the introspection query on a schema.

Convenience function.

@spec introspection_types(t()) :: [Absinthe.Type.t()]

Get all introspection types

Defines a root Mutation object

mutation do
  field :create_user, :user do
    arg :name, non_null(:string)
    arg :email, non_null(:string)

    resolve &MyApp.Web.BlogResolvers.create_user/2
  end
end

Defines a root Query object

@spec referenced_types(t()) :: [Absinthe.Type.t()]

Get all types that are referenced by an operation

Replace the default middleware.

Examples

Replace the default for all fields with a string lookup instead of an atom lookup:

def middleware(middleware, field, object) do
  new_middleware = {Absinthe.Middleware.MapGet, to_string(field.identifier)}
  middleware
  |> Absinthe.Schema.replace_default(new_middleware, field, object)
end

Defines a root Subscription object

Subscriptions in GraphQL let a client submit a document to the server that outlines what data they want to receive in the event of particular updates.

For a full walk through of how to setup your project with subscriptions and Phoenix see the Absinthe.Phoenix project moduledoc.

When you push a mutation, you can have selections on that mutation result to get back data you need, IE

mutation {
  createUser(accountId: 1, name: "bob") {
    id
    account { name }
  }
}

However, what if you want to know when OTHER people create a new user, so that your UI can update as well. This is the point of subscriptions.

subscription {
  newUsers {
    id
    account { name }
  }
}

The job of the subscription macros then is to give you the tools to connect subscription documents with the values that will drive them. In the last example we would get all users for all accounts, but you could imagine wanting just newUsers(accountId: 2).

In your schema you articulate the interests of a subscription via the config macro:

subscription do
  field :new_users, :user do
    arg :account_id, non_null(:id)

    config fn args, _info ->
      {:ok, topic: args.account_id}
    end
  end
end

The topic can be any term. You can broadcast a value manually to this subscription by doing

Absinthe.Subscription.publish(pubsub, user, [new_users: user.account_id])

It's pretty common to want to associate particular mutations as the triggers for one or more subscriptions, so Absinthe provides some macros to help with that too.

subscription do
  field :new_users, :user do
    arg :account_id, non_null(:id)

    config fn args, _info ->
      {:ok, topic: args.account_id}
    end

    trigger :create_user, topic: fn user ->
      user.account_id
    end
  end
end

The idea with a trigger is that it takes either a single mutation :create_user or a list of mutations [:create_user, :blah_user, ...] and a topic function. This function returns a value that is used to lookup documents on the basis of the topic they returned from the config macro.

Note that a subscription field can have trigger as many trigger blocks as you need, in the event that different groups of mutations return different results that require different topic functions.

Converts a schema to an SDL string

Per the spec, only types that are actually referenced directly or transitively from the root query, subscription, or mutation objects are included.

Example

Absinthe.Schema.to_sdl(MyAppWeb.Schema)
"schema {
  query {...}
}"

@spec types(t()) :: [Absinthe.Type.t()]

List all types on a schema

@spec used_types(t()) :: [Absinthe.Type.t()]

Get all types that are used by an operation