BACKEND

Home › Glossary › Backend· 192 ·

GraphQL

\\graf-kyoo-el\\n.

Filed underBackendApisSoftware Engineering

In brief · quick answer

GraphQL is a query language and runtime for APIs, developed by Meta (Facebook), that lets clients request exactly the data they need in a single request. It provides a strongly typed schema and real-time subscriptions.

§ 1 Definition

GraphQL was developed by Meta (Facebook) in 2012 and open-sourced in 2015. It is a query language for APIs and a runtime for fulfilling those queries with existing data. Unlike REST, where the server defines response shapes, GraphQL gives clients the power to specify exactly what data they need in each request. This eliminates over-fetching (getting more data than needed) and under-fetching (needing multiple requests to get all required data). GraphQL APIs are defined by a single strongly typed schema using the GraphQL Schema Definition Language (SDL). The schema serves as a contract between client and server. Clients query against this schema through a single endpoint (typically /graphql). GraphQL supports three operation types: queries (data reading), mutations (data writing), and subscriptions (real-time events).

§ 2 Schema and Type System

The GraphQL schema is the heart of any GraphQL API. It defines the types available, their fields, and the relationships between them. Every field in a GraphQL schema is strongly typed. The schema uses the Schema Definition Language (SDL) to define types, enums, interfaces, unions, and input types. The schema also defines queries (entry points for reading data), mutations (entry points for modifying data), and subscriptions (real-time event streams). Because the schema is a single source of truth, tools like GraphiQL and Apollo Studio can auto-generate documentation, enable autocomplete in queries, and validate operations at build time.

§ 3 Resolvers and Data Fetching

A GraphQL server executes queries by calling resolver functions. Each field in the schema maps to a resolver. Resolvers can return data from a database, call a REST API, read a file, or combine multiple data sources. The GraphQL runtime calls resolvers in a tree, resolving dependent fields first. Performance pitfalls include the N+1 problem (where a resolver makes a database query per parent record) and deeply nested queries. Solutions include DataLoader for batching/caching requests, query complexity analysis to reject expensive queries, and pagination through connections (Relay spec).

§ 4 GraphQL vs REST

GraphQL and REST are different approaches, not competitors. REST is resource-oriented with well-defined URL endpoints. GraphQL is client-driven with a single endpoint. GraphQL excels when clients need different data shapes (mobile vs desktop vs third-party), when data relationships are complex and nested, and when reducing network requests matters most. REST excels when caching is paramount (HTTP caching is built-in), when the API is simple CRUD, and when you want the simplicity of URL-based resource access. Many teams use both: REST for public APIs and GraphQL for internal client applications. The choice depends on your specific requirements.

§ 5 Note

Common misunderstanding: GraphQL replaces REST. It does not. GraphQL is an alternative to REST for specific use cases. Many production systems use both. Another misconception: GraphQL is inherently slower than REST because it always uses POST requests and single endpoints. With proper DataLoader batching, query complexity limits, and persisted queries, GraphQL can be as fast or faster than REST for complex data needs. However, for a simple resource fetch (get user by ID), a cached GET request in REST is always faster than a POST query to GraphQL.

§ 6 In code

```graphql
# Schema definition
enum Status {
  ACTIVE
  INACTIVE
}

type User {
  id: ID!
  name: String!
  email: String!
  status: Status!
  posts: [Post!]!
}

type Post {
  id: ID!
  title: String!
  author: User!
}

type Query {
  user(id: ID!): User
  posts(limit: Int): [Post!]!
}

# Client query
query GetUserWithPosts($userId: ID!) {
  user(id: $userId) {
    name
    email
    posts {
      title
    }
  }
}

# Response
{
  "data": {
    "user": {
      "name": "Alice",
      "email": "[email protected]",
      "posts": [
        { "title": "Hello World" }
      ]
    }
  }
}
```

§ 7 Common questions

Q. Should I use GraphQL or REST for my API?: A. Use REST for simple CRUD, public APIs, and when HTTP caching matters. Use GraphQL when clients need different data shapes, complex nested data, or when minimizing network requests is critical.
Q. Does GraphQL work with any database?: A. Yes. GraphQL is database-agnostic. Resolvers can fetch data from SQL databases, NoSQL databases, REST APIs, microservices, or files. The client never knows or cares about the data source.
Q. Is GraphQL still maintained by Meta?: A. Yes. GraphQL is maintained by the GraphQL Foundation (under the Linux Foundation) with contributions from Meta, Apollo, The Guild, and many other organizations.

Key takeaways

GraphQL lets clients request exactly the data they need in a single request.
Strongly typed schema serves as a contract between client and server.
Resolvers map schema fields to data sources, with DataLoader solving the N+1 problem.
GraphQL and REST are complementary, not competitive. Choose based on use case.

How Atomic Glue helps

Atomic Glue builds GraphQL APIs for projects that benefit from flexible data fetching. We use GraphQL when clients need different data shapes for different devices, when data relationships are deeply nested, or when real-time subscriptions enhance the user experience. Our team has experience with Apollo Server, Yoga, and Hasura. We also maintain REST endpoints alongside GraphQL when the architecture calls for both. GraphQL is part of our API development toolkit within our Web Development services. Get in touch to discuss your API architecture.

Get in touch

# GraphQL

Category: Backend (also: Apis, Software Engineering)

Author: Atomic Glue Development Team

## Definition

## Schema and Type System

## Resolvers and Data Fetching

## GraphQL vs REST

## Note

## In code

## Common questions
Q: Should I use GraphQL or REST for my API?
A: Use REST for simple CRUD, public APIs, and when HTTP caching matters. Use GraphQL when clients need different data shapes, complex nested data, or when minimizing network requests is critical.
Q: Does GraphQL work with any database?
A: Yes. GraphQL is database-agnostic. Resolvers can fetch data from SQL databases, NoSQL databases, REST APIs, microservices, or files. The client never knows or cares about the data source.
Q: Is GraphQL still maintained by Meta?
A: Yes. GraphQL is maintained by the GraphQL Foundation (under the Linux Foundation) with contributions from Meta, Apollo, The Guild, and many other organizations.

## Key takeaways

GraphQL lets clients request exactly the data they need in a single request.
Strongly typed schema serves as a contract between client and server.
Resolvers map schema fields to data sources, with DataLoader solving the N+1 problem.
GraphQL and REST are complementary, not competitive. Choose based on use case.

## Related entries

Last updated June 2026. Permalink: atomicglue.co/glossary/graphql