A GraphQL API starts by building a schema. Using Absinthe, schemas are normal
modules that use
Here’s a schema that supports looking up an item by ID:
You may want to refer to the Absinthe API documentation for more detailed information as you look this over..
Some macros and functions used here that are worth mentioning, pulled in automatically from
query- Defines the root query object. It’s like using
objectbut with nice defaults. There is a matching
mutationmacro as well.
field- Defines a field in the enclosing
arg- Defines an argument in the enclosing
resolve- Sets the resolve function for the enclosing
You’ll notice we mention some types being referenced:
is a built-in scalar type (like
:boolean, and others), but
we need to define ourselves.
We can do it in the same
MyApp.Schema module, using the
object macro defined by
Now, you can use Absinthe to execute a query document. Keep in mind that for
HTTP, you’ll probably want to use
Absinthe.Plug instead of executing
GraphQL query documents yourself. Absinthe doesn’t know or care about HTTP,
absinthe_plug project does – and handles the vagaries of interacting
with HTTP GraphQL clients so you don’t have to.
If you were executing query documents yourself (lets assume for a local tool), it would go something like this:
We could also move our type definitions out into a different module, for instance,
MyApp.Schema.Types, and then use
import_types in our
It’s a nice way of separating the top-level
which define the surface area of the API, with the actual types that it uses.