GraphQL Query Execution: How It Powers Modern?APIs

In the ever-evolving landscape of web development, GraphQL has emerged as a transformative technology, revolutionizing the way we interact with APIs. At its core, GraphQL is a query language that puts the power firmly in the hands of the client, enabling efficient and precise data retrieval.

?This article embarks on a journey through GraphQL’s query execution process, unraveling its inner workings and highlighting the fundamental distinctions that set it apart from traditional RESTful APIs. Join us as we explore how GraphQL’s query execution powers modern APIs and reshapes the developer landscape.

GraphQL operates on a fundamentally different principle compared to traditional REST APIs when it comes to handling client queries. When you submit a query to a GraphQL API, the following steps illustrate how it works:

Query Submission

When you send a GraphQL query, you make a single HTTP POST request to the GraphQL server’s endpoint, typically /graphql. The request body contains the query you want to execute. Here’s an example of a GraphQL query:

query {
 user(id: 1) {
 name
 email
 }
 }        

Schema Validation

The GraphQL server has a defined schema that specifies the available types, queries, mutations, and their structure. It serves as the contract between the client and server. Before processing the query, the server validates it against the schema to ensure it conforms to the expected structure.

Query Parsing

?The server parses the incoming query to understand its structure. Parsing contains the following steps.

1- Lexical Analysis (Tokenization): The first step in parsing is lexical analysis, also known as tokenization. The query string is broken down into a stream of tokens, which are the smallest units of the query.

[QUERY, LEFT_BRACE, NAME(user), LEFT_PAREN, NAME(id), COLON, INT(1), RIGHT_PAREN, LEFT_BRACE, NAME(name), NAME(email), RIGHT_BRACE, RIGHT_BRACE]        

2- Syntax Parsing: The token stream is then parsed to construct an abstract syntax tree (AST). This tree represents the hierarchical structure of the query and is used to validate the query’s syntax.

 {
  operation: "query",
  selectionSet: {
    selections: [
      {
        field: "user",
        arguments: [{ name: "id", value: 123 }],
        selectionSet: {
          selections: [
            { field: "name" },
            { field: "email" }
          ]}}]}}        

Execution Planning

GraphQL generates an execution plan by traversing the AST and resolving each field based on the parsed query.

A query plan serves as a strategic framework for decomposing an initial operation(query receive from user) into several sub-operations, each of which can be independently resolved within its own subgraph.

Field Resolution

GraphQL resolves each field in the query by invoking a corresponding resolver function. When a field is executed, the corresponding resolver is called to produce the next value. If a field produce a scalar value (number or string) then the execution completes. However if a field produce object then query continue until scalar values are reached.

Data Fetching

Resolvers may need to fetch data from one or more data sources. GraphQL allows parallel execution of resolvers, which means that data retrieval can be optimized for efficiency. This is in contrast to REST, where you often have to make multiple sequential requests to different endpoints to gather related data.

Data Stitching and response generation

As data is retrieved, GraphQL stitches the results together into a single JSON response object. The response structure matches the structure of the query?. The GraphQL server sends the response back to the client in JSON format

Conclusion

GraphQL works by allowing clients to request specific data they need, and the server responds with precisely that data. The server resolves the query by executing resolver functions that fetch the necessary data from various sources. This client-centric approach offers greater flexibility and efficiency compared to traditional REST APIs, where endpoints dictate the shape of the data and often result in over-fetching or under-fetching.