Zum Inhalt springen
Alle Projekte

NestJS Production Starter

Ein Ausgangspunkt für neue APIs: JWT mit rotierenden Refresh-Tokens, Rollen, Swagger, Docker, Tests und CI.

Art
Nebenprojekt
Tech-Stack
  • NestJS
  • JWT
  • Swagger
  • Docker
  • CI
Illustration von NestJS Production Starter

Warum

Jedes Backend braucht dieselbe Grundlage: Authentifizierung, Validierung, Konfiguration, Logging, Migrationen, API-Doku, Container und CI. Das sauber aufzusetzen dauert Tage, und unter Zeitdruck entstehen Abkürzungen, die sich später rächen. Dieser Starter ist genau diese Grundlage, einmal ordentlich gebaut und getestet, bereit zum Klonen und Erweitern.

Was drin ist

BereichEnthalten
AuthJWT-Access-Tokens mit rotierenden Refresh-Tokens, Passwörter mit bcrypt gehasht
Rollen@Roles('admin')-Guards und ein @CurrentUser()-Decorator
ValidierungGlobale ValidationPipe mit class-validator-DTOs, Whitelisting und Transformation
DatenbankPostgreSQL mit Prisma, Migrationen und Seed-Skript
DokuSwagger/OpenAPI unter /docs, inklusive Authentifizierung
KonfigurationTypisierte Umgebungsvariablen, beim Start validiert
FehlerEin globaler Exception-Filter mit einheitlichem Fehlerformat
SicherheitHelmet, CORS-Konfiguration und Rate-Limiting über @nestjs/throttler
Betrieb/health-Endpunkt für App und Datenbank, strukturierte JSON-Logs mit Request-IDs
TestsUnit-Tests mit Jest, E2E-Tests mit Supertest gegen eine echte Testdatenbank
AuslieferungMehrstufiges Dockerfile, docker compose für App und Postgres, GitHub Actions für Lint, Typecheck, Tests und Build

Ablauf einer Anfrage

  1. ClientHTTP
  2. GuardsJWT · Rollen · Throttle
  3. ValidationPipe
  4. Controller
  5. Services
  6. PostgreSQLPrisma
Fehler aus allen Schichten landen im globalen Exception-Filter, der ein einheitliches Antwortformat zurückgibt.

Entscheidungen im Detail

Die Konfiguration wird beim Start geprüft. Fehlt ein Secret, startet die App gar nicht erst, statt später in Produktion merkwürdige Fehler zu werfen.

Access-Tokens sind kurzlebig. Refresh-Tokens werden rotiert und beim Logout ungültig gemacht. Das ist schnell erklärt, aber sorgfältig umzusetzen.

Die E2E-Tests laufen gegen eine separate, echte Datenbank statt gegen Mocks, weil Mocks Probleme bei Constraints und Transaktionen verdecken.

Der Starter liefert auch den Login für AgentDesk. Der Einsatz in einem zweiten Projekt hat gezeigt, welche Stellen wirklich konfigurierbar sein müssen.