GraphQL document is parsed:
- Lexer: https://github.com/absinthe-graphql/absinthe/blob/master/lib/absinthe/lexer.ex
- Parser (Yecc): https://github.com/absinthe-graphql/absinthe/blob/master/src/absinthe_parser.yrl
This returns a tree of Absinthe.Language nodes (structs), effectively the AST:
This tree is converted to a tree of Absinthe.Blueprint nodes (structs):
(At the moment the Language and Blueprint trees are separate; in the future we may decide to combine them, but the separation makes certain things easier to reason about).
The Blueprint tree is processed through a "pipeline" of phases (in fact, the parsing/creation of the trees(s) were the first steps in the pipeline):
Our phases are much more discrete than classic GraphQL Parsing, Validation, Execution phases; there are about ~40 phases for processing documents; each phase takes an input and returns an output for the next phase. Post-parsing this means the Blueprint tree is passed in, and an annotated/modified Blueprint tree is returned from each phase.
In our current master/unstable release, schema compilation is handled via a Blueprint tree as well; rather than harvesting results from the tree as with GraphQL documents, intermediate Blueprint trees modeling the schema definition are created using either Elixir macros or SDL input, then passed through to a phase that emits an optimized module (our schemas) for compilation (by Elixir/BEAM).
Inserting phases into the currently executing pipeline, jumping to the end, etc, are how we handle validation and execution errors, re-running for batch execution, etc.