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.

The REST term triggers me. It should not. I should just let it go. But whenever someone says REST 99% of the time they mean HTTP and 98% of the time it is json over HTTP. REST is a specific access pattern where you ship the application required to respond to the query with every query. It is the REpresentational State of the REpresentational State Transfer. And while REST does not have to be html the web browser is realistically the only piece of tech in our stack that can actually do something with a representational state, which is a long winded way to say if you are not shipping html your transfer probably is not REST. json is not REST. in fact REST is almost always a human interface thing. if your transferred data is intended to be processed by machine. it is probably not REST.

Really, i just find it funny how Roy Fielding said "hey this web thing is actually doing something really novel in data access patterns lets give it a name so we can talk about it" and everyone collectively had a huge brain fart and said "Got it. HTTP == REST"