Claude Code NestJS: REST APIs, Module und Tests schneller entwickeln

NestJS ist das Framework, das Node.js-Backend-Entwicklung endlich strukturiert. Angular-inspirierte Architektur, TypeScript von Anfang an, Dependency Injection, Module — alles eingebaut. Der Preis dafür ist Boilerplate: Module, Controller, Services, DTOs, Guards, Interceptors, Pipes. Für jedes Feature mehrere Dateien, jede mit einem bestimmten Muster.

Genau hier setzt Claude Code NestJS an. Nicht um das Framework zu ersetzen, sondern um den Teil zu übernehmen, der mechanisch ist: Strukturen generieren, Muster anwenden, Tests schreiben. Was bleibt, ist die eigentliche Arbeit — Geschäftslogik, Datenmodelle, Architekturentscheidungen.

1. Was ist NestJS?

NestJS ist ein Node.js-Framework für den Aufbau serverseitiger Anwendungen. Es läuft auf Express oder Fastify als HTTP-Adapter und bringt eine vollständige Anwendungsarchitektur mit — ähnlich wie Angular, aber für das Backend.

Die Kernideen: Module kapseln zusammengehörige Funktionalität. Controller empfangen eingehende HTTP-Anfragen und geben Antworten zurück. Services enthalten die Geschäftslogik und sind über Dependency Injection in Controller und andere Services verfügbar.

TypeScript ist kein optionales Add-on, sondern der Standard. Decorators wie @Module(), @Controller() und @Injectable() beschreiben die Struktur deklarativ — NestJS kümmert sich um das Wiring im Hintergrund. Das Ergebnis ist Code, der lesbar, testbar und skalierbar ist.

2. Module, Controller, Services: die Grundbausteine

Jede NestJS-Anwendung besteht aus Modulen. Ein Modul fasst alles zusammen, was zu einem Fachbereich gehört: seine Controller, seine Services, seine Abhängigkeiten. Das Root-Modul heißt per Konvention AppModule.

// users/users.module.ts
@Module({
  imports: [TypeOrmModule.forFeature([User])],
  controllers: [UsersController],
  providers: [UsersService],
  exports: [UsersService],
})
export class UsersModule {}

Der Controller nimmt HTTP-Anfragen entgegen. Decorators wie @Get(), @Post(), @Put() und @Delete() mappen Routen auf Methoden. Parameter aus der URL werden mit @Param() gelesen, der Request-Body mit @Body().

// users/users.controller.ts
@Controller('users')
export class UsersController {
  constructor(private readonly usersService: UsersService) {}

  @Get()
  findAll() {
    return this.usersService.findAll();
  }

  @Get(':id')
  findOne(@Param('id') id: string) {
    return this.usersService.findOne(+id);
  }

  @Post()
  create(@Body() createUserDto: CreateUserDto) {
    return this.usersService.create(createUserDto);
  }

  @Put(':id')
  update(@Param('id') id: string, @Body() updateUserDto: UpdateUserDto) {
    return this.usersService.update(+id, updateUserDto);
  }

  @Delete(':id')
  remove(@Param('id') id: string) {
    return this.usersService.remove(+id);
  }
}

Der Service trägt das @Injectable()-Decorator und enthält die eigentliche Logik. Er wird durch den DI-Container in den Controller injiziert — kein manuelles new UsersService(), kein globaler Zustand.

3. DTOs mit class-validator

Data Transfer Objects definieren, wie eingehende Daten aussehen sollen. In Verbindung mit class-validator und dem ValidationPipe wird die Validierung deklarativ: Decorators direkt auf den Eigenschaften der DTO-Klasse.

// users/dto/create-user.dto.ts
import { IsEmail, IsString, MinLength } from 'class-validator';

export class CreateUserDto {
  @IsString()
  name: string;

  @IsEmail()
  email: string;

  @IsString()
  @MinLength(8)
  password: string;
}

Das ValidationPipe wird global im Bootstrap registriert und lehnt Anfragen ab, die nicht dem Schema entsprechen — mit verständlichen Fehlermeldungen, ohne eigenen Validierungscode.

// main.ts
app.useGlobalPipes(new ValidationPipe({ whitelist: true, transform: true }));

4. Middleware, Guards, Interceptors, Pipes

NestJS kennt mehrere Schichten, durch die eine Anfrage läuft, bevor sie den Controller-Handler erreicht — und eine Antwort, bevor sie den Client verlässt.

