Absinthe Versions Save

• Stricter, spec-compliant scalar parsing rules (#194)
• Bug fix: Fixes to complex resolution using abstract types (#197) (#199)
• Bug fix: Fix escaped characters in input literals (#165) (#202)
• Bug fix: Fix regression where nested list input types did not work (#205)

Overview

Absinthe now generates a richer "intermediate representation" of query documents (see Absinthe.Blueprint) from the document AST. This representation then serves as the data backbone for processing during later phases.

Rather than the integrated validation-during-execution approach used in previous versions-- and rather than using a few "fat" phases (eg, "Parsing", "Validation", "Execution") as in other implementations -- Absinthe treats all operations (parsing, each individual validation, field resolution, and result construction) as a pipeline (see Absinthe.Pipeline) of discrete and equal phases. This allows developers to insert, remove, switch-out, and otherwise customize the changes that occur to the intermediate representation, and how that intermediate representation turns into a result. Future releases will further this model and continue to make it easier to modify Absinthe's processing to support the unique needs of developers.

Breaking Changes

Deprecations and Errors

Absinthe no longer automatically adds deprecations to result errors. (Although this is possible with the addition of custom phases.)

More Strict Input Value Parsing

Absinthe now more closely adheres to the GraphQL specification's rules about input value coercion, to include:

• Int: Disallowing automatic coercion of, eg, "1" to 1
• String: Disallowing automatic coercion of, eg, 1 to "1"
• Enum: Disallowing quoted values, eg, "RED" vs RED

Furthermore scalar type parse functions now receive their value as Absinthe.Blueprint.Input.t structs. If you have defined your own custom scalar types, you may need to modify them; see lib/absinthe/type/built_ins/scalars.ex for examples.

Validation Errors Prevent Resolution

In accordance with the GraphQL Specification, if any errors are added during document validation, no resolution will occur. In the past, because validation was done on-the-fly during resolution, partial resolution, just returning null for fields (in a way that would be invalid, according to the spec) was possible.

(Notably, this release includes a very large number of new document validations.)

No AST Nodes in Resolution

The raw AST nodes are no longer provided as part of the "info" argument passed to resolve functions. If you have built logic (eg, Ecto preloading) based on the AST information, look at the definition instead, which is a Blueprint Field struct containing a fields array of subfields. These fields have passed validation and have been flattened from any fragments that may have been used in the original document (you just may want to pay attention to each field's type_conditions).

List Coercion

Fields and arguments with list types are now automatically coerced if given a single item. For example if you have arg :ids, list_of(:id) Absinthe will coerce a document like foo(ids: 1) into foo(ids: [1]).

This is also true for resolution functions. If your field has a return type of list_of(:user) and your resolution function returns {:ok, %User{}}, the value is wrapped. It is as though you returned {:ok, [%User{}]}.

Simpler Adapters

Adapters now only use to_internal_name/2 and to_external_name/2 as the Absinthe.Blueprint intermediate representation and schema application phase removes the need for whole document conversion. If you have defined your own adapter, you may need to modify it.

Mix Task Removal

The IDL generating mix task (absinthe.schema.graphql) has been temporarily removed (due to the extent of work needed to modify it for this release), but it will reappear in a future release along with integrated schema compilation from GraphQL IDL.

Other Changes

Resolution Functions

Support for 3-arity resolution functions. Resolution functions accepting 3 arguments will have the current "source" (or parent) object passed as the first argument. 2-arity resolution functions will continue to be supported.

The following resolutions functions are equivalent:

fn source, args, info -> {:ok, source.foo} end
fn args, %{source: source} -> {:ok, source.foo} end

Resolution Plugins (+ Async & Batching)

v1.2 features a Resolution Plugin mechanism. See the docs in the Absinthe.Resolution.Plugin module for more information.

Resolution Info

In previous versions, the last argument to resolution functions was an Absinthe.Execution.Field struct. It is now an Absinthe.Resolution struct. While the struct has most of the same information available, the AST nodes is no longer provided. See "Breaking Changes" above.

Custom Type Metadata

To further support extensibility, types and fields can be annotated using the Absinthe.Schema.Notation.meta/2 macro, and metadata extracted using Absinthe.Type.meta/1 and Absinthe.Type.meta/1. This metadata facility has been added for objects, input objects, enums, scalars, unions, interfaces, and fields.