Over the past year, I’ve noticed more teams struggling with monolithic GraphQL implementations as their systems scale. When a client project demanded independent service deployment while maintaining a unified API layer, I turned to Apollo Federation with NestJS. This combination delivers modular GraphQL services that teams can develop independently, yet present as a single cohesive API. Let me show you how I build production-ready federated systems.

GraphQL Federation solves a critical challenge: enabling autonomous teams to own specific domains while exposing a unified graph. Instead of a single GraphQL server, we deploy multiple subgraphs (Users, Posts, Products) that a gateway composes into one schema. Each service defines its types and can extend types from other services. Why does this matter? Because it allows your billing team to update payment types without coordinating with the inventory team. How does the gateway resolve queries spanning multiple services? Through intelligent query planning.

First, we set up our workspace with three components: a gateway, users service, and posts service. Each runs in its own process:

# Create project structure
mkdir -p gateway users-service posts-service shared

For the users service, we define our Prisma schema. Notice how we exclude sensitive fields like passwords from our GraphQL type:

// users-service/prisma/schema.prisma
model User {
  id        String   @id @default(cuid())
  email     String   @unique
  password  String   // Not exposed in GraphQL
  posts     Post[]   // Reference to posts service
}

The GraphQL entity uses Apollo’s @key directive to identify the primary key:

// users-service/src/users/user.entity.ts
@ObjectType()
@Directive('@key(fields: "id")')
export class User {
  @Field(() => ID)
  id: string;
  
  @Field()
  email: string;
  
  // password omitted from fields
}

Authentication requires special handling in federated systems. We implement a guard that validates JWT tokens across services:

// shared/auth.guard.ts
@Injectable()
export class AuthGuard implements CanActivate {
  constructor(private jwtService: JwtService) {}

  canActivate(context: ExecutionContext): boolean {
    const request = context.switchToHttp().getRequest();
    try {
      const token = request.headers.authorization.split(' ')[1];
      request.user = this.jwtService.verify(token);
      return true;
    } catch {
      return false;
    }
  }
}

For the posts service to reference users, we extend the User type without redeclaring it:

// posts-service/src/posts/post.entity.ts
@ObjectType()
@Directive('@key(fields: "id")')
export class Post {
  @Field(() => ID)
  id: string;

  @Field()
  title: string;

  @Field(() => ID)
  authorId: string;

  @Field(() => User)
  author: User;
}

// Extend the User type from users service
@ObjectType()
@Directive('@extends')
@Directive('@key(fields: "id")')
export class User {
  @Field(() => ID)
  @Directive('@external')
  id: string;
  
  @Field(() => [Post])
  posts?: Post[];
}

Query optimization becomes crucial when resolving cross-service relationships. We batch user requests when fetching posts with authors:

// users-service/src/users/users.service.ts
async findMany(ids: string[]) {
  return this.prisma.user.findMany({
    where: { id: { in: ids } },
    select: { id: true, email: true } // Never return passwords
  });
}

When deploying, we configure the gateway to discover our services dynamically:

// gateway/src/gateway.service.ts
@Injectable()
export class GatewayService implements GatewayModuleOptions {
  server = new ApolloGateway({
    supergraphSdl: new IntrospectAndCompose({
      subgraphs: [
        { name: 'users', url: process.env.USERS_URL },
        { name: 'posts', url: process.env.POSTS_URL }
      ]
    })
  });
}

For monitoring, we add tracing to ApolloServer and integrate with Datadog. This reveals which services resolve specific query segments and how long they take. What happens when a service goes down? The gateway continues serving unaffected parts of the schema while returning partial errors for impacted fields.

I’ve deployed this pattern across three production systems now, and the operational benefits are significant. Teams deploy their services independently, schema changes are automatically composed, and clients interact with a single endpoint. Have you tried implementing rate limiting in federated systems? Share your approach in the comments.

If this breakdown helped you understand federated GraphQL, hit the like button! Share it with your team if you’re considering microservices. What other federation challenges should I cover next? Let me know in the comments below.