Can we run Apollo federation along with the monolithic GraphQL server

We have a monolithic GraphQL server and now we are trying to migrate to Apollo federation but we want to do one service at a time so we were wondering if we can have a single Apollo server that can serve traffic to both monolithic server and to the federated server.
Federation document does have a section about incremental approach(Introduction to Apollo Federation - Apollo Federation - Apollo GraphQL Docs) but we are not sure if we can have production traffic with an Apollo gateway serving traffic to both instances.


If you have native and web apps using the existing monolith, I think the best option is to set up a gateway service with the same endpoint as your monolith, update the schema document in your monolith to use federation architecture (extend type query). With these two pieces in place, your production traffic should now go through the gateway and then hit your monolith (which is now a federated service).

Once you have the above, you can start migrating types/queries from your monolith into different federated services. Here’s a hellpful guide for migrations - Entities - Apollo Federation - Apollo GraphQL Docs

Hi kartik_gujarati!

Thanks for the response, I was hoping not to migrate our entire graph to use federation architecture ( extend type query ). Our graph is quite big so we wanted to migrate only a part of our graph to use federations to see the gains we get from it before we migrate the entire graph. That’s the reason we wanted a way to serve traffic to our monolith and federated service based on the request with the help of gateway or without.

Please let me know if this is something that we can do out of the box.


If you want to maintain both federated server and the monolith at the same time, one option I can think of is to setup the federated server gateway with a different endpoint and have the newer versions of your clients talk to the new federated services through gateway’s endpoint while continuing to support older clients through the monolith. You can use a phased rollout or feature flagging approach to safely rollout the switch-over.

Got it, Thanks @kartik_gujarati for all the help.

@Nagarchith_Nama_Bala We recommend having a single endpoint. If you put a Gateway in front of a single existing GraphQL service, you don’t need to use federated features and directives (e.g., extend types are native to GraphQL, but you don’t even need to use them) you should find success and be able to avoid the separate endpoint and be in the best position to start adding new services.

@abernix Thanks for that suggestion but even with a gateway in front of our existing service, I don’t seem to find a way to serve both my legacy/monolith graph and the federated graph at the same time via the gateway. Can you please point me to any documentation that can help me with this? We already have migrated part of our graph over to use federation but we wanted to test it out in production before switching the rest over. During this testing phase we want to run both of our graphs/servers to not cause any issues to our client apps.

1 Like

@abernix We have a similar situation. We’re starting with a very small set of services, and there’s some resistance to adding a network hop (even if on same host) to reach out to a subgraph.

We definitely want to be structured properly for some point down the line when we add more services however, and as a result want to have ourselves set up correctly for Federated Graphs even if initially we’re not federated. – Any thoughts?

If you really really really want to avoid the network hop, you can run a gateway and a monolith GraphQL API in the same process.

import { ApolloGateway, LocalGraphQLDataSource, RemoteGraphQLDataSource } from '@apollo/gateway';

// your current graphql schema
const monolithSchema = makeExecutableSchema({ ... });

const gateway = new ApolloGateway({
  buildService({ name, url }) {
    if (name === 'monolith') {
      return new LocalGraphQLDataSource(monolithSchema);
    } else {
      return new RemoteGraphQLDataSource({ name, url });

When using managed federation, you can publish your monolith schema as a subgraph. It can be your only subgraph until you start breaking up the monolith.

(This works only if you’re doing everything in JavaScript/TypeScript today, of course.)

That being said, don’t fear the extra network hop! It’s minimal with a well-tuned Node.js server.

1 Like