> ## Content Index
> Fetch the complete content index at: https://blog.kyleelliott.net/llms.txt
> Use this file to discover other available public pages before exploring further.

# What Even Is GraphQL, and Why Would You Use It Instead of REST?
- URL: https://blog.kyleelliott.net/what-even-is-graphql-and-why-would-you-use-it-instead-of-rest/
- Published: 2026-05-08T13:07:48.000Z
- Updated: 2026-05-08T13:07:48.000Z
- Description: GraphQL offers flexibility and control over data requests, but it’s not always the best tool. In this post, I explore where GraphQL fits into modern development and when sticking with REST might be the smarter move.
- Author: Kyle Elliott
- Tags: development, api

I’ve mostly worked with REST APIs over the years. They’re familiar, they’re everywhere, and they’re still the standard for most of the projects I touch. But lately, I’ve been seeing more jobs and clients asking for experience with GraphQL. So I spent some time digging in.

This isn’t a deep technical dive. It’s a practical overview of GraphQL and when it actually makes sense to reach for it, especially as a freelance developer.

## The Problem with REST (Sometimes)

REST works great in a lot of cases. You hit predictable endpoints and get back structured data. But there are a few common issues:

- **Overfetching**: You get more data than you need (e.g., a `/users` endpoint that returns everything).
- **Underfetching**: You have to make multiple requests to piece together what you actually want.
- **Rigid structure**: You’re stuck with what the endpoint gives you unless the API is updated.

In a small app, this doesn’t matter much. But when you’re working with complex data models (or trying to stitch systems together) it gets messy.

## What GraphQL Does Differently

With GraphQL, you describe **exactly** what data you need, and you get it in one request. It’s a single endpoint that takes a query payload.

```graphql
query {
  user(id: 123) {
    name
    email
    orders {
      id
      total
    }
  }
}
```

The response mirrors the query:

```
{
  "data": {
    "user": {
      "name": "Kyle",
      "email": "kyle@example.com",
      "orders": [
        { "id": 1, "total": 49.99 },
        { "id": 2, "total": 23.75 }
      ]
    }
  }
}
```

You don’t need to hit three different endpoints or filter anything out on the client.

![A MacBook with lines of code on its screen on a busy desk](https://images.unsplash.com/photo-1498050108023-c5249f4df085?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDExfHxjb2RlfGVufDB8fHx8MTc1OTg1ODg0NXww&ixlib=rb-4.1.0&q=80&w=2000)

Photo by [Christopher Gower](https://unsplash.com/@cgower?ref=blog.kyleelliott.net) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit)

## **So, Why Would You Use GraphQL?**

Here’s where GraphQL starts to shine:

- **Frontend flexibility**: Frontend devs can ask for only what they need, no more, no less.
- **Reduced round-trips**: One call can replace several chained REST calls.
- **Strong typing**: Clients know what shape the data will be. That helps when working across teams or contracts.

## **Why You Might Not**

GraphQL is powerful, but it’s not always the best fit:

- **Overhead**: It takes more setup, especially if you’re building the schema yourself.
- **Caching is more difficult**: Since all requests go through the same endpoint, HTTP caching strategies don’t apply the same way.
- **Security and rate-limiting**: You need to be more careful about exposing data and controlling what can be queried.

## **My Take (So Far)**

If I’m spinning up a quick API or microservice for internal use, I’ll probably stick to REST. It’s easier to set up and reason through, plus more people understand it.

But if the project involves a growing frontend, complex relationships, or a need to reduce client-side logic, GraphQL is worth it. I’ve started using it more with automation tools too, since some APIs only expose GraphQL now.

I won't be replacing REST, but having another option when the use case fits.

*If you’ve been curious about GraphQL but put it off, give it an afternoon. Build something simple. Knowing when to use it is half the value anyway.*