ChatJS: ein Monorepo als Startpunkt für eigene KI-Chat-Oberflächen

Welches Problem ChatJS adressiert

Die README beginnt mit dem Satz, man solle aufhören, dieselbe KI-Chat-Infrastruktur immer wieder neu zu bauen. Das beschreibt die Zielgruppe recht genau: Entwickler, die bereits wissen, wie ein Chat mit Streaming funktioniert, und denen es nicht darum geht, diese Mechanik erneut zu schreiben. Adressiert werden Teams, die eine eigene Oberfläche brauchen, aber Auth, Modellauswahl, Anhänge, Gesprächsverzweigungen und das Teilen von Unterhaltungen nicht von Grund auf entwerfen wollen. Der Umfang der Feature-Liste macht deutlich, dass es hier nicht um eine Demo geht. Genannt werden unter anderem 120+ Modelle über ein Gateway, GitHub-, Google- und anonymer Login, Anhänge in Form von Bildern, PDFs und Dokumenten, fortsetzbare Streams nach einem Seiten-Reload, Branching, öffentliche Freigabelinks, Websuche, Bildgenerierung, Code-Ausführung in einer Sandbox sowie MCP-Unterstützung. Hinzu kommt die Option, die Anwendung per Electron als Desktop-Build für macOS, Windows und Linux zu verpacken. Wer nur einen einzelnen Assistenten in ein bestehendes Produkt einbetten möchte, ist damit überversorgt. Wer dagegen ein eigenständiges Chat-Produkt plant, findet hier eine Ausgangsbasis, die viele Entscheidungen bereits getroffen hat.

Monorepo-Aufteilung und der Weg vom Scaffold zur laufenden App

Das Repository ist als Monorepo organisiert. Die README nennt vier Bestandteile: apps/site für die Landingpage unter chatjs.dev, apps/chat für die eigentliche Next.js-Anwendung unter demo.chatjs.dev, apps/docs für die Dokumentation und packages/cli für das interaktive Scaffold-Werkzeug. Der Einstieg läuft über die Kommandozeile. Der dokumentierte Befehl lautet npx @chat-js/cli@latest create my-app. Laut README führt das CLI durch Fragen zu Gateway, Features und Auth-Auswahl, erzeugt anschließend eine Datei chat.config.ts und listet die Umgebungsvariablen auf, die für die gewählten Optionen benötigt werden. Das ist der zentrale Mechanismus: Die Entscheidungen werden nicht im Code verstreut getroffen, sondern in einer Konfigurationsdatei gebündelt und daraus abgeleitet. Wer die App später umstellt, ändert die Konfiguration und nicht die Provider-Aufrufe im Anwendungscode. Für die lokale Entwicklung nennt die README mehrere Skripte: bun dev startet die Chat-App, bun dev:docs die Dokumentation, bun lint den Lint-Lauf über den Workspace und bun test:types die Typprüfung der Chat-App. Bemerkenswert ist der Umgang mit Ports. Über die Variable CHATJS_DEV_SLOT in .env.worktree.local lässt sich laut README ein stabiler Bereich von zehn Ports pro Worktree reservieren. Innerhalb dieses Bereichs verwendet die Chat-App den Offset 0, Electron den Offset 1 und die Site den Offset 2, konfiguriert in .worktree-env.json. Die README weist ausdrücklich darauf hin, bun dev:info zu verwenden, statt einen Port anzunehmen. Diese Datei ist von Git ignoriert und wird getrennt von der Vercel-verwalteten .env.local gehalten. Wer parallel an mehreren Arbeitskopien arbeitet, bekommt damit kollisionsfreie Ports, muss aber die zusätzliche Konfigurationsdatei mitpflegen.

Der Stack bestimmt, welche Betriebskosten entstehen

Die Stack-Liste ist lang und in Teilen bindend. Als Fundament dient Next.js mit App Router und React Server Components, geschrieben in TypeScript. Die Modellanbindung läuft über das AI SDK und das AI Gateway von Vercel, das laut README den einheitlichen Zugang zu den 120+ Modellen von Claude, GPT, Gemini und Grok herstellt. Für Authentifizierung und Autorisierung ist Better Auth eingetragen. Datenbankzugriffe laufen über Drizzle ORM gegen PostgreSQL. Redis wird für Caching und für die fortsetzbaren Streams verwendet. Blob-Speicher kommt von Vercel Blob. Darüber hinaus listet die README tRPC für typsichere APIs, Zod für Schemavalidierung, Zustand für Zustandsverwaltung, Motion für Animationen, t3-env für Umgebungsvariablen, Pino für strukturiertes Logging, Langfuse für LLM-Observability, Vercel Analytics, Biome mit dem Ultracite-Preset für Linting und Formatierung, Streamdown für Markdown während des Streamings sowie AI Elements und AI SDK Tools. Diese Aufzählung ist keine Empfehlungsliste, sondern eine Abhängigkeitserklärung. Wer ChatJS übernimmt, übernimmt auch die Betriebsanforderung an Postgres, Redis und Blob-Storage. Genau dort liegt die eigentliche Einstiegshürde, nicht im Frontend.

Resumable Streams: das Feature mit den höchsten Infrastrukturkosten

Unter den Funktionen sticht eine hervor, weil sie die Architektur stärker prägt als alle anderen: fortsetzbare Streams, die eine laufende Generierung nach einem Seiten-Refresh weiterführen. Die README ordnet Redis ausdrücklich dem Caching und den resumable Streams zu. Daraus folgt, dass der generierte Text nicht nur an den Browser gestreamt, sondern serverseitig zwischengespeichert wird, damit ein erneut verbundener Client den bereits erzeugten Teil abrufen kann. Das ist ein anderer Entwurf als ein reiner Weiterleitungsstream, bei dem ein Verbindungsabbruch den Kontext der laufenden Antwort beendet. Der Preis dafür ist eine zustandsbehaftete Komponente mehr im Pfad jeder Anfrage. Fällt Redis aus, ist nicht nur der Cache weg, sondern auch das Verhalten nach einem Reload. Wer diesen Aufwand scheut, muss prüfen, ob das Feature in der eigenen Zielgruppe überhaupt gebraucht wird, denn es lässt sich nicht ohne Weiteres abschalten, ohne die Stream-Logik anzufassen.

