Join data across APIs: GraphQL, REST, PostgreSQL, MySQL and more - WunderGraph

CEO & Co-Founder at WunderGraph

January 4, 2022·10min read

Last updated on September 9, 2025

Archive Notice

This article is archived and no longer maintained. It describes an earlier version of WunderGraph, including experimental features that are no longer part of the current product. The concepts and examples may not work as described. For current documentation and guidance, see https://wundergraph.com/cosmo

One way to think about APIs is to see them as lego blocks. They might be (Micro-) Services within your company or an API from a third party, but in the end, it's just lego blocks to solve specific problems.

The number of lego blocks being created is constantly growing, which leads to a few problems.

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.

Client-Side Application-Level Joins

First, you need a GraphQL client that allows multi tenancy. That is, many GraphQL clients are designed to work with a single GraphQL API.

Then we define the two Queries, one to fetch the capital, the other to get the weather data. From the result of the first Query, we use the name of the capital to fetch the weather data.

Finally, we combine the two results and get our desired result.

The solution is simple and doesn't require any additional backend. You can deploy the application to a CDN almost for free.

Server-Side Application-Level Joins

Another solution would be to move this logic to the server. Instead of using multiple GraphQL clients in our client application, we move them to our backend and expose the whole operation as a REST API.

The logic is the same as above, but moving it to the server introduces a few advantages but also drawbacks.

First, the client gets a lot simpler. It makes a single REST API call to fetch the data. There's no client needed, you can just use "fetch" from the browser.

However, we now have to run a backend to fetch the data and combine it. So we need to figure out a backend stack and need to decide how and where to deploy it.

Database Joins

Another way of joining data, probably the most widely known, is to use a database. Although a database join is not really suitable to combine the responses of APIs, it's still worth mentioning here.

PostgreSQL for example, has the concept of Foreign Data Wrappers (FDW). There are ways to use a FDW to join a table to another database or even using an HTTP call.

Apollo Federation

Another solution to join data from multiple APIs is to use Apollo Federation. Apollo Federation allows you to define the composition of multiple GraphQL (Micro-)Services from within the GraphQL Schema.

The idea of Federation is to have "one single GraphQL Schema" across the whole organization. An API Gateway that supports Federation will then distribute the requests to the different services.

WunderGraph doesn't just support Apollo Federation as a DataSource. We're also the only service capable of handling GraphQL Subscriptions for Federated APIs.

Schema Stitching

As we've learned before, Federation is not a solution to implement joins across organizations / Graphs.

Schema stitching, in contrast to Federation, is a centralized solution to facilitate JOINs across GraphQL APIs. While Federation encourages to share the JOIN configuration across all services that belong to a Graph, Schema stitching moves this logic into a single centralized service.

WunderGraph: GraphQL Query Joins

We've looked at the GraphQL landscape for a while and observed how others have implemented JOINs. The most popular approaches have been discussed above.

Looking at these existing solutions, we've always felt that they add a lot of complexity. We wanted to find an easier way to JOIN data across APIs, so we've started experimenting.

For a long time, we thought that the solution needs to be to JOIN the APIs in the GraphQL Schema. This might sound obvious because it's the default way of thinking.

It took us a while, but we finally realized that with WunderGraph, you can actually JOIN APIs from within the GraphQL Operation. There's no need to use Federation or Stitching, just write a GraphQL Query with some small additions.

So, how does the solution look like?

First, we need to add the two APIs to our project:

const countries = introspect.graphql({
  apiNamespace: 'countries',
  url: 'https://countries.trevorblades.com/',
})

const weather = introspect.graphql({
  apiNamespace: 'weather',
  url: 'https://graphql-weather-api.herokuapp.com/',
})

Now that we've got the two APIs added to our "virtual Graph", let's define our REST API by writing a GraphQL Query.

What about PostgreSQL, MySQL, SQLite, SQL Server etc.?

WunderGraph is more than just another GraphQL Server, we've already got a wide array of connectors for different upstreams:

Conclusion

You've learned about multiple ways of joining data from different APIs. We talked about the different ways of solving the problem, pros and cons of Federation and Schema Stitching, and when to use which one.

We've then introduced the concept of joining APIs in the Query, a novel approach by WunderGraph that is possible by doing Server-Side only GraphQL instead of exposing it to the client.