ExetJS im Praxistest: Wie viel Framework braucht ein Express-Backend wirklich?
Wer regelmäßig Backends mit Express und TypeScript entwickelt, kennt den eigentlichen Vorteil von Express sehr gut: Das Framework schreibt vergleichsweise wenig vor. Routing, Middleware, Projektstruktur und viele Architekturentscheidungen bleiben unter der Kontrolle des Entwicklers. Genau diese Freiheit kann jedoch mit zunehmender Projektgröße zu einer anderen Frage führen: Wie oft möchte man dieselben technischen Grundlagen neu strukturieren, bevor aus Flexibilität unnötige Wiederholungsarbeit wird?
An diesem Punkt setzt ExetJS an. Das von WebDigiTech entwickelte Toolkit versteht sich nicht als Ersatz für Express und versucht auch nicht, dessen Arbeitsweise hinter einer neuen Abstraktionsschicht zu verstecken. Stattdessen ergänzt es Express und TypeScript um eine definierte Projektstruktur, ein klares Modulmodell und eine CLI, die wiederkehrende Aufgaben übernimmt. Nach unserer Arbeit mit dem aktuellen Produktstand zeigt sich schnell, dass genau diese Zurückhaltung der interessanteste Teil von ExetJS ist.
Ein Express-Projekt, das weiterhin wie Express aussieht
Der erste Eindruck nach der Initialisierung eines Projekts ist angenehm unspektakulär. Es entsteht kein Konstrukt, bei dem man zunächst eine eigene Framework-Sprache lernen muss. Die generierte Anwendung trennt Konfiguration, Middleware, Module und gemeinsame Hilfsfunktionen voneinander, besitzt von Beginn an einen Health Endpoint und arbeitet mit einer zentralen Konfiguration über exet.config.ts.
Dabei bleibt der eigentliche Express-Unterbau sichtbar. Ein ExetJS-Modul besitzt einen Namen, einen Base Path und eine explizite Registrierungsfunktion, die einen Express Router bereitstellt. Es gibt keine automatische Suche nach Modulen im Dateisystem und keine versteckte Registrierung aufgrund bestimmter Dateinamen oder Decorators. Wer ein Modul zur Anwendung hinzufügt, sieht deshalb auch, dass es hinzugefügt wurde.
Das wirkt zunächst wie ein kleines Detail, ist architektonisch aber eine klare Entscheidung. ExetJS versucht nicht, möglichst viel Code vor dem Entwickler zu verbergen. Es versucht vielmehr, die Stellen zu standardisieren, an denen in vielen Express-Projekten irgendwann eigene Konventionen entstehen.
Die CLI ist mehr als ein Projektgenerator
Der zweite Teil des Produkts ist die ExetJS CLI. Mit exet init entsteht ein neues Projekt, exet start übernimmt den vorgesehenen Entwicklungsstart, exet list zeigt verfügbare Module, exet install ergänzt das Projekt und exet doctor überprüft dessen grundlegenden Zustand.
Möchten Sie sehen, wie ExetJS diesen Workflow tatsächlich aufbaut?
Die Dokumentation zeigt Core, CLI, Modulstruktur und den Einstieg in ein eigenes Projekt direkt am konkreten Aufbau. So lässt sich der Ansatz besser beurteilen als über eine reine Feature-Liste.
Gerade diese Kombination macht den Unterschied zu einem einfachen Starter-Repository. Ein Starter hilft beim ersten Tag eines Projekts und verliert danach schnell an Bedeutung. Eine CLI kann dagegen während der weiteren Entwicklung Bestandteil des Workflows bleiben. ExetJS nutzt diesen Ansatz, ohne daraus ein überladenes Kommandozentrum zu machen.
Interessant ist auch, wie installierbare Module behandelt werden. Sie verschwinden nicht als undurchsichtige Funktion innerhalb eines großen Framework-Pakets, sondern ihre Struktur wird Bestandteil des eigenen Projekts. Der Entwickler kann sehen, was installiert wurde, und besitzt weiterhin Zugriff auf die konkrete Implementierung. Das passt konsequent zur Grundidee des Produkts: Struktur anbieten, aber Kontrolle nicht wegnehmen.
Auth als Ausgangspunkt, nicht als fertige Identitätsplattform
Ein gutes Beispiel dafür ist das Auth-Modul. ExetJS liefert hier bewusst keine komplette Identity-Plattform, die vorgibt, wie Benutzer, Rollen, Sessions und jede denkbare Zugriffskontrolle aufgebaut sein müssen. Stattdessen gibt es einen strukturierten Ausgangspunkt mit den typischen Bereichen für Routes, Controller, Service, Repository, Schema und Security-Helfer.
Besonders wichtig ist die Repository-Grenze. Die Authentifizierung ist nicht fest an eine bestimmte Datenbank gekoppelt. Ein eigenes AuthRepository kann die Persistenz übernehmen, während die restliche Auth-Struktur bestehen bleibt. Damit löst ExetJS eine häufige Grundaufgabe, ohne gleichzeitig eine Entscheidung über das Datenmodell des gesamten Projekts zu erzwingen.
Genau hier zeigt sich allerdings auch eine Grenze, die bei einem Review nicht verschwiegen werden sollte: Wer eine vollständig fertige Benutzerverwaltung mit Rollenmodell, Passwort-Reset, E-Mail-Verifikation, OAuth, Administration und komplexem Session Management erwartet, bekommt diese nicht automatisch. Das Auth-Modul ist eine Grundlage, auf der eine projektspezifische Lösung aufgebaut werden kann.
Datenbankmodule ohne universelle Datenbankschicht
Ähnlich konsequent ist der Ansatz bei Datenbanken. Der aktuelle dokumentierte Stand umfasst eigenständige Module für MongoDB, PostgreSQL, MySQL, MariaDB und SQLite. Dabei wird nicht versucht, sämtliche Datenbanken hinter einer eigenen universellen ExetJS-Abfragesprache zu verstecken. Jedes Modul installiert nur den tatsächlich benötigten Treiber und stellt Verbindung, Konfiguration und Lifecycle des jeweiligen Systems bereit.
Das ist eine sinnvolle Grenze. ExetJS entscheidet damit nicht, ob ein Projekt ein ORM, einen Query Builder oder direkten Zugriff über den nativen Treiber verwenden soll. Diese Wahl bleibt beim Projekt. Das Toolkit kümmert sich stattdessen um den Teil, der sich sinnvoll vereinheitlichen lässt: Verbindung herstellen, Verfügbarkeit kontrollieren und Ressourcen sauber in den Lebenszyklus der Anwendung integrieren.
Gerade für kleine und mittlere Backend-Projekte wirkt dieser Ansatz pragmatisch. Ein PostgreSQL-Projekt muss keine MongoDB-Abhängigkeit mitführen, ein SQLite-Projekt benötigt keinen Netzwerk-Treiber, und die eigentliche Datenarchitektur bleibt unabhängig vom Framework.
Ein unterschätzter Punkt: der Lifecycle
Technisch interessanter wird ExetJS beim Umgang mit Ressourcen. Datenbanken und andere externe Ressourcen können Abhängigkeiten zwischen Modulen erzeugen. Ein Modul darf beispielsweise erst gestartet werden, wenn seine Datenbankverbindung verfügbar ist. Beim Herunterfahren sollte die Reihenfolge entsprechend umgekehrt funktionieren.
Der aktuelle Core berücksichtigt genau diesen Lebenszyklus. Ressourcen werden vor abhängigen Modulen gestartet, beim Shutdown kontrolliert in umgekehrter Reihenfolge geschlossen und auch bei Startfehlern wieder freigegeben. Der HTTP-Server kann laufende Requests beenden, bevor beispielsweise eine Datenbankverbindung geschlossen wird.
Das ist keine Funktion, die auf einer Landingpage besonders spektakulär aussieht. In einem echten Backend ist sie jedoch wesentlich relevanter als viele auffällige Komfortfunktionen. Sauberes Starten und Herunterfahren wird häufig erst dann interessant, wenn eine Anwendung produktiv betrieben wird und plötzlich mehrere Ressourcen voneinander abhängen.
Wo ExetJS bewusst weniger bietet
Die größte Stärke des Produkts kann je nach Erwartung gleichzeitig seine größte Einschränkung sein. ExetJS ist kein Framework, das möglichst viele technische Entscheidungen zentral übernimmt. Es gibt keinen schweren Dependency-Injection-Container, keine Decorator-basierte Anwendungsarchitektur, keine automatische Modul-Erkennung und keine eigene Datenbankschicht, die sämtliche Datenbanktechnologien vereinheitlichen möchte.
Wer genau diese umfassende Abstraktion sucht, wird mit einem größeren Framework wahrscheinlich schneller ans Ziel kommen. Wer hingegen Express bereits kennt und gerade dessen direkte Arbeitsweise behalten möchte, findet in ExetJS einen deutlich natürlicheren Übergang.
Auch die derzeitige Modulwelt ist noch überschaubar. Das Projekt steht am Anfang und besitzt naturgemäß nicht die jahrzehntelang gewachsene Infrastruktur etablierter Frameworks. Das sollte bei produktiven Projekten berücksichtigt werden. Dafür ist die vorhandene Architektur klein genug, um sie tatsächlich lesen und verstehen zu können.
Passt eine schlanke Backend-Architektur auch zu Ihrem nächsten Projekt?
Nicht jedes Backend benötigt denselben technischen Umfang. WebDigiTech entwickelt individuelle Webanwendungen und APIs auf Basis der Anforderungen des jeweiligen Projekts und kann gemeinsam mit Ihnen klären, welche Architektur dafür sinnvoll ist.
Wir prüfen die Anfrage und melden uns persönlich.
Unser Eindruck nach dem aktuellen Entwicklungsstand
ExetJS funktioniert am überzeugendsten, wenn man es nicht als Konkurrenz zu Express betrachtet. Express ist bereits die Grundlage. ExetJS beschäftigt sich vielmehr mit der Frage, was danach passiert: Wie strukturieren wir Module? Wie starten wir ein Projekt reproduzierbar? Wie ergänzen wir Authentifizierung oder eine Datenbank, ohne das gesamte Backend neu zu organisieren? Und wie behalten wir trotzdem die Kontrolle über den Code?
Gerade diese Positionierung macht das Projekt interessant. ExetJS möchte Entwicklern nicht möglichst viele Entscheidungen abnehmen. Es versucht, wiederkehrende technische Entscheidungen dort zu vereinheitlichen, wo daraus eine klarere Projektstruktur entsteht, und lässt den Rest bewusst offen.
Für Entwickler und kleinere Teams, die TypeScript und Express mögen, aber nicht jedes Backend wieder vollständig bei null strukturieren möchten, ist das eine nachvollziehbare Richtung. Wer dagegen ein Framework sucht, das Architektur, Datenzugriff, Authentifizierung und Anwendungslogik möglichst vollständig vorgibt, gehört wahrscheinlich nicht zur eigentlichen Zielgruppe.
ExetJS ist damit noch kein Werkzeug für jede denkbare Backend-Anwendung. Das muss es aber auch nicht sein. Sein interessanter Ansatz liegt gerade darin, klein zu bleiben und trotzdem an den Stellen Struktur zu schaffen, an denen ein wachsendes Express-Projekt sie tatsächlich braucht.
Oder kürzer formuliert: Nicht Express ersetzen, sondern dafür sorgen, dass aus seiner Freiheit nicht jedes Mal dieselbe Architekturarbeit entsteht.