Dissecting GraphQL Queries
In the last post titled Putting REST to rest. Here’s why you should be using GraphQL! we talked about how GraphQL had an edge over REST and how we could leverage the power of GraphQL to create high performant and blazing fast web services.
Today we shall go through GraphQL under the hood i.e. how a schema is defined and the queries and mutations that fetch and send data to the server are designed.
As we talked about in the previous post a schema is used to describe the shape of data graph. This schema defines a hierarchy of types with fields that are populated from back-end data stores. The schema also specifies exactly which queries and mutations are available for clients to execute against data graph.
A graphQL query looks pretty much like json , wherein we either have a field assigned to a scalar data type or an object type.
So to perform a graphQL query we first define a schema to which the query will adhere to, and then we write the queries or mutations to fetch the data based on the schema that we defined.
So there are basically three types of operations that are performed in GraphQL, Query is used to fetch data from one or multiple data sources, Mutation’s write data onto data sources and subscriptions listen for an event and then perform various actions based on the type of event they have been listening to.
Queries are used by the client to request the data it needs from the server. Unlike REST APIs where there’s a clearly defined structure of information returned from each endpoint, GraphQL always exposes only one endpoint, allowing the client to decide what data it really needs from a predefined pattern.
In GraphQL, mutations are used to CUD:
- Create new data
- Update existing data
- Delete existing data
The syntax for mutations look almost the same as queries, but they must start with the mutation keyword.
Subscriptions are a way to create and maintain real time connection to the server. This enables the client to get immediate information about related events. Basically, a client subscribes to an event in the server, and whenever that event is called, the server will send the corresponding data to the client.
Individual fields in a schema are resolved using Resolver functions which are responsible for populating the data for a single field in your schema. They can populate that data in any way you define, such as by fetching data from a back-end database or a third-party API.
So as you can see in the above mentioned code snippet, the resolver resolves the data against individual fields by firing functions which in turn fetch the said data from a third party API or Database.
Conclusion
In this article we introduced the concept of queries, mutations and subscriptions. We will look at how to create a robust application using what we learned today in the forthcoming posts.
