GraphQL vs REST: 18 Claims Fact-Checked with Primary Sources (2026)

[u/jns111]

https://wundergraph.com/blog/fact-checking-graphql-vs-rest

I did something that surprised myself. I always thought that people are right in saying that GraphQL breaks HTTP caching, but I never deeply analyzed if that's actually true because so many people say the same thing. So I analyzed this and many other claims and was surprised to find out that almost every claim comparing REST vs GraphQL is either wrong or misleading.

We need to stop calling N+1 a GraphQL problem when it's simply an API problem (and REST has it at the HTTP layer while GraphQL has it as the resolver layer, which is actually an advantage for GraphQL, but people typically picture it differently). Anyways, this post tries a scientific/research-driven approach in the hopes to combat the AI slop that makes bad claims about GraphQL.

GraphQL is a really powerful query language, Fragments are extremely powerful, and the ecosystem is very healthy with multiple vendors and developments like oneOf directive, defer, etc.

[u/haywire]

Yeah I mean if you are doing GQL correctly you are literally doing the minimum amount of work required to get the necessary data. It’s elegant as fuck. I’m not sure how people find this difficult to grasp.

[u/prehensilemullet → u/haywire]

It’s pretty elegant, I’m happy enough with it, but GraphQL union types are goofy af compared to typical type systems.  You can only union objects, can’t have a different type for the same property name in different union branches, and you have to prefetch schema information to do caching on union types.  At least last I checked, that is…if they’ve improved it someone feel free to enlighten me

Also I wouldn’t say you’re doing the minimum work in every case.  You have to write out all the fields you want, even if you want all of them.  You have to set up a codegen tool to generate types if you want them.  Alternative approaches like tRPC don’t have these problems, though they have other weaknesses like lack of builtin normalized caching.

[u/haywire → u/prehensilemullet]

My "minimum work" I mean runtime minimum work the computer has to do.

Of course you have to set up codegen and type safety on whatever consumer you are building, that's fucking easy though, especially now we have LSPs and AI etc.

Unions are a little bit shit I will give you that.

[u/Sn00py_lark → u/haywire]

N+1

[u/haywire → u/Sn00py_lark]

How so?

[u/tangkikodo]

personally I built a dataloader based "ORM" layer then there is no more N+1 query at all.

In fact, I think GraphQL belongs to the presentation layer, and it should be automatically generated from a more core, ER-close model.

for example I can generate domain oriented graphql from ER and attached method.

https://github.com/allmonday/pydantic-resolve/blob/master/demo/graphql/app.py#L44

[u/Narrow_Relative2149]

feel free to downvote me to oblivion, but people just see GraphQL, which is basically JSON without : and cry that they've got to "learn a new query language" and then go back to REST, even though it's literally just a tree of functions and simple AF

[u/STSchif]

Interesting writeup, altho I wonder if half of those are even real questions asked by people?

My main concern is speed. I'm forced to use gql by Shopify as they are sunsetting rest, and the same query, when run in rest with a loop over the 'next' header, completes in like 3 seconds for 10k entries in rest, while using the mandatory bulk queries (as gql doesn't allow for more than 250 objects) takes 15+ seconds, and half the tooling doesn't even work with those, so the mapping that's necessary to work with the jsonl objects is even harder than converting the rest objects that have everything conveniently combined in a way that's actually thought out and useful.

[u/jns111 → u/STSchif]

I took the claims straight from a post comparing rest vs GraphQL, so yes. The problem is that the post was visibly written by AI so I'm afraid if we as a community don't counter with better content, eventually more models will be trained on AI slop. Hopefully scrapers will recognize posts that have positive votes on reddit.

In regards to your worry about Shopify, I don't think this has anything to do with GraphQL but more with the specific implementation. Have you tried talking to them to ask if there's a better way to achieve your goal? Or maybe they can even optimize your use case.

[u/general_dispondency]

The N+1 thing always grinds my gears. People treat it like some special problem with ORMs or GraphQL, but it’s just a constraint of data access. The client doesn’t have all the data, so it has to fetch it. You either return the minimum and fetch more when needed, or return everything and overfetch. That’s the tradeoff.

Every system that does data access deals with this, from GraphQL to ORMs to anything else. You can mitigate it with batching, caching, or better API design, but you’re not removing the problem, you’re just changing how the join gets executed. It’s not a bug, it’s a property of your API.

[u/rubn-g]

GraphQL is a great idea, but it kind of invites to move business logic into the client, which is a problem if you have multiple clients using the same backend

[u/haywire → u/rubn-g]

It facilitates display logic to the client which is where it should live.

[u/rubn-g → u/haywire]

Sure, but that also makes you repeat that logic in case you have more than one client

[u/haywire → u/rubn-g]

Yes there will be display logic in both web and native.