Schema Organization

Learn how we organize the schema and import the types module in GraphQL.

We'll cover the following

Organising a schema

Absinthe schemas are compiled. This means that their types are collected, references are resolved, and the overall structure of the schema is verified against a set of rules. All this happens during Elixir’s module compilation process. Absinthe does this to ensure that GraphQL documents can be processed at runtime using a schema module that’s already been checked for common errors and optimized for better performance. That doesn’t mean our Absinthe schema needs to be written in a single module. In fact, when a schema grows beyond a limited sketch of our domain model into something more comprehensive, it becomes something we need to maintain. To make maintenance easier, it’s a good idea to organize it across multiple modules. To do this, we need something to wire them all together so Absinthe can find the portions of the schema we’ve extracted and organized elsewhere.

Thankfully, Absinthe provides two simple tools to help us: import_types and import_fields. Let’s look at how we can use these two handy macros in our schema definitions. We can use the PlateSlate example application that we’ve been working on.

Importing types

All the types referenced in an Absinthe schema are bundled and built into the compiled module during the module compilation process. Right now, in our PlateSlate application, all the types are located inside a single module, PlateSlateWeb.Schema. Unfortunately, it’s getting a bit long and unwieldy with each new feature we add.

Let’s consider splitting the custom types from the root type definitions. Since all the types we’ve built so far are menu-related, we’ll create a new module, PlateSlateWeb.Schema.MenuTypes, to hold them.

Here’s what that looks like:

Get hands-on with 1200+ tech skills courses.