Viele Wege führen nach Rom – und ebenso viele Wege gibt es, Dokumente in Softwareprojekten zu generieren. In diesem Artikel vergleichen wir zwei Ansätze, und beleuchten deren Vor- und Nachteile: die Dokumenten-Generierung im Frontend und im Backend. Anhand der Projekte Testiny und TRUDI zeigen wir, welcher Ansatz sich für welchen Anwendungsfall eignet.
Projektvorstellungen: Testiny und TRUDI
Testiny: SaaS-Lösung für Testmanagement in der Softwareentwicklung
Testiny ist eine Single Page Application (SPA) im Webbrowser, die für Testmanagement verwendet wird. Nach Abschluss eines Testlaufs sollen die Ergebnisse in einem Bericht druck- und speicherbar zur Verfügung stehen.
TRUDI: Web-basiertes Auftragsmanagement im Containertransport
TRUDI ist ein zentrales Kommunikationstool für Spediteure und andere Akteure im kombinierten Verkehr. Ein zentraler Anwendungsfall ist die Digitalisierung des Lieferscheins, der flexibel gestaltet und direkt auf dem Smartphone erstellt werden kann.
Frontend-Dokumenten-Generierung bei Testiny
Beim Erstellen eines Berichts löst der Nutzer einen HTTP-POST-Aufruf an das Backend aus. Das Backend liefert die Berichtsinhalte als JSON zurück, und das Frontend generiert daraus eine HTML-Seite, die im Browser angezeigt und gedruckt werden kann.
Umsetzung im Detail:
Im Testlauf kann man die Inhalte des zu erstellenden Berichtes bestimmen. Mit "Bericht erstellen" wird eine Vorschau des Berichtes im Druck-Dialog des Webbrowsers geöffnet. Der Bericht wird in der Webanwendung am Client (Browser) als HTML-Seite erstellt und über den Browser-Druckdialog für den direkten Druck oder die Ablage als PDF zur Verfügung gestellt. "Bericht erstellen" löst einen HTTP-POST-Aufruf an das Backend aus, in dem die Einstellungen des Dialogs (ob z.B. Anhänge & Bilder im Bericht aufscheinen sollen, ob Testfallinhalte mitgedruckt werden sollen, ….) an das Backend übermittelt werden. (Aufruf "/api/v1/report/")
Fenster "Bericht erstellen"
Vorschau des Berichtes
Als Antwort wird ein JSON mit den Berichtsinhalten zurückgegeben. Je nach Einstellungen des Berichtdialogs ruft das Frontend zusätzliche Daten ab (z.B. "/api/v1/custom-fields/all", wenn im Berichtsdialog "Zusätzliche Felder anzeigen" gewählt wurde). Das Frontend erstellt aus den gelieferten Rohdaten eine HTML-Seite, die im Browser über einen iFrame zum Druck zur Verfügung steht.
JSON mit den Berichtsinhalten
Vorteile der Frontend-Generierung
- Wiederverwendbarkeit: Grafische Komponenten können sowohl in der Anwendung als auch im Bericht genutzt werden.
- Reduzierte Datenmenge: Durch die Übermittlung der Rohdaten wird die Datenmenge minimiert.
- Entlastung des Backends: Rechenintensive Aufgaben (grafische Aufbereitung der Daten) werden an den Client ausgelagert.
Nachteile der Frontend-Generierung
- Einschränkungen in der Gestaltung: HTML-basierte Berichte haben begrenzte Gestaltungsmöglichkeiten.
- Abweichende Darstellung: Unterschiedliche Browser können Berichte unterschiedlich anzeigen.
- Fehlendes "1:1" Datei-Gefühl: Der Bericht wird jedes Mal neu generiert, was das Gefühl einer unveränderbaren Datei mindert.
Architektonisch hat sich das Entwicklerteam von Testiny den Weg offengelassen, den Bericht zukünftig, sollten die genannten Nachteile ("Abweichende Darstellung" und "'1:1' Datei" einmal zu einem Problem werden), auch als Datei über das Backend zu erzeugen. In diesem Fall würden sich am Backend ein Frontend in einem Headless Browser öffnen, den Bericht erzeugen, als PDF abspeichern, und über das Backend das so erzeugte PDF als Binärdownload ausliefern.
Architektonisch haben wir uns den Weg offengelassen, den Bericht zukünftig auch als Datei über das Backend zu erzeugen.
Stefan Schnuderl, Software-Architekt im Projekt Testiny
Backend-Dokumenten-Generierung bei TRUDI
Die Berichterstellung erfolgt im Backend mit .NET und der Bibliothek QuestPDF. Berichte werden pixelgenau definiert und als PDF generiert, was eine konsistente Darstellung und einfache Weiterbearbeitung ermöglicht.
Technische Umsetzung im Detail:
Die Berichterstellung für TRUDI wird im Backend mit .NET realisiert. Mit .NET kann auf eine Vielzahl von Bibliotheken zurückgegriffen werden, die die Dokumentenerzeugung stark vereinfachen. Im Zuge einer Evaluierung haben hat sich das Entwicklungsteam für die Bibliothek QuestPDF entschieden. Dabei wird mit einer FluentLibrary der gewünschte Bericht definiert und anschließend als PDF erzeugt. Durch die integrierte Vorschau wird die Entwicklung deutlich beschleunigt und vereinfacht. Die Vorschau aktualisiert sich bei jedem Speichern der Datei über ein schnelles Hot-Reloading, sofern document.ShowInPreview() aufgerufen wird. Die Anwendung muss dazu einfach mit dotnet watch gestartet werden. Das PDF selbst lässt sich über document.GeneratePdf(„hello.pdf“) erzeugen.
Quellcode und QuestPDF Vorschau nebeneinander
Video aus der QuestPDF Homepage
Vorteile der Backend-Generierung
- Pixelgenauigkeit: Berichte sind unabhängig von Browsern immer gleich.
- Flexibilität: Berichte können weiterbearbeitet, zusammengeführt und elektronisch signiert werden.
- Unabhängigkeit von Frontend-Technologien: Die Generierung ist nicht an das Frontend gebunden.
Nachteile der Backend-Generierung
- Backend-Abhängigkeit: Ein Backend ist erforderlich, was zusätzlichen Entwicklungsaufwand bedeutet.
- Kosten: Für kommerzielle Projekte können Lizenzkosten anfallen.
- Entwicklungsaufwand: Die Entwicklung kann aufwendiger sein.
Die Flexibilität Berichte weiterverarbeiten, zusammenführen und elektronisch signieren zu können, war für uns ausschlaggebend.
Patrick Schadler, Senior Lead-DEV im Projekt TRUDI
Fazit zum Vergleich der Dokumentengenerierung im Frontend vs. Backend - Welcher Ansatz ist der richtige?
Beide Lösungswege – die Frontend-basierte Dokumentengenerierung in Testiny und die Backend-basierte Lösung in TRUDI – haben ihre spezifischen Vor- und Nachteile, die sie für unterschiedliche Anwendungsfälle geeignet machen.
Die Wahl zwischen Frontend- und Backend-Dokumenten-Generierung hängt also von den spezifischen Anforderungen des Projekts ab. Die Frontend-Lösung eignet sich besonders für Anwendungen, die von der Interaktivität und Wiederverwendbarkeit der UI-Komponenten profitieren und eine direkte Entlastung des Backends benötigen. Die Backend-Lösung ist optimal für Szenarien, die pixelgenaue, weiterverarbeitbare Berichte erfordern und unabhängig von Frontend-Beschränkungen arbeiten müssen.
