Category: 14. Gatsby Internals

As we saw earlier in this section, when a group of nodes is returned in response to a plural root field query, the type returned is Connection, which represents a common pattern in GraphQL. The term connection refers to an abstraction that operates over paginated resources. When you query a connection in GraphQL, Gatsby returns a subset of the…

Singular root fields also accept the filter parameter, but the filter is spread directly into arguments rather than as a distinct key. As such, filter parameters are passed to the singular root field directly and return the resulting object directly. If no parameters are passed, a random node of that type, if it exists, is returned. Because this…

Plural root fields accept four arguments: filter, sort, skip, and limit. The filter argument permits filtering based on node field values, and sort reorders the result. Meanwhile, the skip and limit arguments offset the result by the number of skip nodes and restrict it to the number of limit items. In GraphQL, plural root fields return a Connection type for the given type name (e.g., BlogArticleConnection for allBlogArticle). Here is an example of a plural root field…

In this section, we’ll discuss another key step in the Gatsby build lifecycle and the enablement of GraphQL queries: the creation of schema root fields. In Gatsby, schema root fields are considered the “entry point” of any GraphQL query, also sometimes known as a top-level field. For each Node type created during the process of schema generation, Gatsby generates…

In this section, we’ll examine the schema inference Gatsby undertakes to define child fields that have a relationship to their parent field. Consider the example of the File type, for which many transformer plugins exist that convert a file’s contents into a format legible to Gatsby’s data layer. When transformer plugins implement onCreateNode for each File node, this implementation produces File child nodes that carry their…

Fields that are directly created on the node, meaning fields that are provided through source and transformer plugins (e.g., relativePath, size, and accessTime in nodes of type File), are typically queried through the GraphQL API in a query similar to the following: These fields are created using the inferObjectStructureFromNodes function in src/schema/infer-graphql-type.js. Based on what kind of object the function is dealing with as it…

Each time a node is created, yielding a newly sourced or transformed node, Gatsby generates inference metadata that can be merged with other metadata such that it’s possible to define a schema for the new node that is as specific as possible to its structure. Thanks to inference metadata, Gatsby can also understand if there are any conflicts in…

After the nodes in your Gatsby site have been sourced from upstream data sources and transformed where necessary through plugins and their implementations of Gatsby APIs, it’s time for Gatsby to generate the schema underlying the GraphQL API driving data in your Gatsby implementation. Schema generation involves several steps. Gatsby’s GraphQL schema differs considerably from many…

Each time you run the gatsby build command, because Gatsby is fundamentally an SSG, there is always a nonzero chance that some node in the Redux nodes namespace will no longer be available because it’s been removed from the upstream data source. The Gatsby build lifecycle needs to be aware of this event in order to handle all nodes appropriately.…

Many nodes have a relationship to a parent node or child node that establishes a dependency between the two. Gatsby’s build process provides several approaches to create these relationships, which isn’t straightforward due to the fact that all nodes are considered top-level objects in the Redux nodes namespace. For this reason, each node’s children field consists of an array of…