The Node interface and automatic type inference

In Gatsby’s GraphQL schema, these three data types (MarkdownRemark, AuthorJson, and TranslatorJson) are each represented using the Node interface, which defines the GraphQL fields mutually shared by Node objects that are generated by source and transformer plugins (namely id, parent, children, and several internal fields such as type). Written in GraphQL’s Schema Definition Language (SDL), the Node interface is defined as follows:

interface Node {
  id: ID!
  parent: Node!
  children: [Node!]!
  internal: Internal!
}

type Internal {
  type: String!
}

The types that are created by source and transformer plugins, like gatsby-source-filesystem, gatsby-transformer-remark, and gatsby-transformer-json, are implementations of this Node interface. For instance, the Node type TranslatorJson will be defined in the GraphQL schema as follows:

type TranslatorJson implements Node {
  id: ID!
  parent: Node!
  children: [Node!]!
  internal: Internal!
  name: String
  firstName: String
  email: String
  multipleLanguages: Boolean
}

NOTE

Fields whose value types end with an exclamation point represent nullability, indicating whether a field value can be null or not; they must have a non-null value.

Gatsby performs inference to determine the field types (i.e., String, Boolean, etc.)—it inspects the contents of every field and validates its type to translate each data shape into meaningful type definitions. Gatsby is usually quite adept at this process of automatic type inference, though it consumes significant resources in doing so and has trouble deciding between types if multiple types (e.g., String and Date) are represented in a particular field. One potential consequence of this approach is that if data sources change the way they expose data, automatic type inference suddenly fails.