Data Fetching with GraphQL: A Modern Approach to APIs

Struggling with slow, bloated APIs? Discover GraphQL, a game-changing query language for APIs that lets you request exactly the data you need, improving performance and flexibility.
Data Fetching with GraphQL: A Modern Approach to APIs
Last updated 16:33 06/07/2024 GMT+7

While REST APIs are the traditional way apps and websites talk to servers requesting and receiving data following defined rules, GraphQL, a Facebook innovation in 2012, allows apps to precisely specify their data needs, potentially fetching information in a more efficient way.

What is GraphQL?

GraphQL https://graphql.org/ is a query language for APIs (Application Programming Interfaces). Think of it as a way for apps to ask for exactly the data they need from a server.

Who’s using GraphQL?

How is it different from the traditional way?

Precise data fetching

  • Traditional: You get a fixed set of data, sometimes more than you need.
  • GraphQL: You ask for only what you want, nothing more, nothing less.

Traditional REST API:

GET /users/123
Response: { "id": 1, "name": "Huan Vu", "email": "[email protected]", "phone": "+84877698945", "address": "Gia Nghia, Dak Nong, Viet Nam" }

GraphQL:

query {
  user(id: 1) {
    name
    email
  }
}
Response: { "data": { "user": { "name": "Huan Vu", "email": "[email protected]" } } }

In this example, GraphQL only fetches the name and email, while the REST API returns all user data.

Single request

Traditional: You might need multiple requests to get all the data you need.

GET /users/123
GET /users/123/posts
GET /users/123/friends

GraphQL: One request can fetch data from multiple sources.

query {
  user(id: 123) {
    name
    posts {
      title
    }
    friends {
      name
    }
  }
}

This GraphQL query fetches user data, their posts, and friends in one request.

Faster performance

  • Traditional: More data transferred means slower loading times.
  • GraphQL: Less unnecessary data means faster apps.

Easier updates

Traditional:

  • Changes in data structure can break the app. In REST, the structure of the response is fixed. If you change the data structure on the server, all clients expecting the old structure might break.
  • Removing or changing fields often requires creating a new API version. APIs often need versioning (e.g., /api/v1/, /api/v2/) to maintain backwards compatibility.
  • Adding a field for a specific client might affect all clients. Significant changes often require updating the entire API and all clients simultaneously.

GraphQL:

  • It's more flexible, allowing easier updates without breaking things.
  • You can mark fields as deprecated. Clients can be informed about deprecated fields but can still use them, allowing for a smoother transition. You can add new fields and types without creating a new version. Old queries will still work, and new queries can use the new fields.
  • New fields can be added without affecting other clients. Only queries requesting the new field will receive it. New features can be added incrementally. Clients can adopt new fields at their own pace.

Self-documenting

Traditional:

  • You need separate documentation (like Swagger or API blueprints) to understand the API.
  • Documentation can become outdated if not carefully maintained.
  • Developers need to switch between documentation and code.
  • Understanding available data and relationships can be challenging.

GraphQL:

  • The schema itself describes what data is available.
  • Provides built-in introspection for exploring the API. GraphQL APIs support introspection https://graphql.org/learn/introspection/, allowing clients to query the schema itself.
  • Tools can automatically generate documentation from the schema.
  • Clearly defines types, fields, and relationships.

Retrieve data

  • GraphQL can retrieve data from various sources. Data for GraphQL can come from databases (MySQL, PostgreSQL, MongoDB, Cassandra, etc), existing APIs (REST APIs, SOAP services, etc).
  • The key point is that GraphQL acts as a layer between the client and these data sources. The GraphQL server handles the complexity of fetching data from multiple sources and presents it in a unified way to the client.
  • To use these data sources with GraphQL, developers typically create "resolvers" - functions that specify how to fetch the data for each field in the GraphQL schema. This allows GraphQL to be flexible and work with almost any type of data source.

GraphQL disadvantages

While GraphQL offers many benefits, it also has some disadvantages. Here are some key drawbacks:

  • Complexity for simple applications:
    • For basic CRUD operations or simple APIs, GraphQL might be overkill.
    • Setting up GraphQL requires more initial work compared to a simple REST API.
  • Performance concerns with nested queries:
    • Deeply nested queries can lead to performance issues if not properly optimized.
    • Risk of N+1 query problems if resolvers are not efficiently implemented.
  • Caching challenges:
    • Traditional HTTP caching methods don't work as well with GraphQL's single endpoint approach.
    • Implementing efficient caching requires more complex solutions.
  • Potential for over-fetching on the backend:
    • While clients can request only what they need, resolvers might still fetch more data than necessary from the database.
  • Learning curve:
    • Teams familiar with REST APIs need time to adapt to GraphQL concepts.
    • Requires learning new tools and best practices.
  • Overhead for simple queries:
    • Even simple queries require the full GraphQL parsing and validation process.
    • This can add unnecessary overhead for very basic data fetching needs.

These disadvantages don't make GraphQL a poor choice - it's still excellent for many use cases. However, they're important considerations when deciding whether to use GraphQL for a project.

Use GraphQL in your projects