State of GraphQL Federation 2026

Jens Neuse

CEO & Co-Founder at WunderGraph

January 22, 2022·10min read

Last updated on September 9, 2025

How are teams governing schema changes, handling production traffic, and measuring Federation success? Share your experience and get early access to the full report. For every valid survey completed, we'll donate $30 to UNICEF.

Introduction to GraphQL vs REST

GraphQL is usually praised to the moon and beyond while REST seems to be an old school way of doing things.

I keep on hearing from Developer Advocates about how great GraphQL is and how much better it is than REST. I keep reading blog posts that compare GraphQL and REST APIs where GraphQL is always much more powerful and flexible than REST, with no disadvantages obviously.

I think these comparisons fail to show the real value of following the constraints of REST. I believe that both GraphQL and REST are great tools to build powerful API solutions, when used together. It's not a question of either or, but rather of how well they can work together.

The Basics of REST

If you build a RESTful service, it's compatible with the REST of the web. If you don't care much about REST, your service will be less compatible with the web. It's not a goal to build something in a RESTful way, but doing so means that your service fits very well with the existing infrastructure of the web.

GraphQL and HTTP

GraphQL is a Query language. The GraphQL specification doesn't mention the word HTTP a single time. REST on the other hand is a set of constraints that, if you follow them, makes your service compatible with the web. When you're using GraphQL over HTTP, you're actually using REST, just a very limited version of REST because you're not following a lot of the constraints.

The Misunderstanding about REST

Most GraphQL enthusiasts see REST as bad, old-fashioned, and outdated. They believe that GraphQL is the successor of REST. This just doesn't make sense. If you want to use GraphQL on the web, you have to use HTTP and that means you're in REST territory.

You can either accept REST and try to follow the constraints, or you can ignore them and use GraphQL in a way that is not really leveraging the existing infrastructure of the web.

The Role of the URL

A URL uniquely identifies a resource on the web. Concepts like Caching and Cache Invalidation work when we use a unique URL for each resource. The GraphQL specification doesn't mention HTTP because it simply describes the Query language.

Stateless API Requests

Every API Request should be stateless. Stateless APIs are very easily scalable because you can easily scale your backend systems horizontally. This means that all information is sent in each request.

However, with GraphQL, the use of WebSockets complicates the stateless aspect. It's vital to understand how WebSocket connections operate and how they differ from standard HTTP requests.

Caching in REST vs GraphQL

By exposing REST instead of GraphQL, we gain the ability to cache requests without losing the capabilities of GraphQL. Browsers, CDNs, Proxies, and Cache Servers are able to cache REST requests, making the handling of HTTP caching much simpler.

Conclusion

GraphQL is an incredible tool, but the discussions around "REST vs GraphQL" should end. Instead, we should explore how to make the most out of both technologies. It's essential not to ignore the web's fundamental principles while building APIs for the web.