These Key Features of GraphQL make it Unique among Other API Technologies

Hello, I’m Ganesh. I’m building LiveReview, a private AI code review tool that runs on your LLM key (OpenAI, Gemini, etc.) with highly competitive pricing — built for small teams. Do check it out and give it a try!

When building modern applications, especially for mobile devices, how you get data from the server to the client is everything. For years, REST has been the standard for API design, but it often comes with frustrations. Let's look at the problems that led to a new way of thinking and the birth of a powerful alternative: GraphQL.

Why was GraphQL introduced in the first place?

Before we dive into GraphQL, it's crucial to understand the challenges it was designed to solve. Traditional API architectures like REST often struggle with two pervasive and inefficient patterns:

• Over-fetching: This happens when an endpoint returns more data than the client application actually needs. Imagine needing just a user's name but receiving an object with 20 fields of user information. This wastes bandwidth and adds unnecessary processing overhead for the client.

• Under-fetching:
  This is the opposite problem, where a single endpoint doesn't provide all the required data, forcing the client to make multiple API calls. To get a blog post, its author, and its comments, an application might have to make three sequential requests. This "request waterfall" significantly increases load times, especially on slow mobile networks.

These inefficiencies were particularly painful in an increasingly mobile-centric world, setting the stage for a new solution.

The Birth of GraphQL

The story of GraphQL begins at Facebook around 2011-2012. The company was making a critical pivot from HTML5-based mobile apps to fully native experiences. They quickly realized their existing REST-like APIs were deeply inefficient for this new mobile environment. The multiple round-trips and bloated data payloads resulted in slow load times and a poor user experience on unreliable mobile networks.

In response, an internal team was tasked with creating a more efficient data-fetching API specifically for their native iOS application. This project evolved into GraphQL, and its first version was deployed in 2012 to power the News Feed in the redesigned Facebook for iOS app.

This origin story is key: GraphQL wasn't an academic exercise. It was forged as a practical solution to a pressing business problem, with the performance needs of the client application as its primary driver.

Mastering the Operations: Queries, Mutations, and Subscriptions

At its core, GraphQL allows clients to interact with the API through three distinct types of operations.

Queries: For Reading Data

A GraphQL Query is a read-only operation used to request data from the server. The client declaratively specifies the exact data fields it needs, and the server responds with a JSON object where the structure precisely mirrors the query. This solves over-fetching and under-fetching in a single request.

For example, to fetch a specific user's name and email, the query would look like this:

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

Mutations: For Writing Data

While queries are for reading data, Mutations are used for all write operations, such as creating, updating, or deleting data.

A critical feature is that mutations in a single request are guaranteed to execute serially, which prevents race conditions and makes side effects predictable.

Creating a New User

Here, the mutation creates a new user and asks for the id, name, and email of the newly created user to be returned in the response.

mutation {
  createUser(input: { name: "John Doe", email: "[e-mail]" }) {
    id
    name
    email
  }
}

Updating User Information

This mutation finds a user by their id and updates their information. The response will contain the updated data.

mutation {
  updateUser(id: 123, input: { name: "Jane Smith", email: "[e-mail]" }) {
    id
    name
    email
  }
}

Deleting a User

This mutation deletes a user and returns the data of the user that was just removed.

mutation {
  deleteUser(id: 123) {
    id
    name
    email
  }
}

Subscriptions: For Real-Time Data

Subscriptions are the third operation type, designed to handle real-time data updates. A client can subscribe to specific events on the server. When that event occurs, the server pushes the updated data to the client over a long-lived connection, typically using WebSockets.

For example, a client could subscribe to receive updates whenever a new comment is added to a specific blog post:

subscription {
  newComment(postId: "123") {
    id
    content
    author {
      name
    }
  }
}

After sending this subscription, the client will maintain a connection to the server and automatically receive the new comment's details every time a comment is added to post "123".

Continue Reading: Link

LiveReview helps you get great feedback on your PR/MR in a few minutes. Saves hours on every PR by giving fast, automated first-pass reviews. If you’re tired of waiting for your peer to review your code or are not confident that they’ll provide valid feedback, here’s LiveReview for you.