What Even Is GraphQL, and Why Would You Use It Instead of REST?

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.

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.

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.