Was ist NestJS?
NestJS gibt Backends in TypeScript eine feste Ordnung: Jedes Projekt ist gleich aufgebaut, und neue Entwickler finden sich schnell zurecht. Was dahinter steckt und wann sich das lohnt, verständlich erklärt.
- Lesezeit
- 8 Minuten
- Autor
- Samet Akin
- Veröffentlicht
- Kategorie
- Technik erklärt
Was ist NestJS?
Wer mit Node.js einen Server baut, bekommt viel Freiheit und wenig Vorgaben. Wo liegt die Anmeldelogik, wie werden Eingaben geprüft, wie hängen die Teile zusammen? Jedes Team beantwortet das anders, und nach drei Jahren erkennt niemand mehr das Muster. NestJS ist die Antwort auf genau dieses Problem: ein Framework, das diese Entscheidungen einmal trifft und für alle Projekte gleich beantwortet.
Die Ordnung besteht aus drei Bausteinen. Module fassen einen Fachbereich zusammen, etwa alles rund um Rechnungen. Controller nehmen Anfragen von außen entgegen und geben Antworten zurück. Services enthalten die eigentliche Logik, etwa das Berechnen oder Speichern. Dazu kommt ein Mechanismus namens Dependency Injection: Bausteine fordern an, was sie brauchen, und das Framework setzt es ein, statt dass jemand alles von Hand verdrahtet. In Code sieht ein Controller so aus:
Geschrieben wird NestJS in TypeScript. Das ist kein Detail, sondern der halbe Nutzen: Die Typen beschreiben an jeder Stelle, welche Daten fließen, und wenn die Oberfläche ebenfalls in TypeScript entsteht, teilen sich Frontend und Backend dieselben Datenmodelle. Ein geändertes Feld fällt dann auf beiden Seiten sofort auf.
@Controller("rechnungen")
export class RechnungenController {
constructor(private readonly dienst: RechnungenDienst) {}
@Get(":nummer")
eine(@Param("nummer") nummer: string) {
return this.dienst.finde(nummer);
}
}
// Die Anfrage GET /rechnungen/2026-101 landet
// automatisch in dieser MethodeWie funktioniert NestJS?
Unter der Haube ist NestJS eine Schicht über Node.js. Die Anfragen nimmt weiterhin ein bewährter HTTP-Unterbau entgegen, standardmäßig Express. NestJS sortiert darüber, was mit jeder Anfrage passiert: Zuerst prüfen sogenannte Guards, ob der Aufrufer angemeldet ist und die nötige Rolle hat. Dann validieren Pipes die Eingaben gegen die Typen. Erst danach erreicht die Anfrage den Controller, der sie an den passenden Service weitergibt. Jeder dieser Schritte hat seinen festen Platz.
Das Praktische daran: Querschnittsthemen werden einmal gelöst statt hundertmal. Wer festlegt, dass nur die Zentrale alle Fahrzeuge sehen darf und ein Fahrer nur seine eigenen, schreibt diese Regel an eine Stelle, und jede neue Schnittstelle erbt sie automatisch. In einem frei strukturierten Projekt liegt dieselbe Regel schnell in zwanzig Abfragen verstreut, und die einundzwanzigste vergisst sie.
Dazu kommt eine ungewöhnlich vollständige Ausstattung. Anmeldung, Rechteprüfung, Validierung, geplante Aufgaben, Warteschlangen und die Anbindung von Datenbanken gibt es als offizielle Bausteine mit Dokumentation. Aus dem Code erzeugt NestJS außerdem eine OpenAPI-Beschreibung der Schnittstelle, also ein maschinenlesbares Verzeichnis aller Endpunkte, das nicht veralten kann, weil es bei jedem Build neu entsteht.
Wozu wird NestJS verwendet?
NestJS ist ein reines Backend-Framework. Es erzeugt keine Oberflächen, sondern die Dienste dahinter, an denen Weboberflächen, Apps und fremde Systeme hängen. Typische Einsatzgebiete sind:
- Schnittstellen im REST- oder GraphQL-Stil, über die Oberflächen und Partner Daten austauschen
- Backends für Kundenportale mit Rollen, Rechten und mehreren angebundenen Systemen
- Zentrale Dienste, an denen gleichzeitig eine Weboberfläche, eine App und ein Partnersystem hängen
- Hintergrundverarbeitung mit Warteschlangen, etwa Rechnungsläufe oder Mailversand
- Echtzeit-Funktionen wie Benachrichtigungen über WebSockets
Wir setzen NestJS ein, wenn ein Backend mehr ist als eine Handvoll Endpunkte: sobald Rollen, Rechte und mehrere Verbraucher dazukommen. Die Schnittstellen schreiben wir dann mit denselben Typen wie die Oberfläche, sodass beide Seiten nachweisbar zusammenpassen. Für einen kleinen Dienst, der eine Datei entgegennimmt und ablegt, wäre das Gerüst dagegen übertrieben, dort greifen wir zu leichteren Mitteln.
Die Geschichte von NestJS
NestJS ist das jüngste der großen Backend-Frameworks und hat einen ungewöhnlichen Ursprung: Es begann als Projekt eines einzelnen Entwicklers. Der Pole Kamil Mysliwiec veröffentlichte es 2017, weil ihm in der Node-Welt genau das fehlte, was Java mit Spring und PHP mit Symfony längst hatten: ein Framework mit klarer Architektur. Die Struktur lehnte er bewusst an Angular an, damit sich Entwickler aus der Frontend-Welt sofort zurechtfinden. Die Idee traf einen Nerv, heute gehört NestJS zu den meistgenutzten Backend-Frameworks für Node.js.
- Erschienen
- 2017
- Entwickelt von
- Kamil Mysliwiec und Gemeinschaft
- Sprache
- TypeScript, läuft auf Node.js
- Lizenz
- Quelloffen und kostenlos (MIT)
- Vorbilder
- Angular, Spring, Symfony
Vom Soloprojekt zum Backend-Standard
Die erste Version
Kamil Mysliwiec veröffentlicht NestJS als Einzelprojekt. Die Mischung aus TypeScript und Angular-Struktur spricht sofort Entwickler an, die beides schon kennen.
2017
Die Grenzen von NestJS
Die feste Ordnung von NestJS ist eine Stärke mit Preisschild. Ehrlicherweise gehören diese Punkte dazu:
- Für kleine Dienste ist das Gerüst zu schwer: drei Endpunkte brauchen in NestJS mehr Dateien als der ganze Dienst in purem Express
- Die Einarbeitung dauert: Wer Dependency Injection und Dekoratoren nicht kennt, braucht ein paar Wochen, bis sich das Framework natürlich anfühlt
- Es erzeugt keine Oberfläche: Für alles Sichtbare braucht es zusätzlich ein Frontend, etwa mit React oder Next.js
- Es erbt die Grenzen von Node.js: lange Berechnungen am Stück blockieren den Dienst und gehören ausgelagert
Wer diese Punkte kennt, kann sauber entscheiden. NestJS lohnt sich dort, wo ein Backend wächst und lange lebt, nicht dort, wo ein Wochenendprojekt schnell fertig werden soll.
NestJS oder Express?
Express ist das älteste und bekannteste Web-Framework für Node.js, und die Frage NestJS oder Express ist eigentlich eine Frage nach der Projektgröße. Express gibt fast nichts vor: ein paar Zeilen, und der Server antwortet. NestJS gibt fast alles vor: Struktur, Prüfung, Zuständigkeiten. Als Faustregeln:
- Express passt für kleine Dienste mit wenigen Endpunkten, die eine Person überblickt
- NestJS passt, sobald Rollen, Rechte, Validierung und mehrere angebundene Systeme dazukommen
- Express lässt jedem Team die eigene Struktur, NestJS macht Projekte zwischen Teams austauschbar
- Ein Widerspruch ist es nicht: NestJS nutzt Express standardmäßig als Unterbau
Der letzte Punkt überrascht viele: Wer NestJS einsetzt, setzt meist auch Express ein, nur eben mit einer Ordnung darüber. Die Entscheidung lautet also nicht Entweder-oder, sondern: Reicht die Freiheit von Express, oder braucht das Projekt die Struktur? Unsere Einschätzung dazu steht auch auf der Seite zur NestJS-Entwicklung.
NestJS aus Kundensicht
Für Auftraggeber ist die feste Struktur bares Geld, nur zeitversetzt. Ein NestJS-Backend sieht bei jedem Dienstleister ähnlich aus, weil das Framework den Aufbau vorgibt. Wechselt das Team oder die Agentur, findet sich der Nachfolger in Tagen statt Wochen zurecht. Dazu kommt die erzeugte Schnittstellenbeschreibung: Ein anderer Dienstleister kann eure Schnittstelle nutzen, ohne den Vorgänger zu fragen. Beides senkt genau die Abhängigkeit, die bei Individualsoftware am meisten kostet.
Auf der Kostenseite steht ein etwas höherer Start. Das Gerüst will aufgesetzt sein, und die ersten Endpunkte dauern länger als in einem frei strukturierten Projekt. Diese Investition holt ein Backend über die Jahre mehrfach wieder herein, über günstigere Erweiterungen und weniger Fehler. Bei einem Dienst, der nach sechs Monaten wieder abgeschaltet wird, holt sie sich nicht zurück, und dann sagen wir das auch.
Ist NestJS die Zukunft?
Für Backends in TypeScript ist NestJS heute die Standardantwort, und daran wird sich so schnell nichts ändern. Das Framework wird aktiv weiterentwickelt, hat eine große Community und ein Geschäftsmodell aus Kursen und Beratung, das die Pflege finanziert. Die Ideen dahinter, feste Module, eingesetzte Abhängigkeiten, Prüfung vor der Logik, sind zudem Jahrzehnte alt und in Java und PHP längst bewährt. NestJS hat sie nur in die Node-Welt geholt.
Sicher ist auch: NestJS bleibt eine Wahl unter mehreren. Wer PHP-Infrastruktur betreibt, fährt mit Laravel oft besser, und für sehr kleine Dienste bleibt Express die einfachere Antwort. Die Entscheidung hängt am Projekt, nicht an der Mode, und genau so beraten wir sie.
Was NestJS stark macht
Ordnung mit System
Module, Controller, Services: Jedes NestJS-Projekt ist gleich aufgebaut. Wer eines kennt, findet sich in allen zurecht.
Typen bis zum Rand
TypeScript beschreibt jede Schnittstelle. Frontend und Backend teilen sich die Datenmodelle und passen nachweisbar zusammen.
Rechte an einer Stelle
Wer was sehen darf, steht einmal im Code statt verstreut in Abfragen. Jede neue Schnittstelle erbt die Regeln automatisch.
Dokumentation aus Code
Die Schnittstellenbeschreibung entsteht bei jedem Build neu. Sie kann nicht veralten und macht euch unabhängig vom Entwickler.
Was wir mit NestJS bauen
NestJS ist unser Werkzeug für Backends, die lange leben und an denen mehr als eine Oberfläche hängt.
Webanwendungen
Portale und Fachanwendungen mit Rollen, Rechten und Auswertungen, sauber getrennt in Backend und Oberfläche.
Apps
Mobile Apps brauchen ein Backend, das Daten liefert und Rechte prüft. NestJS stellt es bereit, dokumentiert und typisiert.
IT-Sicherheit
Anmeldung, Zwei-Faktor-Schutz und Rechteprüfung liegen im Backend an einer Stelle und lassen sich dort prüfen und testen.