• Middleware — läuft vor dem Routing, kennt Request und Response direkt. Für Logging, CORS, Rate-Limiting.
• Guards — entscheiden, ob eine Anfrage den Handler erreicht. Für Authentifizierung und Autorisierung. Ein Guard gibt true oder false zurück.
• Interceptors — umhüllen den Handler. Können die Anfrage vor dem Handler transformieren und die Antwort nach dem Handler manipulieren. Für Response-Mapping, Caching, Logging.
• Pipes — transformieren oder validieren Eingangsdaten. Das ValidationPipe ist das bekannteste Beispiel. ParseIntPipe konvertiert automatisch URL-Parameter in Zahlen.

Die Reihenfolge ist festgelegt: Middleware → Guards → Interceptors (before) → Pipes → Handler → Interceptors (after) → Exception Filter. Wer das versteht, schreibt keinen Code an der falschen Stelle.

5. Datenbankanbindung mit TypeORM oder Prisma

NestJS integriert sich mit beiden großen TypeScript-ORMs. TypeORM ist das ältere, das NestJS-eigene Paket @nestjs/typeorm bietet Repository-Injection direkt ins Module-System.

// Prisma Service als Injectable
@Injectable()
export class PrismaService extends PrismaClient implements OnModuleInit {
  async onModuleInit() {
    await this.$connect();
  }
}

Prisma ist die modernere Wahl: typsicheres Schema, automatisch generierter Client, keine Decorator-basierten Entities. Die Integration in NestJS ist unkompliziert — PrismaService als Injectable, in jeden Service injizierbar der es braucht.

6. WebSockets und CQRS-Pattern

NestJS bringt mit @nestjs/websockets und @nestjs/platform-socket.io eine vollständige WebSocket-Integration. Ein Gateway ist wie ein Controller, aber für bidirektionale Verbindungen:

@WebSocketGateway({ cors: true })
export class EventsGateway {
  @WebSocketServer()
  server: Server;

  @SubscribeMessage('message')
  handleMessage(client: Socket, payload: string): string {
    this.server.emit('broadcast', payload);
    return payload;
  }
}

Für komplexere Anwendungen bietet @nestjs/cqrs das CQRS-Pattern (Command Query Responsibility Segregation): Commands verändern den Zustand, Queries lesen ihn. Commands werden über den CommandBus dispatcht, jeder Command hat einen dedizierten CommandHandler. Für Event-Sourcing und Event-Driven Architectures ist das die richtige Grundlage.

7. Claude Code NestJS: konkrete Tipps

Wo macht Claude Code bei NestJS-Projekten den größten Unterschied?

Boilerplate generieren

Der NestJS-CLI generiert Dateien, aber Claude Code generiert vollständigen, auf dein Projekt angepassten Code. Beschreibe das Feature, Claude Code erstellt Module, Controller, Service, DTO und Tests in einem Durchgang — bereits an deine bestehenden Konventionen angepasst.

claude "Erstelle ein vollständiges NestJS-Modul für Bestellungen (Orders):
- CreateOrderDto mit Validierung (userId, items-Array, Gesamtpreis)
- OrdersController mit CRUD-Endpunkten
- OrdersService mit Prisma-Anbindung
- Unit-Tests für den Service"

Modulstruktur analysieren und verbessern

Claude Code liest deine bestehenden Module und findet zirkuläre Abhängigkeiten, falsch exportierte Provider oder Services die zu viel verantwortung tragen. Beschreibe das Problem — oder gib einfach die Fehlermeldung weiter.

Tests schreiben

NestJS-Tests haben ein bestimmtes Muster: Test.createTestingModule(), Mock-Provider, Spies auf injizierte Dependencies. Claude Code kennt dieses Muster und schreibt Tests die tatsächlich isolieren, was isoliert werden soll.

claude "Schreib Unit-Tests für UsersService. Der Service nutzt Prisma.
Mock PrismaService vollständig und teste create(), findAll() und findOne()
inklusive den Fehlerfall wenn ein User nicht gefunden wird."

"Was früher 45 Minuten Boilerplate war, ist mit Claude Code in 5 Minuten erledigt. Was bleibt, ist die Architekturentscheidung selbst — nicht die mechanische Umsetzung."

Der wichtigste Tipp: Claude Code als Pair-Programmer, nicht als Ersatz. Du entscheidest, welche Module es gibt, wie die Datenmodelle aussehen, wo die Grenzen zwischen Services liegen. Claude Code setzt um, was du entschieden hast — schnell, korrekt und im richtigen Stil.

Weitere Artikel, die in diese Richtung weiterführen:

• Claude Code Prisma — Datenbankschemas, Migrationen und typsichere Queries
• Claude Code GraphQL — Schema-Design, Resolver und Code-First-Ansatz