Grenzen, die die README offenlegt

Die Materiallage ist an mehreren Stellen dünn. Die README beschreibt Features in Stichpunkten, aber nicht das Datenmodell, nicht die Tabellenstruktur hinter Drizzle und nicht die Frage, wie Gesprächsverzweigungen oder Freigabelinks in der Datenbank abgebildet werden. Wer abschätzen will, wie aufwendig eine Migration auf ein eigenes Schema wird, findet in der README keine Grundlage. Auch zur Code-Ausführung in einer Sandbox steht nur der Feature-Name. Ob die Ausführung lokal, in einem Container oder bei einem externen Dienst stattfindet, geht aus dem Material nicht hervor. Das ist relevant, weil eine Sandbox mit Zugriff auf das eigene Netzwerk ein Sicherheitsproblem wäre. Eine weitere Einschränkung ergibt sich aus der Gateway-Bindung: Die 120+ Modelle kommen laut README über das AI Gateway von Vercel. Wer Modelle über einen eigenen Endpunkt oder einen anderen Broker ansprechen will, muss an dieser Stelle eingreifen. Und die Desktop-Variante ist nicht kostenlos zu haben: Electron als zweite Auslieferungsform bedeutet zusätzliche Build- und Signaturschritte für drei Plattformen. Die README nennt zwar die Veröffentlichung von Installern über GitHub Releases, beschreibt aber nicht, wie die Signierung organisiert ist.

Wartung, Releases und Lizenz

Die Release-Praxis ist im Repository konkret beschrieben. Releases laufen über Changesets für das gesamte Repository. Der Ablauf laut README: für jedes veröffentlichbare Paket, das geändert wurde, einen Changeset hinzufügen, den generierten Versions-Pull-Request aus dem Changesets-Workflow mergen, öffentliche Pakete wie @chat-js/cli werden auf npm publiziert, Desktop-Installer für @chat-js/electron landen in den GitHub Releases. Die veröffentlichten Versionen von @chat-js/cli zeigen den Takt: 0.6.5 im Mai, 0.7.0 im Juli, 0.8.0 im September. Ein Abstand von rund zwei Monaten zwischen den Minor-Versionen. Wer das CLI als Teil seiner Toolchain einsetzt, muss also damit rechnen, dass sich die generierte chat.config.ts zwischen zwei Minor-Versionen ändern kann. Vor einem Upgrade lohnt ein Blick in die Änderungen, die der jeweilige Changeset beschreibt, bevor die Konfiguration neu erzeugt wird. Zur Lizenz: ChatJS steht unter Apache-2.0. Das erlaubt kommerzielle Nutzung und Modifikation, verlangt aber, dass Lizenz- und Urheberrechtshinweise erhalten bleiben und Änderungen an Dateien kenntlich gemacht werden. Wer das Projekt als Grundlage eines eigenen Produkts verwendet, sollte die beigelegte NOTICE-Datei prüfen. Das ist keine Rechtsberatung, sondern ein Hinweis auf die Stellen, an denen die Lizenz Pflichten auslöst.

Wo eine schlankere Alternative besser passt

Der naheliegende Vergleich ist ein direkter Aufbau auf dem AI SDK ohne das umgebende Gerüst. ChatJS nutzt das AI SDK ohnehin als Modellschicht. Der Unterschied liegt nicht in der Modellanbindung, sondern in allem, was darum herum gebaut wurde: Authentifizierung, Datenbank, Redis, Blob-Storage, Routing über tRPC, Freigabelogik. Ein eigener Aufbau auf dem AI SDK bedeutet, diese Teile selbst zu wählen, und das kann heißen, dass nur eine Route und ein In-Memory-Verlauf entstehen, ohne Postgres und ohne Redis. Der Preis ist, dass Verzweigungen, Freigabelinks und fortsetzbare Streams dann ebenfalls selbst zu implementieren sind. Die Entscheidung hängt also nicht daran, welches Modell man anspricht, sondern daran, wie viele der Randfunktionen man tatsächlich braucht. Für ein internes Werkzeug mit einem einzigen Assistenten ist der eigene Aufbau deutlich kürzer. Für ein Produkt mit Konten, Verlauf und teilbaren Unterhaltungen verschiebt sich das Verhältnis zugunsten des fertigen Gerüsts, weil die Randfunktionen genau die Teile sind, die erfahrungsgemäß am längsten dauern.

Redaktionelles Fazit

ChatJS passt zu Teams, die eine bestehende Chat-Oberfläche erweitern wollen und Postgres, Redis sowie Vercel Blob ohnehin betreiben oder bereit sind, sie zu betreiben. Wer lediglich einen Chat-Endpunkt in eine bestehende Anwendung einhängen will, sollte zuerst prüfen, ob ein direkter Aufruf des AI SDK nicht ausreicht, denn ChatJS bringt Datenbank, Redis, Blob-Storage und Auth als feste Bestandteile mit. Vor der Übernahme lohnt der Blick in chat.config.ts und in die vom CLI aufgelisteten Umgebungsvariablen, weil diese Dateien festlegen, welche Provider, Features und Auth-Wege tatsächlich aktiv sind.

Offizielle Quellen

1. FranciscoMoretti/chat-js on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases