Angular at Scale – Best Practices für Enterprise-Applikationen
Große Angular-Projekte wachsen schnell – und mit ihnen die Komplexität. Wir zeigen, wie ein durchdachtes Setup Skalierbarkeit, Wartbarkeit und einen reibungslosen Teamwechsel über Jahre hinweg sicherstellt.
Anforderungen
Seit mehreren Jahren liegt unser Fokus bei FORTIX auf der Entwicklung von Enterprise-Applikationen mit Angular. Dabei stehen vor allem drei Ziele im Vordergrund: Die Anwendungen sollen über ihre gesamte Lebensdauer hinweg skalierbar bleiben, sich einfach warten und erweitern lassen und gleichzeitig einen leichten Einstieg für neue Teammitglieder ermöglichen – unabhängig davon, wie groß oder wie wechselhaft ein Team aufgestellt ist.
Gerade in großen Projekten verändern sich Teams im Laufe der Zeit. Rollen verändern sich, neue Mitarbeiter kommen hinzu und Anforderungen wachsen. Deshalb ist es wichtig, bereits zu Beginn des Projekts die nötige Flexibilität im Setup zu berücksichtigen. Eine gut strukturierte und wartungsfreundliche Architektur zahlt sich langfristig aus. Es gibt kaum etwas Ärgerlicheres als technische Altlasten, die zukünftige Weiterentwicklungen erschweren oder blockieren.
Das Setup
Unser bevorzugtes Setup basiert auf einem NX Monorepo, das mehrere Vorteile vereint. Es ermöglicht eine klare Trennung zwischen Anwendungen und Bibliotheken, sorgt für einheitliche und wiederverwendbare Standardbefehle und bietet effizientes Caching sowie schnelle Build-Prozesse. Durch diese Struktur lassen sich neue Anwendungen und Komponenten konsistent integrieren, was Wartung und Erweiterungen deutlich vereinfacht.
Typische Struktur
- Component Library – zentrale UI-Komponenten
- Style Library – Themes, Layout, Variablen
- Utils Library – generische Funktionen & Helfer
- Signal Stores – schlankes State-Management
- NSwag-Generierung – gemeinsame API-Typdefinitionen für Client & Server
Warum NX Monorepo?
Mit NX erreichen wir bereits die wesentlichen Projektanforderungen:
- Trennung zwischen Apps und Libraries - Einfachere Wartung & Fehlersuche
- Wiederverwendbare Komponenten - Schneller Aufbau neuer Anwendungen
- Team-freundliche Struktur - Leichter Einstieg für neue Teammitglieder
Neue Anwendungen können innerhalb des Monorepos mit denselben UI-Komponenten und Tools erstellt werden. Das steigert Konsistenz und reduziert Aufwand.
Component Library
Für die Component Library setzen wir häufig auf DevExtreme als Basis. Diese liefert eine große Auswahl an vorgefertigten UI-Komponenten wie Tabellen, Data Grids und Formularelementen.
Wir erstellen eigene Wrapper-Komponenten, um Controls gezielt zuzuschneiden. Das spart Zeit und sorgt für ein durchgängiges UI-Verhalten im gesamten System.
Warum Signal Store?
Mit den Angular Signal Stores steht ein schlankes und sehr intuitives State-Management zur Verfügung.
Vorteile:
- Stores werden feature-spezifisch aufgebaut
- sehr übersichtliche Syntax
- weniger Boilerplate als NgRx
- Migration von NgRx schrittweise möglich
Der Store befindet sich nah an der Komponente → das verbessert Lesbarkeit und Testbarkeit.
Instruction Files
Damit Vorschläge von GitHub Copilot oder anderen AI-Tools den Projektstandards entsprechen, verwenden wir ein instructions.md im Repository.
- Projektbeschreibung & Struktur
- Coding-Guidelines
- Namenskonventionen
- Beispielcode
So wird AI-generierter Code direkt in der gewünschten Form erzeugt.
Testing & Wartung
Für langfristig stabile Anwendungen setzen wir auf:
- Unit Tests für Kernlogik & Helper
- E2E Tests für kritische Userflows
- Regelmäßige Angular Updates, um Tech Debt gering zu halten
Eine klare Architektur erleichtert Testbarkeit automatisch.
Wesentliche Punkte (Zusammenfassung)
- UI - Basiskomponenten aus Library (DevExtreme + Wrapper)
- Zustand - Signal Stores, nach Features getrennt
- Architektur - Standalone Components + Library-Aufteilung
- AI-Unterstützung - instructions.md zur Regelung von Copilot-Vorschlägen
Ausblick: Micro Frontends
Für sehr große Systeme oder mehrere unabhängige Teams kann der Einsatz von Micro Frontends sinnvoll sein. Dabei werden mehrere Frontend-Anwendungen separat entwickelt und deployt, aber in eine gemeinsame Shell eingebettet. So können Teams unabhängig arbeiten, Features releasen und gleichzeitig die Anwendungen als ein zusammenhängendes System präsentieren.
Mit Webpack Module Federation lassen sich diese Micro Frontends zur Laufzeit laden und dynamisch kombinieren. Dies ermöglicht nicht nur unabhängige Deployments, sondern erlaubt auch den Einsatz unterschiedlicher Technologien innerhalb desselben Projekts und schafft klare Verantwortlichkeiten pro Team.
Typische Anwendungsbeispiele sind Webshops, bei denen Checkout, Artikelverwaltung und Userverwaltung als separate Frontends implementiert werden, oder Plattformen wie Netflix, bei denen Startseite, Suche, Player und Profile voneinander entkoppelt sind und unabhängig weiterentwickelt werden können.