Auch im Frontend zahlt sich Architektur aus: Vue 3 mit TypeScript

Warum gewachsener Code irgendwann bremst Warum eine Komponente nicht auch die API kennen sollte

Ruft eine Komponente die API direkt auf, verknüpft sie zwei Dinge, die eigentlich nichts miteinander zu tun haben: wie Daten dargestellt werden, und woher sie kommen. Ändert sich der Endpunkt, das Antwortformat oder die Authentifizierung, muss das in jeder Komponente angepasst werden, die diese Daten braucht. Nutzen mehrere Komponenten denselben Zustand, verwaltet ausserdem jede ihre eigene Kopie von Ladezustand, Fehlerbehandlung und Daten.

Bei Batix zeigt sich der Effekt einer klaren Trennung am deutlichsten, sobald eine Anwendung wächst. Debuggen und Erweitern sind bei sauber getrennten Schichten spürbar effizienter, als wenn Anzeige- und Datenlogik über viele Komponenten verstreut sind. Ein zusätzlicher Vorteil zeigt sich beim Testen: Lässt sich eine Komponente nicht von der API lösen, muss jeder Test die Netzwerkschicht mitsimulieren. Mit einem eigenen Controller lässt sich der Store isoliert testen, indem lediglich der Controller gemockt wird.

Component, Store, Controller, Model: die Rollen im Detail

Die Component nimmt Nutzereingaben entgegen und zeigt Daten an, ähnlich wie der Controller im Backend Anfragen entgegennimmt. Der Store hält den Zustand und die Geschäftslogik, in der Rolle des Service. Der Controller im Frontend kapselt die eigentlichen API-Aufrufe, vergleichbar mit dem Repository, das im Backend die Datenbank kapselt. Das Model ist ein TypeScript-Interface, das exakt abbildet, was an die API gesendet oder aus ihr empfangen wird, in der Rolle des DTOs.

Ein Beispiel: Ein Formular zum Anlegen eines Kurses ruft im Store eine Methode wie createCourse auf. Der Store prüft, was inhaltlich nötig ist, und übergibt die Daten an den Controller. Der Controller baut daraus ein CourseRequest-Model, schickt es an die API und wandelt die Antwort in ein Course-Model zurück, bevor der Store seinen Zustand aktualisiert. Die Component selbst sieht von alledem nur den fertigen Zustand im Store.

Ohne diese Trennung landen API-Antworten im Code oft als any oder als lose typisiertes Objekt, TypeScript kann dann nicht mehr prüfen, ob ein Feld tatsächlich existiert. Mit einem eigenen Model-Typ pro Endpunkt meldet der Compiler dagegen sofort, wenn sich das Antwortformat ändert oder ein erwartetes Feld fehlt.

Warum sich das bei wachsender Software auszahlt

Der Mehraufwand fällt zu Beginn auf: mehr Files, mehr Typisierung, mehr Zwischenschritte für denselben API-Aufruf. Bei einer kleinen Anwendung mit wenigen Komponenten ist das kaum zu rechtfertigen. Sobald eine Anwendung über mehrere Module und viele Komponenten wächst, kehrt sich das Verhältnis um: Eine Änderung an einem Endpunkt betrifft nur noch den Controller und das betroffene Model, nicht jede Komponente, die die Daten anzeigt.

Der Effekt zeigt sich auch im Team: Während die eine Person an der Darstellung einer Komponente arbeitet, kann eine andere Person parallel den Controller für einen neuen Endpunkt ergänzen, ohne dass sich beide Änderungen gegenseitig in die Quere kommen.

Sascha, der das Muster bei Batix auch im Frontend eingeführt hat:

«Debuggen und Erweitern sind bei einer grossen Software mit sauber getrennten Schichten spürbar effizienter, als wenn API-Logik und Zustand über viele Komponenten verstreut sind.»

Warum gewachsener Code irgendwann bremst Wo die Analogie zum Backend nicht ganz passt

Eine Einschränkung bleibt: Ein Store ist kein reiner Service wie im Backend, sondern reaktiver Zustand. Ändert sich ein Wert im Store, aktualisiert Vue automatisch jede Komponente, die ihn verwendet. Diese Reaktivität ist im Frontend ausdrücklich gewünscht, sie unterscheidet den Store aber von einem zustandslosen Backend-Service, der bei jedem Aufruf neu ausgeführt wird.

Wer die Analogie zu wörtlich nimmt, versucht unnötig, Reaktivität aus dem Store herauszuhalten, obwohl sie genau der Grund ist, warum der Store überhaupt existiert. Die Rollenaufteilung stimmt, die technischen Eigenschaften der einzelnen Bausteine bleiben trotzdem framework-spezifisch.

Für Logik, die keinen geteilten Zustand braucht, bietet sich statt eines Stores oft ein Composable an, eine wiederverwendbare Funktion mit eigenem, lokalem Zustand. Die Rollenaufteilung zwischen Controller und Model bleibt dabei gleich, nur die Service-Rolle wandert vom Store in das Composable.

Fazit

Das Prinzip lässt sich auf jedes komponentenbasierte Frontend übertragen, unabhängig vom gewählten Framework: Darstellung, Zustand und Datenzugriff gehören in getrennte Bausteine, verbunden über klar typisierte Schnittstellen. Bei Batix ist das mit Vue 3 und TypeScript inzwischen Standard für neue Frontend-Projekte, und die Erfahrung aus dem Backend fliesst dabei direkt in die Frontend-Architektur mit ein.

 

Häufig gestellte Fragen 

Was übernimmt der Store in dieser Architektur?

Der Store übernimmt die Rolle des Service: Er hält Zustand und Geschäftslogik und delegiert den eigentlichen Datenzugriff an den Controller. Komponenten lesen und verändern Daten ausschliesslich über den Store, nie direkt über die API.

Was macht der Controller im Frontend?

Er kapselt die API-Aufrufe, vergleichbar mit dem Repository im Backend. Anfragen und Antworten laufen dabei über typisierte Models, sodass der Rest der Anwendung nichts von den Details der Schnittstelle wissen muss.

Was macht der Controller im Frontend? Wozu dienen die TypeScript-Models?

Sie bilden ab, was an die API gesendet oder von ihr empfangen wird, in der Rolle des DTOs im Backend. Der Compiler prüft dadurch schon beim Schreiben des Codes, ob eine Anfrage oder Antwort zur erwarteten Struktur passt, statt den Fehler erst zur Laufzeit im Browser sichtbar zu machen.

Lohnt sich das auch für kleine Vue-Projekte?

Bei sehr kleinem Umfang steht der Mehraufwand an zusätzlichen Files und Typisierung oft in keinem guten Verhältnis zum Nutzen. Sobald ein Projekt über mehrere Module, mehrere Personen im Team und einen längeren Zeitraum wächst, zahlt sich die Trennung aus.

Ist ein Store dasselbe wie ein Backend-Service?

ANTWORT 5

Nicht ganz: Ein Store ist reaktiver Zustand, ein Backend-Service meist zustandslos. Die Aufgabentrennung, die beide Muster verfolgen, bleibt aber dieselbe.