The pseudo-JSON structure of the GraphQL query becomes a valid JSON object in the GraphQL response. In other words, a typical GraphQL query issued by a client outlines the shape that the GraphQL response issued by the server should take. Notice how the GraphQL query and response are structurally identical: they share the same hierarchy and the same sequence of names. Gatsby’s internal GraphQL API will return the following response to this query: The primary means of interacting with a GraphQL API from the client is a query, which is a declarative expression of data requirements from the server.Ĭonsider the following example GraphQL query, which in Gatsby returns the title of the Gatsby site from its metadata: To get you up to speed, in the coming sections we’ll cover GraphQL queries, fields, arguments, query variables, directives, fragments, and finally schemas and types. Fortunately, because Gatsby uses GraphQL during development and build-time compilation, that latency only impacts the build duration rather than the end user’s time to first interaction. Using GraphQL does have some disadvantages, too-notably, GraphQL APIs can be difficult to scale due to the need to serve a response that is tightly tailored to the client’s query. Because GraphQL only requires a query, as opposed to a particular URL (and potentially headers and request bodies), it may provide a smoother developer experience. Offloading request complexity In many JavaScript implementations, correctly issuing a query often requires a complex interplay between promises, XMLHttpRequest implementations, and waiting for the requested data to arrive. GraphQL offers means to perform data transformations on the fly at query time through the use of explicitly defined arguments within a GraphQL API. Query-time data transformations In many JavaScript implementations, data postprocessing needs to occur to harmonize data formats or to perform a sort operation.
In traditional REST APIs, response payload sizes can be larger than necessary, or additional requests may be required to acquire the needed information. Common motivations for using it include: Avoiding response bloat GraphQL improves query performance by only serving that data that is necessary to populate the response according to the client-issued query.
GraphQL has become popular thanks to the flexibility it provides developers and the more favorable developer experience it facilitates through client-driven queries. Today, GraphQL APIs are commonplace for backend database access, headless CMS consumption, and other cross-system use cases, but it’s still quite rare to find GraphQL used internally within a framework. That is, unlike REST APIs, which adhere to the requirements dictated by the server, GraphQL APIs respond to client queries with a response that adheres to the shape of that query. GraphQL is a query language that provides client-tailored queries. In this chapter, we’ll explore the foundations of GraphQL that apply to any GraphQL API before switching gears to look at how Gatsby uses GraphQL specifically in its data layer and in page and component queries. With data potentially originating from a variety of disparate sources, Gatsby flattens the differences between discrete serialization formats (forms of articulating data) and thus third-party systems by populating a GraphQL API that is accessible from any Gatsby page or component. Though GraphQL is popular in web development as a query language, Gatsby uses it internally to provide a single unified approach to handling and managing data. Within Gatsby’s data layer, GraphQL mediates the relationship between Gatsby pages and components and the data that populates those pages and components. Before we turn our attention to how Gatsby integrates with external data, in this chapter we’ll cover the data layer in Gatsby, whether data comes from files in your Gatsby site (the local filesystem) or from external sources such as CMSs, commerce systems, or backend databases (external data sources that require a source plugin, discussed in more detail in Chapter 5). Up until now, all of our work on implementing Gatsby has focused on use cases that don’t require data retrieval and processing.
0 kommentar(er)
