GraphQL vs REST

Welcome to the latest edition of the WunderGraph Community Newsletter. This issue is built around a single post that examines 18 claims people often make about GraphQL and REST. When we could, we traced each back to primary sources, and the results weren't always what we expected.

18 Claims. 3 Confirmed. 6 Partially True. 9 Misleading.

Claiming GraphQL is inferior to REST because it breaks HTTP caching is misleading. The infamous N+1 problem? It's real, but REST has it too.

Jens spent a lot of time researching the REST vs. GraphQL arguments that keep showing up in blog posts, conference talks, and hot takes. Of 18 claims checked, 3 were confirmed. 6 were partially true. 9 proved misleading or incomplete.

A few highlights worth knowing before the next debate:

• API security issues are not unique to GraphQL. The article cites Salt Security’s 2024 report, which found that 95% of organizations experienced API security incidents in production, and 23% reported an API-related breach. These findings apply to APIs broadly, not GraphQL specifically.
• The “80% of GraphQL APIs are vulnerable to DoS” stat is misread. The article says Escape’s report found 69% of the API services they scanned had issues related to unrestricted resource consumption, which can lead to denial-of-service (DoS) conditions. The commonly cited 80% figure referred to the share of identified GraphQL issues that were fixable with basic best practices, not to the percentage of APIs vulnerable to DoS.
• GraphQL does not break HTTP caching. GraphQL can use standard HTTP caching when queries are persisted. Persisted queries allow requests to be sent as GET, which enables CDN caching just like REST. The limitation is not the protocol, but how queries are structured and delivered.

Performance varies by workload, and neither approach is consistently faster.

REST often performs well for flat CRUD and high concurrency. GraphQL often performs well for relational queries, multi-resource fetches, and bandwidth efficiency. Benchmarks that don’t reflect real workloads, like simple Hello World tests, can misrepresent how these systems perform in practice.

Read the full post: GraphQL vs REST: 18 Claims Fact-Checked with Primary Sources

The right question is not which one wins.

The REST vs GraphQL debate keeps producing articles that pick a side and build the case. Both sides select favorable benchmarks, ignore inconvenient tradeoffs, and declare the other technology dead.

The evidence does not support either extreme. 93% of respondents report using REST in the Postman 2025 survey. Gartner has predicted that more than 60% of enterprises will use GraphQL in production by 2027. The Postman survey also shows that 33% of developers use GraphQL alongside REST. They coexist because they solve different problems.

For public APIs, flat resources, and stable URLs: REST. For a single TypeScript frontend and backend: maybe tRPC. For relational data, cross-team composition, and multiple consumers with different needs: GraphQL. For scaling from one team to many: Federation. You can have Federation as the composition layer and REST as the consumption layer. They aren't mutually exclusive.

The next time you read a post making technical claims about either technology, check the sources. Read the original docs. Look at the methodology. The evidence is out there.

State of GraphQL Federation 2026 Survey

We’ve launched the 2026 State of GraphQL Federation Survey, and we need your input. It only takes 5-10 minutes, and for every completed survey, we’ll donate $30 to UNICEF.

We are capturing how organizations adopt, operate, and scale Federated GraphQL architectures. Your input shapes an unbiased, vendor-agnostic view of Federation in practice across organizations at every maturity stage.

Take the Survey

From the Archives

Episode 5 · APIs, Development, and GraphQL

Jens and Stefan break down why most API debates go wrong. Teams argue from opinions, benchmarks, and vendor narratives instead of real use cases and customer needs.

“You should be advocating the category, not the solution… Let our customers with their stories speak about how they use Cosmo.”

Key takeaways:

• Most API debates are driven by narrative, not evidence.
• Benchmarks and hot takes rarely reflect real workloads.
• The right choice depends on your use case, not ideology.

Watch the episode →

The Good Thing is where developers, architects, and founders talk candidly about how they're building the future of APIs, infrastructure, and AI. This newsletter distills those insights into a five-minute read, every other week.

Like what you read? Hit Subscribe to get technical insights from real builders.