Jens Neuse
CEO & Co-Founder at WunderGraph
November 1, 2020·15min read
Last updated on July 6, 2026

State of GraphQL Federation 2026

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.

TL;DR

Most benefits credited to GraphQL are not actually unique to it. Over-fetching, multiple round trips, waterfall requests, and clients needing to know where each service lives can all be handled with the backend-for-frontend (BFF) pattern using tools like Next.js and swr, which provide caching, Etags, and 304 responses with less data transfer and a smaller client. GraphQL does not inherently fix versioning. Type safety is often a trust/people problem an OpenAPI Specification can match, while documentation and error handling still require developer effort and tooling on both GraphQL and REST/OAS. What actually makes GraphQL powerful is its tooling and ecosystem, similar to how Docker needed something like Kubernetes. WunderGraph, now the open-source Cosmo federation platform, is one approach to getting those benefits without the tradeoffs.

The downside of REST

The author states that REST APIs come with a set of downsides and how GraphQL solves all of them: Over-fetching, multiple requests for multiple resources, waterfall network requests on nested data, and each client needing to know the location of each service.

The first three issues could be solved by writing another REST API as a facade for a specific user interface. Take Next.JS as an example. Next lets you define APIs with a very lightweight syntax. Instead of making multiple requests from the client, you can wrap those calls into an API and make them server-side. Over and underfetching can be solved with this approach too, as you can manipulate the data before sending it back to the client. The pattern described is named "backend for frontend" (BFF). It's not limited to full-stack frameworks like Next.JS. You can build a BFF for your mobile apps as well.

With the BFF pattern, the client itself doesn't have to know the location of each service. However, the developer who implements the BFF needs to understand the service landscape. Hopefully, you have OpenAPI Specifications for all your services, nicely presented in a developer portal.

With GraphQL, there still needs to be a developer who implements the resolvers. Implementing the resolvers is more or less the same task as building a BFF, the logic is very similar. So, what's the real difference?

The BFF is easier to implement as there's a lot more tooling available. E.g. if you use a framework like Next.JS in combination with swr hooks (stale while revalidate) you get automatic caching with Etags and cache invalidation out of the box. This reduces the amount of data sent between server and client.

When it comes to user experience and ease of development, the BFF is the clear winner. Less data transfer between client and server. Easier to implement. Smaller client, less moving parts.

No more versioned APIs

In the next paragraph, Kyle goes on with the problems involved with versioned APIs. Just because GraphQL schemas don’t support versioning natively doesn’t mean the problem goes away. If having too many versions of your REST APIs is a problem in your organization, before throwing a new tool like GraphQL at the problem, you should have a look at the organization first.

Smaller payloads

RESTful APIs don't allow partial responses, which is incorrect. With the BFF approach, you don't need this as you can just return exactly the data you need.

Strictly-typed interfaces

OAS allows you to describe all your APIs easily. GraphQL is lacking features to describe Authentication, Authorization, and input validation. The problems with APIs not being clearly defined are often organizational issues that can be solved with proper OAS documentation.

Better client performance

GraphQL does reduce the number of requests and overall data transfer. However, consider the cost of adding a GraphQL client.

Less time spent documenting and navigating APIs

While navigating a single GraphQL schema is simpler than looking at multiple OAS files, it's crucial to set up a developer portal for productive API usage. Documentation effort is vital regardless of the tools used.

Legacy app support

Supporting legacy apps is a challenge with both REST and GraphQL APIs. You need to ensure that the contract between client and server is not broken.

Better error handling

Both OAS and GraphQL provide good tooling for error handling, and it depends on the developer to utilize these tools effectively.

Conclusion

The author concludes that while GraphQL is indeed the future of APIs, it should not be oversold as a unique solution. Developers must weigh their needs against what tools will serve them best.

Frequently Asked Questions (FAQ)

Can the downsides of REST that GraphQL claims to fix be solved another way?
Yes. Over-fetching, multiple requests, and waterfall requests on nested data can be solved by writing a backend for frontend (BFF), for example with Next.js.

Does GraphQL solve API versioning?
No, GraphQL does nothing to solve versioning problems; you get the same effect by simply not versioning your REST APIs.

Is GraphQL's type safety an advantage over REST?
Type safety in GraphQL often comes down to trusting the server behavior, whereas OpenAPI can provide similar assurances.

What actually makes GraphQL powerful?
It's the tools, community, and ecosystem that make GraphQL powerful, similar to how Docker needed a scheduler like Kubernetes.

When is REST still the better choice?
REST APIs excel for internal, partner, and server-to-server communication where GraphQL may not offer additional benefits.