Eine skalierbare Frontend-Architektur ist das Fundament jeder erfolgreichen Anwendung. Es geht dabei jedoch nicht nur um den Code, sondern um das smarte Fundament aus Planung und Struktur, auf dem alles aufbaut. In diesem Beitrag zeigen wir euch wichtige Regeln, wie man Code strukturiert und wie man ihn wartbar macht, sodass er nicht nur heute funktioniert, sondern auch zukünftigen Anforderungen gewachsen ist.
Aber was bedeutet „Frontend-Architektur“ eigentlich?
Um das zu klären, werfen wir einen Blick auf die Definitionen von „Frontend“ und „Architektur“ — beides Begriffe, die wir im Duden finden:
- Frontend bezeichnet den Teil eines digitalen Systems, den Nutzer:innen direkt sehen und mit dem sie interagieren – die „grafische Oberfläche“.
- Architektur umfasst die Konstruktion und Struktur eines Aufbaus.
Betrachten wir Beides nun im Kontext der Softwareentwicklung, können wir sagen, dass Frontend-Architektur das logische Konstruieren, Strukturieren und Organisieren von Code, Ordnern und Ressourcen ist, mit dem Ziel ein für Nutzer:innen nahtloses Erlebnis zu schaffen.
Mit der Aufgabe sind Entwickler:innen jedoch nicht ganz allein gelassen – zur Unterstützung stehen eine Vielzahl von architektonischen Mustern bereit. Aber welche Muster eignen sich am besten für welche Projekte? Und wie setzt man sie effektiv ein?
Entwurfsmuster in der Frontend-Architektur
Entwurfsmuster sind bewährte Lösungsansätze für wiederkehrende Probleme bei der Softwareentwicklung, die eine strukturierte Vorlage zur effizienten Organisation von Code und Systemkomponenten bieten. Sie erleichtern die Skalierbarkeit, Wartbarkeit und die Erweiterbarkeit von Softwareprojekten durch vorgegebene Strukturen und Prinzipien.
Wir stellen zwei der beliebtesten Pattern vor: Model-View-Controller (MVC) und Model-View-ViewModel (MVVM).
Model-View-Controller (MVC)
MVC unterteilt Anwendungen in 3 miteinander verbundene Komponenten: das Modell, die Ansicht und den Controller. Dadurch soll eine klarere Struktur geschaffen werden, die das Entwickeln, Testen und Warten der Anwendung erleichtern soll.
- Model: Das Modell enthält die Daten und die Geschäftslogik der Anwendung. Es verwaltet die Daten, Regeln und Geschäftslogik, die definieren, wie Daten abgerufen, erstellt, aktualisiert und gelöscht werden. Das Modell ist für die direkte Interaktion mit der Datenbank zuständig und sorgt dafür, dass die Daten korrekt und konsistent bleiben.
- View: Die „View“ / „Ansicht“ ist die Benutzeroberfläche der Anwendung. Sie präsentiert das Modell dem Benutzer auf eine verständliche Weise und nimmt Benutzereingaben entgegen. Die Ansicht ist dafür verantwortlich, die vom Modell zur Verfügung gestellten Daten abzubilden und reagiert auf Anweisungen des Controllers, um sich selbst zu aktualisieren.
- Controller: Der Controller fungiert als Vermittler zwischen Model und View. Er empfängt Benutzereingaben von der Ansicht, verarbeitet diese (oft durch Interaktionen mit dem Modell) und aktualisiert anschließend die Ansicht mit neuen Daten oder Änderungen. Der Controller hält Modell und Ansicht getrennt und koordiniert ihre Interaktionen.
MVC wird häufig in Webanwendungen eingesetzt, bei denen eine klare Trennung zwischen der Darstellung der Informationen (Webseiten), der Logik der Benutzerinteraktion und der Datenverwaltung erforderlich ist. Es eignet sich damit besonders gut für Anwendungen, bei denen die Benutzeroberfläche regelmäßig aktualisiert werden muss, basierend auf Änderungen in den Daten oder der Geschäftslogik, wie z.B. bei dynamischen Websites, Web-Apps und Unternehmensanwendungen.
Model-View-ViewModel (MVVM)
MVVM ist ein weiterer beliebter Ansatz in der Softwarearchitektur. Im Gegensatz zum MVC, wo der Controller als Vermittler fungiert, ist es beim Model-View-ViewModel die Ansicht (View), die direkt mit dem Model kommuniziert.
- Model: Das Modell kümmert sich um die Daten und die damit verbundene Logik. Es bestimmt, was gespeichert wird, wie, wo und unter welchen Bedingungen.
- View: Die Ansicht ist für die Benutzeroberfläche (UI) zuständig. Diese setzt sich aus HTML, CSS, JS und anderen Frontend-Architekturen zusammen.
- ViewModel: Das ViewModel ist verantwortlich für die Aktualisierung der Ansicht und die Kommunikation mit dem Model.
Durch diese Struktur ermöglicht MVVM eine klare Trennung zwischen Präsentationslogik und Geschäftslogik der Anwendung. Diese Trennung erleichtert nicht nur die Wartung und Skalierbarkeit des Codes, sondern fördert auch die Wiederverwendbarkeit und Testbarkeit der einzelnen Komponenten. Indem die Ansicht direkt mit dem ViewModel kommuniziert, ohne durch den Controller gehen zu müssen, wird eine engere Bindung zwischen UI und Logik ermöglicht, die den Entwicklungsprozess effizienter macht.
Nachdem wir uns nun zwei der beliebtesten Entwurfsmuster angeschaut haben, ist es Zeit, uns Best Practices für den Aufbau skalierbarer Frontend-Architekturen anzuschauen. Denn wie bei allem im Leben, ist auch in der Softwareentwicklung eine gute Vorbereitung das A und O.
Best Practices für skalierbare Frontend-Architektur
Planung ist alles!
Bevor ihr mit dem Entwickeln neuer Software beginnt, steht an erster Stelle eine ordentliche Planung. Das bedeutet, ihr solltet einen groben Überblick darüber haben, was von dem Projekt erwartet wird und welche Schlüsselpunkte es gibt. Zum Beispiel erfordert der Aufbau eines Dashboards eine ganz andere Herangehensweise als die Erstellung einer Landingpage.
Welche Packages werdet ihr verwenden? Werden bestimmte Logiken auf dem Frontend abgebildet oder nicht?
Eine durchdachte Planung ist schon die halbe Miete und je mehr Projekte ihr habt, desto besser wird eure Voraborganisation. Alles niederzuschreiben oder eure Anwendung auf Papier zu skizzieren, kann enorm helfen. Oft kommen einem dabei Einsichten, die man sonst übersehen hätte. Der Clou beim Aufbau skalierbarer Systeme ist, dass ihr Mikrosysteme schafft, die in Zukunft leicht geändert und erweitert werden können. Außerdem ist es essenziell, dass jede Komponente, Funktion, Model, View und Controller genau eine Aufgabe erfüllt und nicht mehrere. Sobald ihr anfangt, mehr Aufgaben zu einer einzelnen Komponente hinzuzufügen, wird eure Anwendung komplizierter und schwerer zu warten.
Beim Planen solltet ihr auch zukünftige Upgrades, Updates und Änderungen einkalkulieren. Wenn die Planung stimmt, werden all diese Anpassungen zum Kinderspiel. Ein weiterer wichtiger Punkt ist, die Softwarearchitektur in jeder Hinsicht logisch zu gestalten. Wenn alle ihre Hauptdatei index.html nennen, solltet ihr eure nicht startingPoint.html nennen.
Indem ihr diesen Ansatz verfolgt, legt ihr das Fundament für eine skalierbare Frontend-Architektur.
Ordnerstruktur
Jetzt, wo wir die Planung gemeistert haben, widmen wir uns einem weiteren essentiellen Punkt der Frontend-Architektur: der Ordnerstruktur. Warum? Ganz einfach, weil wir mit Ordnern arbeiten, oft bevor auch nur eine einzige Zeile Code geschrieben wurde.
Die Struktur eurer Ordner sollte der Struktur eures Codes bzw. genauer gesagt der Struktur eurer Anwendung folgen. Nachdem wir geplant haben, wissen wir, was unsere Anwendung benötigt. Und denkt dran: Es ist unglaublich wichtig, die verschiedenen Teile der Anwendung getrennt zu halten!
Unterteilung in Kategorien
Was die Ordner angeht, könnt ihr sie in mehrere Hauptkategorien einteilen: Ansichten (Views), API, Komponenten (Components), Modelle (Models), Controller usw. Nachdem ihr eure Ordner in Hauptkategorien unterteilt habt, könnt ihr weitere Unterordner als Unterkategorien hinzufügen. Zum Beispiel könnten unter Ansichten (Views) Unterkategorien wie Dashboard, Benutzer, Artikel usw. liegen, unter Komponenten (Components) Buttons, Formulare, Cards, Modals usw. Es gibt wirklich keine Regel, die besagt, dass dies zu viel oder zu wenig ist. Ihr müsst selbst den richtigen Mittelweg finden. Aber als allgemeine Regel gilt, dass ihr so spezifisch wie möglich sein solltet. Auch wenn es mühsam erscheinen mag, hilft es langfristig enorm.
Benamung
Zudem sollte die Ordnerstruktur sauber und leicht verständlich sein. Wenn ein:e ander:e Entwickler:in euer Projekt öffnet, sollte diese:r intuitiv wissen, wo was zu finden ist, ohne Stunden mit der Suche verbringen zu müssen.
Um es so intuitiv und zugleich so skalierbar sowie nutzbar wie möglich zu gestalten, verwendet klare Benennungen. Eure Benennungen müssen sauber, klar und einfach sein. Google hat sogar eine Ressource zu Benennungskonventionen erstellt.
Ein kleiner Tipp: Wenn ihr nur eine Datei in einem Ordner habt, könnt ihr sie index.js, index.ts, index.php (je nach Erweiterung) nennen, denn es ist viel einfacher und schneller, diese Datei zu importieren.
Mit dieser Herangehensweise schafft ihr nicht nur eine Ordnung, die eure Entwicklung vereinfacht, sondern legt auch den Grundstein für eine Architektur, die flexibel genug ist, um mit euren Bedürfnissen zu wachsen und sich anzupassen.
Codestruktur
Genau wie bei der Ordnerstruktur, spielt auch bei der Codestruktur die Benennung eine entscheidende Rolle!
Schauen wir uns ein Beispiel an:
Wir haben keine Ahnung, was diese Funktion tut. Also müssen wir darauf klicken, ihre Quelle finden und dann lesen und lesen und lesen… bis wir endlich herausfinden, was „diese Funktion tut“.
Deswegen wiederholen wir uns gerne noch einmal: Ein klares Naming ist extrem wichtig! Setzen wir dies an unserem Beispiel um…
… so wissen wir auf einen Blick, was die Funktion tut. Super, oder?
Ein weiterer wichtiger Aspekt eurer Code-Struktur ist das Kommentieren des Codes. Ihr müsst sinnvolle Kommentare in eurem Code haben, denn in 6 Monaten werdet ihr euch wahrscheinlich nicht erinnern, welche Art von Daten die Funktion empfängt, in welchem Format und was sie zurückgibt.
Um die Wichtigkeit sauberen Codes zu verstehen, genügt ein Blick auf beliebte Plattformen, die von Hunderten oder sogar Tausenden von Personen gewartet werden.
Das folgende Beispiel ist die Standard-User-Modelldatei für Laravel und zeigt, wie Code kommentiert werden sollte.
Um eine skalierbare Frontend-Architektur aufbauen zu können, müsst ihr folgende Philosophie verinnerlichen: Ein Code-Element erfüllt nur eine einzige Aufgabe. Wenn es mehr als eine Aufgabe zu erfüllen hat, muss es in mehrere Komponenten aufgeteilt werden. Und wenn wir Komponenten sagen, dann meinen wir alles: wie Funktionen, Ansichten, UI-Components, Variablen usw.
Ihr fragt euch jetzt vielleicht: Warum ist das wichtig?
Stellt euch vor, eure Anwendung wächst und ihr müsst sie aktualisieren. Der einfachste Weg, etwas zu aktualisieren, ist, es nur an einer Stelle zu tun. Das ist auch einer der Gründe, warum wir heute .env-Dateien haben. Ohne .env-Dateien müssten wir, wenn wir die Datenbank-Credentials ändern, diese in jeder Datei aktualisieren, in der wir eine Verbindung zur Datenbank aufbauen. Ziemlich mühsam, nicht wahr?
Microcomponents
Das führt uns zum nächsten wichtigen Punkt: Wir sollten Mikrokomponenten erstellen und nutzen. Mikrokomponenten erfüllen jeweils nur eine kleine Aufgabe und können beliebig oft wiederverwendet werden.
Schauen wir uns folgendes Microcomponent-Beispiel an – bei dem wir eine Überschrift in einem Dashboard haben:
Dank Microcomponents können wir diese Heading nun überall in unserem Code einfach mit <Heading heading="This is text"/> nutzen. Wollen wir nun im Nachhinein die Textfarbe anpassen, müssen wir es nur an dieser einen Stelle tun (nämlich in der Mikrokomponente).
Das ermöglicht es uns nicht nur schneller zu entwickeln, sondern auch schneller zu updaten.
Nutzung von CSS in der Frontend Architektur
Mit dem Aufkommen von React und anderen JavaScript-Frameworks entbrannte die Debatte, ob wir unser CSS in JS-Dateien packen sollten. Es gibt sogar einige Bibliotheken wie Styled Components, StyleX und Emotion, die uns dabei unterstützen. Doch wir bei Aptex setzen uns für eine Trennung von CSS und JS ein.
Die Gründe dafür sind einfach. Wir möchten, dass unser Code, unsere Dateien und Assets übersichtlich strukturiert sind. Anstatt CSS in JS zu verwenden, setzen wir auf CSS-Frameworks, die unseren Entwicklungsprozess beschleunigen und unseren Code lesbarer, einfacher und leichter verständlich machen können. Eines der Frameworks, das wir nutzen, ist Tailwind. Es gibt auch andere Frameworks wie Bootstrap, Bulma, Materialize usw. Darüber hinaus gibt es auch Präprozessoren wie SCSS, welches bei vielen Entwickler:innen sehr beliebt ist.
Je nachdem, wofür ihr euch entscheidet, kann sich eure CSS-Code- und Ordnerstruktur unterscheiden. Wenn ihr euch für SCSS entscheidet, müsstet ihr wahrscheinlich Ordner und Dateien für verschiedene Komponenten, Media Queries usw. anlegen. Nutzt ihr TailwindCSS, müsst ihr es richtig konfigurieren, und dann wird das meiste hinter den Kulissen abgewickelt. Bei Bootstrap, müsst ihr lediglich ein Link-Tag verwenden, um es mit eurem Projekt zu verbinden, unabhängig davon, ob ihr ein CDN verwendet oder eine benutzerdefinierte Datei in eurem Projekt habt.
Weitere Libraries
So gut wie jedes Projekt nutzt zusätzliche Bibliotheken. Abhängig von diesen müsst ihr eure Frontend-Architektur eventuell leicht anpassen. Beachtet dabei jedoch weiterhin, dass eure Ordnerstrukturen clean und intuitiv bleiben sollten und trennt eure Dateien so wie es euch gefällt.
Solltet ihr durch weitere Bibliotheken aber gezwungen sein, zusätzliche Dateien zu erstellen, so nutzt einfach eure bestehende Ordnerstruktur.
Frontend-Architektur – Quick Guide
Um das Fundament für eine skalierbare Frontend-Architektur zu legen,gibt es einige grundlegende Regeln, die ihr beachten solltet:
- Eine gute Planung ist entscheidend. Ohne eine solide Vorabplanung seid ihr im Entwicklungsprozess verloren. Denkt an das große Ganze, bevor ihr mit dem Coden beginnt.
- Erstellt saubere Ordner- und Dateistrukturen. Eine intuitive Struktur erleichtert nicht nur euch, sondern auch euren Teamkolleg:innen die Arbeit.
- Achtet auf die Benennung aller eurer Komponenten. Klare Namensgebungen reduzieren Missverständnisse und erleichtern die Navigation im Code.
- Verwendet Kommentare im Code. Kommentare sind eure Notizen für die Zukunft – sie helfen euch und anderen Entwickler:innen, den Überblick zu behalten.
- Jede Komponente sollte nur eine einzige Funktion haben! Das vereinfacht die Wartung und zukünftige Anpassungen.
- Erstellt Mikrokomponenten. Sie ermöglichen eine schnellere Entwicklung, einfachere Updates und eine effizientere Fehlerbehebung.
- Trennt verschiedene Code-Typen in verschiedenen Ordnern. Dadurch bleibt eure Struktur übersichtlich und logisch.
- Integriert zusätzliche Bibliotheken sinnvoll. Eure Architektur sollte flexibel genug sein, um neue Tools und Bibliotheken problemlos integrieren zu können, ohne dass ihr euer gesamtes Setup überarbeiten müsst.
Suchst du nach einer erfahrenen Agentur für die Umsetzung deines Projekts? Kontaktiere uns gerne für ein unverbindliches Angebot! Wir haben jahrelange Erfahrung und wissen, wie man eine skalierbare Frontend-Architektur aufbaut.