GraphQL is a powerful query language for APIs and a runtime for resolving queries with data. We talk history, features, and how to work with the language
Join the DZone community and get the full member experience. This article was originally published at Coder Society, and we’ll explore GraphQL’s core features, how to interact with a GraphQL API, and some development and operational challenges. Nowadays, REST seems to be the default approach for building APIs, typically based on the familiar HTTP protocol. While REST is relatively simple to work with and enjoys widespread popularity, its use of multiple endpoints to address resources sometimes gets in the way of flexibility. With such a rigid approach, some clients will get more data than they actually need (over-fetching), whereas others will not get enough from a single endpoint (under-fetching). This is a common issue among endpoint-based APIs like REST, and API clients have to compensate for it, for example, by issuing multiple requests and having to do the work of bringing data into the right shape on the client-side. With GraphQL, however, clients can request exactly the data they need, no more and no less, similar to querying specific fields in a database. GraphQL was developed at Facebook in 2012 when the company was reworking its mobile apps and needed a data-fetching technology that was friendly even to low-resource devices. It was open-sourced in 2015 and moved to the GraphQL Foundation in 2018. GraphQL shares some similarities with REST. It allows clients to request and manage data from APIs via a request-response protocol, typically run on top of HTTP. However, the way that data is organized, requested, and served is very different. GraphQL provides the following operations to work with data via a single endpoint: Therefore, at the surface, GraphQL can cover your typical API requirements. Do not be misled by the QL into thinking that it’s used just for data retrieval. A GraphQL API is based on a type system or schema which describes the capabilities and data structures of the API. The schema is defined using the GraphQL Schema Definition Language (SDL) and includes all the different types, their fields, and how they are related. Using a feature called introspection, clients can query the schema itself. This functionality is particularly useful for tooling, such as code generation and autogeneration of API documentation. For example, projects such as GraphiQL and GraphQL Playground leverage this functionality to provide rich documentation and integrated querying experiences. What makes GraphQL so powerful is that clients can request exactly the data they need, not more and not less. It’s also possible to request related data in the same query without the need for additional API calls. We’ll see some examples in the next section. A GraphQL server evaluates each incoming API request and resolves the values for each requested field using resolver functions. The resolver functions are doing the real work by, for example, fetching data from databases or other systems. This makes GraphQL an ideal solution for heterogeneous environments where data is located in different sources. To understand a little better what it’s like to interact with a GraphQL API, let’s look at a few simple examples. We’re going to use an updated Star Wars example server, which provides a fully functional GraphQL API with some example data, as well as GraphQL Playground. Simply follow these instructions to get it up and running: Clone the example repository: $ git clone https://github.
