GraphQL vs REST: A 2020 Perspective

GraphQL shifts power to the client.It solves over - fetching but introduces new complexity in caching and security.REST is not dead; it's just no longer the default for complex data requirements.

The Parade of Paradigms

For decades, REST(Representational State Transfer) was the undisputed king of APIs.It leveraged the primitives of the web—URLs, HTTP verbs, status codes—to create predictable, cacheable interfaces.Then came the mobile revolution.Suddenlt, round trips were expensive.The "chatty" nature of REST(call / users , then call /users / 1 / posts , then call /posts / 1 / comments ) became a performance bottleneck.

Facebook invented GraphQL to solve this specific problem.It allowed the client to ask for exactly what it needed—no more, no less—in a single request.But in solving one problem, it introduced ten others.This article dissects the trade - offs that often get glazed over in the hype cycle.

REST: The Strength of Simplicity

REST is beautiful because it is dumb.I mean that as a compliment.It pushes complexity to the edges.When you make a GET request to / api / products / 123 , everyone knows what's happening. The browser knows how to cache it. The CDN knows how to cache it. The load balancer knows how to route it.

• Caching: HTTP caching is solved. ETags, Last-Modified, Cache-Control headers work out of the box.
• Decoupling: The backend team exposes resources. The frontend team consumes them. The contract is the URL structure.
• Error Handling: 404 means Not Found. 401 means Unauthorized. 500 means server go boom. We have standard semantics.

GraphQL: Power to the Consumer

GraphQL inverts the control.The server exposes a schema(a graph), and the client traverses it.This is liberating for frontend developers.You want to render a user profile with their last 5 posts and the top comment on each post ? In REST, that's either 3 cascading endpoints or a custom /user-profile-summary endpoint that the backend team hates maintaining.

In GraphQL, it's just:

 
                                                                                                                                                                                                                                                                                                                                                    query {
    user(id: "1") {
        name
        posts(limit: 5) {
            title
            comments(limit: 1) {
                text
            }
        }
    }
}

No backend changes required.This velocity is why teams adopt GraphQL.

The Hidden Costs

However, "There is no such thing as free lunch." The complexity didn't disappear; it just moved from the client to the server.

1. The N + 1 Problem

This is the classic GraphQL pitfall.In the query above, the server fetches one user(1 query).Then it fetches 5 posts(1 query).Then for each of those 5 posts, it fetches comments. If you aren't careful, a single incoming HTTP request can explode into thousands of database queries.

Solution: DataLoaders. You must implement batching and request-level caching. You have to write code to coalesce those ID lookups into a single SELECT * FROM comments WHERE post_id IN (...).It's extra work.

2. Caching is Broken

Since every GraphQL request is usually a POST to a single endpoint(/graphql), you lose HTTP caching.The CDN sees every request as identical (or unique, depending on the body). You can't cache at the network edge easily.

Solution: Persisted Queries (turning queries into hashes) or complex client-side caching (Apollo Client's normalized cache).

3. Authorization Hell

In REST, you secure the endpoint. / admin / users requires an Admin token. Simple. In GraphQL, you have to secure the graph. A user might have permission to see a Post, but not the author_email field on that Post.You need field - level authorization logic.

Schema Stitching vs Federation

As organizations grow, a single monolithic GraphQL server becomes a bottleneck. "Who owns the User type? The Identity team or the Profile team?"

Apollo Federation solves this by allowing you to build a "Distributed Graph." Each microservice exposes a subgraph(e.g., the Billing service extends the User type with subscriptionStatus ), and a Gateway stitches them together. It's powerful, but it's a massive architectural commitment.

Decision Matrix: When to use what ?

Conclusion

Don't choose GraphQL just because it's trendy.Choose it if you have a "Graph" data problem—highly interconnected entities where the client access patterns vary wildly.If you just have a list of resources, REST is fine.In fact, newer tools like ** tRPC ** (for TypeScript monorepos) or ** React Server Components ** differ from both by removing the API layer entirely for internal usage.

---

References & Further Reading

• GraphQL Official Docs
• Apollo Federation
• tRPC: End - to - end typesafe APIs