Language record
GraphQL
A GraphQL document is read as a type system: object types, interfaces, unions, scalars, enums and input objects each get an identity, their fields are members, and every construct that names another type — a field's return and argument types, a variable's type, a union member, a fragment's condition — becomes a reference with the role it played.
The registry row this page is generated from
Read at render time from the same family row the register reads, so nothing in this block can disagree with it.
- Extensions
- .graphql, .gql, .graphqls
- Registry names
graphql- Recorded symbols
- types · fields · operations · fragments
Relationship types this analyzer constructs
8 of 14 constructed, read from this analyzer's source and re-derived by the languages gate. Each row below is one of the engine's types, in the engine's own order.
| Relationship type | Constructed |
|---|---|
calls | ruled absent |
extends | constructed by this analyzer |
implements | constructed by this analyzer |
uses | constructed by this analyzer |
imports | constructed by this analyzer |
exports | constructed by this analyzer |
contains | constructed by this analyzer |
references | constructed by this analyzer |
overrides | constructed by this analyzer |
instantiates | ruled absent |
decorates | ruled absent |
renders | ruled absent |
mixes_in | ruled absent |
part_of | ruled absent |
8 constructed, 6 not constructed. All 6 absent types are recorded as ruled absent: the written reason and the corpus measurement behind each are in this family's completeness record. The register explains what each label means.
What this analyzer does not resolve
- The relationship vocabulary is
contains,implementsanduses, and that is the format's shape rather than a shortfall: a GraphQL document declares types and names them.importsis empty by design —#importis a non-standard comment convention, not part of the specification — and a resolver lives in a JavaScript file bound to the schema by a naming convention the document never states, so the schema and its resolvers are two halves of the index. - A field's arguments are parameters of the field, not symbols.
invoice(id: ID!)gives you the argument's type; it does not give you something namedidyou can go and search for. Built-in scalars and introspection meta-fields are emitted as ordinary references, because they are specification vocabulary no declaration can own. extend type Xsplits a type across files, and which happens depends on this file: when it also declaresX, the extension contributes members only; when it does not, a symbol is published for it markedpartial. That is read from a pre-pass over the file's own top-level definitions rather than guessed, andextend scalar Spublishes no symbol at all because it declares nothing.
Every line above was written against GraphQL’s own analyzer module and is named against a construct in it, so it can be checked against the source. Nothing here is inherited from a template, or from another language’s page.
Where you meet it in a repository
Recognised by extension — .graphql, .gql, .graphqls. Everything below is about where those files actually sit in a working repository.
- A schema is usually a set of
.graphqlfiles mixing SDL and operations, or a directory of type files with a separate operations folder. Both index into one family and the two halves stay distinguishable, because a type declaration and an operation are different kinds. - A
.gqlfile sitting next to a component is the operation that component sends. The operation records its variables and its selections, and the component's ownfetchbelongs to a different file and a different edge. - Codegen output — the TypeScript types generated from a schema — is ordinary TypeScript to the index, so a schema and its generated types do not join into one graph.
Questions this index answers
Phrased as retrievals, because that is what an index can honestly do: it holds the symbols and the edges between them, and hands them back with the evidence attached.
- Which types does this schema declare, and which interfaces do they implement?
- Which fields does this type expose, and what types do they return?
- Which operations and fragments does this document define?
- Which directive does this field apply, and what does it declare?
What the analyzer sees in code like this
type Invoice implements Payable { // bb records: class Invoice, implements Payable
id: ID! // bb records: property id on Invoice
lines: [Line!]! // bb records: property lines; uses -> Line
}
type Query { // bb records: class Query
invoice(id: ID!): Invoice // id is a parameter of the field, not a symbol;
} // the edge to Invoice is the field's return typeSymbols are stored with the file they came from and the bytes they span, so a hit points at a line rather than at a guess. The annotations in the sample are commentary for the reader, not strings the index would store.
Languages that turn up in the same repository
Web, data & config — the count beside each name is how many relationship types that family’s analyzer constructs.
The extensions, registry names, recorded symbols and relationship types above are the parser registry row for GraphQL, read while the page rendered — the same row the register reads, so the two surfaces cannot tell two stories. Every relationship type listed as constructed appears in src/ast/real-*, the analyzer modules bb ships. bb 0.1.0 answers from a local store over 50 languages (53 registry ids, three of them aliases). There is no benchmark on this page: every claim here is one you can go and read in the source.