State of GraphQL Federation 2026

Jens Neuse

CEO & Co-Founder at WunderGraph

April 14, 2021·min read
Last updated on July 18, 2026

This article is archived and no longer maintained. It describes an earlier version of WunderGraph built around the WunderNode and a "package manager for APIs" concept, which is no longer part of the current product. The examples and setup steps may not work as described. For current documentation and guidance, see current docs.

TL;DR

The post builds one example app, a weather API plus a jobs API in Next.js, and compares three ways to integrate them: client-side, server-side (the BFF pattern), and WunderGraph as a "package manager for APIs." Client-side integration is the easiest to start with but creates tight coupling, can't store secrets securely, and piles on boilerplate. A BFF removes the tight coupling and centralizes authentication and caching, but you pay for it in implementing, deploying, and maintaining the backend. The package-manager approach aims to give you the BFF pattern at lower cost: you declare your API dependencies in a config file, WunderGraph composes them into a virtual GraphQL schema, and it generates the BFF (hosted on the edge) plus a thin, typesafe client that handles login, caching, and invalidation, so you get authentication and edge caching by configuration with zero boilerplate.

Client-side integration

Client-side integration is one of the easiest approaches which also comes with some drawbacks. In this scenario, the application code sits side by side with the two clients, one for each API. It's clear that the client application talks directly to the APIs, creating a tight dependency between them.

Pros

• This approach comes with an easy to understand architecture.
• No additional backend needs to be deployed or operated.
• No extra dependencies, except the two APIs.

Cons

• We have a tight coupling between the client application and the two APIs.
• We need to choose a client technology to talk to the APIs.
• It's more complex to implement a unified authorization layer that works for both APIs.
• Implementing a unified caching strategy for both APIs is also rather complex.
• We need to handle multiple API clients in the client, the complexity of the client application will grow if we add more APIs.
• There's no way to store secrets in the application as the code is public so it's harder to limit access to the APIs.
• Lots of boilerplate required to talk to both APIs, e.g. setting up code generation for both APIs so that we can enjoy some type-safety.
• In general, this approach can get us results pretty fast. On the other hand, the drawbacks might overwhelm us in the long term.

Server-side integration

The second approach we'd like to look at is server-side integration. This pattern is also well known as "Backend for Frontend" (BFF). We're essentially moving the complexity of the integration to a secure server. This adds complexity but comes with a lot of benefits.

In this scenario, the client application only has a single API client which is talking to the BFF. The BFF consists of all the business logic, implements authentication & caching and contains API clients for both upstream APIs. The BFF secures access to the APIs and can apply general rules to both of them.

Pros

• There's no more tight coupling between the client application and the upstream APIs as they are abstracted away by the BFF.
• Rules like rate limiting, authentication & caching can be implemented in a unified way in the BFF.
• Secrets like API keys can be stored securely in the BFF.
• Less complexity in the client application as we can define exactly the API the client asks for in the BFF.

Cons

• Implementing, deploying and maintaining the BFF adds a lot of complexity (cost) to the project.
• The problem of solving authentication & caching still needs to be solved, just in a different layer.
• Cost for maintenance and extension of the application increases as both client and server (BFF) needs to be touched and deployed.
• The boilerplate to talk to both APIs is still required; it only moved to the server.

WunderGraph integration

As stated above, implementing a BFF is a very clean and easy to maintain architecture to solve a common problem. Our goal is to use the BFF pattern but reduce implementation and maintenance cost while increasing the developer experience. What is a package manager for APIs?

What is a Package Manager for APIs?

Throughout our careers, we had to solve many problems similar to the scenario described above. The problem is always the same: Get data from x different services that speak y different protocols. Compose all APIs together, secure the communication and make sure that content that can be cached will be cached to ensure good performance.

Getting data from different services and composing it together to form something new should sound very familiar to developers. Package managers help us bring all the dependencies into one place to build something new on top of them. We don't have to manually install code from others.

Yet, when it comes to APIs, we still live in a cave. If you're super lucky, someone pushed an OpenAPI specification somewhere. Or maybe you have to deal with a SOAP WSDL? What about GraphQL? When you deal with high class products like e.g. Stripe you're lucky because they offer an SDK, but does that really solve the problem?

All our Dependencies (APIs) are on the right. WunderGraph composes them into a virtual GraphQL schema. WunderGraph supports REST APIs (via OpenAPI Specification), GraphQL and Federation and can be extended for any other Protocol. The specifications of the origins will be automatically transformed into a virtual GraphQL schema. GraphQL has a very expressive type system and allows us to query exactly the data we need.

The WunderGraph client

The BFF alone wouldn't fully solve the problem. We still need a client in our frontend application. However, you also don't have to worry about the client. We're generating the client for you. The client is very thin but super smart. It knows how to log your users in and out. It knows how to cache data and when and how to invalidate it. Of course, the client also knows about all the operations, their inputs and how the responses will look like.

Pros of WunderGraph integration

• No tight coupling between your upstream APIs and the client.
• Authentication via configuration.
• Edge Caching via configuration.
• Typesafe generated client.
• No need to build, maintain and operate a BFF.
• Zero boilerplate.
• Extreme developer productivity.

Frequently Asked Questions (FAQ)

What are the drawbacks of client-side integration?

• It creates tight coupling between the client and the APIs, requires choosing a client technology, makes unified authorization and caching complex, can't store secrets because the code is public, and adds a lot of boilerplate.

What is the "Backend for Frontend" (BFF) approach?

• It moves the integration complexity to a secure server that holds the business logic and API clients for the upstream APIs, so the client only talks to the BFF, which removes tight coupling and lets rate limiting, authentication, and caching be implemented in a unified way with secrets stored securely.

What is the downside of building a BFF?

• Implementing, deploying, and maintaining the BFF adds a lot of complexity and cost, the authentication and caching problems still need to be solved in a different layer, and both client and server must be touched and deployed.

What is a package manager for APIs?

• It's an approach where you specify all your API dependencies in a configuration file, and WunderGraph introspects their schemas and composes them into a virtual GraphQL schema, similar to how a package manager brings dependencies into one place.

What does WunderGraph generate?

• It generates the BFF itself, hosted on the edge, and a thin, typesafe client that knows how to log users in and out, cache data, and invalidate it.