TypeORM

Fast jede App speichert Daten dauerhaft: Nutzernamen, Bestellungen, Nachrichten. Dafür gibt es Datenbanken, also Programme, die große Mengen an Daten geordnet ablegen und wiederfinden. Viele Datenbanken werden mit einer eigenen Abfragesprache namens SQL bedient, die mit dem restlichen Programmcode wenig gemeinsam hat. TypeORM ist ein Werkzeug, das diesen Bruch überbrückt. Es erlaubt Entwicklern, Daten im Code wie ganz normale Objekte zu behandeln, und erzeugt die passenden Datenbankbefehle selbst. Genutzt wird es in Projekten, die in JavaScript oder in dessen strengerer Variante TypeScript geschrieben sind.

Warum Entwickler nicht jede Abfrage von Hand schreiben wollen

Ohne ein solches Werkzeug muss man für jeden Datenzugriff SQL-Text von Hand formulieren. Das ist fehleranfällig, weil der Text erst beim Ausführen geprüft wird. Ein Tippfehler in einem Spaltennamen fällt dann womöglich erst beim Nutzer auf. TypeORM prüft solche Dinge schon während der Entwicklung, weil die Datenstruktur im Code beschrieben ist.

Dazu kommt die Arbeitsersparnis bei Routineaufgaben. Einen Datensatz anlegen, ändern, suchen oder löschen sind immer dieselben vier Muster. TypeORM liefert sie fertig mit, statt dass jedes Team sie neu baut. In einem mittelgroßen Projekt spart das hunderte Zeilen Code.

Ein weiterer Punkt ist die Austauschbarkeit der Datenbank. TypeORM spricht unter anderem mit PostgreSQL, MySQL und SQLite. Wechselt ein Projekt das System, bleibt ein großer Teil des Codes unverändert. Vollständig ist diese Unabhängigkeit allerdings nie, weil sich die Systeme in Details unterscheiden.

Von der Klasse zur Tabelle

Der Kern ist eine Zuordnung zwischen Code und Datenbank. Der Entwickler schreibt eine sogenannte Entity, also eine Beschreibung eines Datentyps wie „Benutzer“. Darin stehen die Felder: Name, E-Mail, Geburtsdatum. TypeORM macht daraus eine Tabelle, in der jedes Feld eine Spalte ist und jeder Benutzer eine Zeile.

Diese Zuordnung markiert man mit kurzen Anmerkungen im Code, den Dekoratoren. Sie stehen direkt über einem Feld und sagen etwa, dass es sich um den Primärschlüssel handelt. Ein Primärschlüssel ist die eindeutige Nummer, an der ein Datensatz erkannt wird. Auch Beziehungen werden so beschrieben: Ein Benutzer hat viele Bestellungen, eine Bestellung gehört zu einem Benutzer.

Beim Ausführen einer Abfrage baut TypeORM daraus den SQL-Befehl und schickt ihn an die Datenbank. Die Antwort verwandelt es zurück in Objekte. Dieses Hin-und-Her-Übersetzen gibt der ganzen Software-Gattung ihren Namen: Object-Relational Mapping, kurz ORM. Der Preis dafür ist ein gewisser Kontrollverlust. Bei komplizierten Abfragen erzeugt ein ORM manchmal langsameren SQL-Code als ein erfahrener Entwickler von Hand — deshalb erlaubt TypeORM auch, rohes SQL einzusetzen.

TypeORM in echten Projekten

Man begegnet dem Namen vor allem im Umfeld von Node.js, also JavaScript auf dem Server. Besonders häufig taucht TypeORM zusammen mit NestJS auf, einem verbreiteten Baukasten für Server-Anwendungen. Wer eine Stellenanzeige für Backend-Entwicklung liest, findet TypeORM dort regelmäßig neben Alternativen wie Prisma oder Sequelize.

Ein typisches Einsatzfeld ist die Software hinter einem Onlineshop oder einer Web-App. Auch bei KI-Produkten steckt so etwas im Hintergrund: Nutzerkonten, Abrechnungen und Gesprächsverläufe eines Chatbots liegen in einer ganz gewöhnlichen Datenbank. Das eigentliche Sprachmodell hat damit nichts zu tun, aber ohne diese Verwaltung gäbe es kein Produkt.

Ein verbreiteter Irrtum ist, TypeORM sei selbst eine Datenbank. Das ist es nicht. Es ist nur die Vermittlungsschicht dazwischen, vergleichbar mit einem Dolmetscher, der zwei Seiten verbindet, aber selbst nichts besitzt. Die Daten liegen weiterhin im Datenbanksystem, das man zusätzlich installieren und betreiben muss.