Part 8.1 — Why GraphQL Exists: Problems It Tries to Solve

GraphQL did not emerge because REST is “bad.”
It emerged because API design often ignored how clients actually consume data.

To understand GraphQL properly, you have to stop thinking in terms of technologies and start thinking in terms of pain. This post explains the real problems GraphQL was created to solve—and why those same problems can still exist today, even if you never touch GraphQL.

1. The Original Pain: Mobile Clients

GraphQL was born inside Facebook, in a world where:

• mobile networks were slow

• devices were underpowered

• apps needed precise data control

• backend teams moved slower than frontend teams

The core issue was not protocol choice.
It was client dependency on server decisions.

2. Over-Fetching: Getting More Than You Need

Classic REST problem:

GET /users/42

Response:

{
  "id": 42,
  "name": "Alice",
  "email": "alice@example.com",
  "address": "...",
  "preferences": "...",
  "settings": "...",
  "auditLogs": [...]
}

The client only needs:

• id

• name

But it receives everything.

Problems:

• wasted bandwidth

• slower parsing

• tighter coupling

• accidental data exposure

Over-fetching isn’t just inefficiency—it’s loss of control.

3. Under-Fetching: Not Getting Enough

The opposite problem:

GET /posts

Returns:

[{ "id": 1, "title": "Hello" }]

Now the client needs:

• author name

• comment count

So it makes more calls:

GET /posts/1
GET /users/9
GET /posts/1/comments

Problems:

• multiple round trips

• waterfall requests

• fragile client logic

Under-fetching forces clients to orchestrate the backend.

4. The Real Problem: Fixed Responses

Traditional REST endpoints return fixed shapes.

That means:

• server decides what data looks like

• clients adapt or work around it

• adding fields risks breaking consumers

GraphQL’s core idea was simple:

Let the client ask for exactly what it needs.

Everything else follows from that.

5. Frontend Teams Move Faster Than Backends

Another root cause: team structure.

Common reality:

• frontend ships weekly

• backend ships monthly

• API changes are gated

• clients are blocked

GraphQL shifts responsibility:

• backend defines capabilities

• frontend composes queries

This decoupling is powerful—but costly.

6. Multiple Clients, Conflicting Needs

One backend, many consumers:

• web app

• mobile app

• admin dashboard

• third-party integrations

Each wants:

• different fields

• different nesting

• different performance trade-offs

REST often responds by:

• adding more endpoints

• adding more versions

• adding flags and hacks

GraphQL responds by:

• exposing a flexible graph

• letting clients shape responses

Again: flexibility vs complexity.

7. REST Was Never the Villain

Here’s the uncomfortable truth:

Most GraphQL “wins” come from fixing bad REST APIs.

Problems blamed on REST are usually caused by:

• poorly designed endpoints

• lack of DTO discipline

• server-centric thinking

• ignoring client usage patterns

REST itself never forbade:

• sparse responses

• nested includes

• pagination

• field selection

They were just… not enforced.

8. GraphQL Is a Response to Process, Not Protocol

GraphQL solves:

• coordination problems

• versioning anxiety

• client-server friction

It does not magically solve:

• N+1 queries

• authorization complexity

• caching difficulty

• operational overhead

Those problems still exist—just in different places.

9. The Hidden Costs GraphQL Introduces

Before romanticizing GraphQL, understand the trade-offs:

• more complex tooling

• harder caching

• complex auth rules per field

• runtime query cost analysis

• new failure modes

GraphQL shifts complexity—it does not remove it.

10. Why This Part Still Teaches REST Only

In this program, we keep:

• PostgreSQL

• Prisma

• NestJS

• REST APIs

On purpose.

Because most GraphQL benefits come from:

• better API design

• client-aware responses

• intentional data modeling

All of which you can do with REST—cleanly and predictably.

11. The Mental Shift That Matters

The real lesson of GraphQL is this:

APIs should serve client needs, not backend convenience.

Once you internalize that, your REST APIs start to:

• shrink

• clarify

• stabilize

• scale better

The tool matters less than the mindset.

12. What Comes Next

In the next post, you’ll learn:

• how GraphQL thinks in schemas and resolvers

• how those ideas map directly to

  • REST controllers

  • services

  • DTOs

No GraphQL implementation.
No schema language.
Just clear mental models you can apply today.