NestJS — Enterprise Node.js

GraphQL Plugins, Complexity, Extensions & Federation

18 min Lesson 66 of 80

GraphQL Plugins, Complexity, Extensions & Federation

Production GraphQL needs operational controls. Apollo plugins hook into request lifecycle events, complexity analysis rejects overly expensive queries, extensions add response metadata, and federation splits one graph across multiple services.

Core idea

This feature is about controlling how the application is organized and how it behaves at runtime. These are the points a developer should understand before using it in a real project:

Plugins are the right place for GraphQL request logging, tracing, metrics, and lifecycle hooks.
Complexity limits protect the server from deeply nested or intentionally expensive queries.
Extensions can return metadata such as request IDs, cache hints, or tracing details to clients.
Federation uses subgraphs and a gateway to compose a single graph from multiple services.
Federated schemas require careful ownership of entities, keys, and cross-service references.

Practical example

The following example shows the idea in a practical NestJS project. The goal is not to memorize the snippet, but to understand where it belongs in the architecture:

GraphQLModule.forRoot<ApolloDriverConfig>({
  driver: ApolloDriver,
  plugins: [new ApolloServerPluginLandingPageLocalDefault()],
  validationRules: [
    createComplexityRule({ maximumComplexity: 1000 }),
  ],
  buildSchemaOptions: {
    orphanedTypes: [User],
  },
});

@ObjectType()
@Directive('@key(fields: "id")')
export class Product {
  @Field(() => ID)
  id: string;
}

Design note: GraphQL federation is an architectural choice, not just a package install. Start with a monolith unless independent teams truly need subgraph ownership.

Production checklist

Set query depth or complexity limits before exposing public GraphQL.
Add request IDs and tracing through plugins or extensions.
Define entity ownership before introducing federation.
Load test federated gateways because one client query can fan out to many services.

Rule of thumb: If the feature makes boundaries clearer and tests easier, it is probably the right choice. If it hides dependencies or makes tracing harder, redesign.

Summary

This lesson covers an advanced NestJS area that matters when building enterprise applications. Focus on clear boundaries, testable behavior, and choosing the right tool for the context instead of using every feature everywhere.