Technologie-Stack und Designbegruendung

Die Technologieentscheidungen in QuoteNode orientieren sich an Sicherheit, Korrektheit und langfristiger Wartbarkeit, nicht an minimalem RAM-Verbrauch oder wechselnden Framework-Trends.

Diese Seite erklaert, was wir einsetzen, warum wir es gewaehlt haben und was das fuer Betrieb und Deployment bedeutet.

Warum Java 25 und Spring Boot 4

Sicherheit als Haupttreiber

QuoteNode verarbeitet sensible kaufmaennische Daten: Kundenstammsaetze, Preisstrategien, Angebotsverhandlungen und Geschaeftsbeziehungen. Der Technologie-Stack muss in Umgebungen belastbar sein, in denen Sicherheitsfehler reale Folgen haben.

Java und Spring Boot sind die Standardwahl in Banken, Versicherungen, Gesundheitswesen und Verwaltung, also in Branchen, in denen Sicherheit nicht optional ist. Das ist kein Zufall:

• Ausgereiftes Sicherheitsmodell — Spring Security bietet ein bewaehrtes, auditierbares Fundament fuer Authentifizierung, Autorisierung, Sitzungsverwaltung, CSRF-Schutz und Security Header. Diese Grundlagen muessen nicht von Grund auf neu gebaut werden.
• Type Safety — das starke Typsystem von Java faengt ganze Fehlerklassen bereits zur Compile-Zeit ab, die in dynamisch typisierten Sprachen erst zur Laufzeit sichtbar wuerden. Bei Angebotswerten, mehreren Waehrungen, VAT-Saetzen und Rabattlogik ist Type Safety kein Luxus.
• Memory Safety — die JVM bietet automatisches Speichermanagement ueber Garbage Collection und verhindert Buffer Overflows, Use-after-free und andere Speicherfehler, wie sie aus C/C++ und teilweise auch aus Go-nahen Oekosystemen bekannt sind.
• Reifes Oekosystem — Bibliotheken wie Flyway (Migrationen), Thymeleaf (PDF-Templates), Hibernate (ORM) und Testcontainers (Integrationstests) werden von Organisationen mit langjaehrigem Track Record gepflegt.

Warum nicht Go, Rust oder Node.js

Alle drei Technologien waeren fuer andere Produkte nachvollziehbar. Fuer QuoteNode konkret gilt:

• Go — stark fuer Netzwerkdienste und CLI-Tools, aber das Typsystem ist schwaecher und die Modellierung komplexer Preislogik mit deterministischen Mehrwaehrungsberechnungen ist fehleranfaelliger. Auch das Oekosystem fuer Enterprise-Themen wie ORM, Migrationen, PDF-Rendering und Security-Frameworks ist weniger ausgereift.
• Rust — maximiert Performance und Speichersicherheit, aber auf Kosten von Entwicklungsgeschwindigkeit und Oekosystem-Reife fuer Business-Anwendungen. QuoteNode ist eine CRUD-lastige Business-Plattform und kein Systems-Programming-Projekt. Compile-Zeiten und Lernkurve wuerden den Fortschritt ohne proportionalen Nutzen verlangsamen.
• Node.js — schnell fuer Prototypen, aber Single-Threaded-Concurrency, schwaechere Typdisziplin selbst mit TypeScript und ein fragmentiertes Oekosystem machen es zu einem schlechteren Fit fuer eine sicherheitskritische Plattform mit finanziellen Berechnungen. Dazu kommt das Supply-Chain-Risiko durch tiefe npm-Abhaengigkeitsbaeume.

Was das fuer den Ressourcenverbrauch bedeutet

Java-Anwendungen benoetigen mehr Speicher als vergleichbare Dienste in Go oder Rust. Ein QuoteNode-Backend liegt typischerweise bei 512 MB bis 1.5 GB RAM, abhaengig von Last und JVM-Konfiguration. Das ist ein bewusster Trade-off:

• der JIT-Compiler der JVM optimiert heisse Pfade nach dem Warm-up und liefert fuer dauerhafte Workloads einen Durchsatz, der nativen Sprachen nahekommt,
• Garbage-Collection-Pausen sind fuer eine Single-Tenant-Anwendung mit typischer B2B-Last praktisch vernachlaessigbar,
• der zusaetzliche Speicherbedarf kauft ein reichhaltiges Typsystem, ausgereifte Security-Primitiven, battle-tested Bibliotheken und schnellere Feature-Entwicklung.

Fuer eine self-hosted, single-tenant Anwendung, die genau eine Organisation bedient, ist der Unterschied zwischen 256 MB und 1 GB RAM operativ kaum relevant. Der guenstigste VPS, der Docker Compose sinnvoll ausfuehren kann, betreibt auch QuoteNode bequem.

PostgreSQL 16

PostgreSQL ist die einzige unterstuetzte Datenbank. Das ist absichtlich so:

• ACID-Konformitaet — jede Angebotsberechnung, jeder Statuswechsel und jeder Audit-Log-Eintrag findet in einer sauberen Transaktion statt. Das MVCC-Modell von PostgreSQL liefert starke Isolationsgarantien.
• JSON-Support — Angebots-Snapshots werden in JSONB-Spalten gespeichert, wodurch sich historische Angebotsdaten effizient abfragen lassen, ohne einen separaten Document Store einzufuehren.
• Erweiterungen — pgcrypto fuer serverseitiges Hashing und pg_trgm fuer Volltextsuche auf Kundennamen und Produkten.
• Zuverlaessigkeit — PostgreSQL hat jahrzehntelange Produktionshistorie in Finanz- und Handelssystemen.
• Backup-Werkzeuge — pg_dump im Custom-Format erlaubt konsistente Online-Backups ohne Downtime.

Datenbankverschluesselung

Sensible Felder werden auf Anwendungsebene mit AES-256-GCM verschluesselt.

Immer verschluesselt (erfordert DB_ENCRYPTION_KEY):

• TOTP-Secrets (2FA-Backup-Codes)
• SMTP-Credentials

Optional verschluesselt (wenn ENCRYPT_PII=true):

• Kunden-PII — Namen, E-Mail, Telefon, NIP / Tax ID
• Kontaktpersonen-PII — Namen, E-Mail, Telefon
• Lieferanten-PII — Tax ID, E-Mail, Telefon
• Lieferantenkontakt-PII — Namen, E-Mail, Telefon
• Benutzer-PII — E-Mail, Vorname, Nachname, Telefonnummer
• Order-Intent-PII — Kundenname, E-Mail, Telefon

Wenn PII-Verschluesselung aktiv ist, nutzen exakte Suchanfragen HMAC-SHA256-Blind-Indexes, die neben dem Ciphertext gespeichert werden, statt direkter Column-Lookups. Die Volltextsuche faellt auf Nicht-PII-Felder zurueck, etwa Firmennamen oder gecachte Anzeigenamen. LIKE-Abfragen auf verschluesselten Spalten sind bewusst nicht moeglich. Das ist ein absichtlicher Trade-off zugunsten des Datenschutzes.

Der Verschluesselungsschluessel wird aus der Umgebungsvariable DB_ENCRYPTION_KEY ueber SHA-256 abgeleitet. Der Schluessel selbst beruehrt die Datenbank nie und existiert nur im Arbeitsspeicher der Anwendung. Ein Validator fuer Produktionskonfiguration verhindert den Start mit dem Default-Development-Key. Ein separater Startup-Validator erkennt zudem Inkonsistenzen zwischen Verschluesselungsflag und Datenbankzustand, etwa verschluesselte Daten bei ENCRYPT_PII=false oder einen falschen Schluessel, und verweigert den Start, um stille Datenkorruption zu verhindern.

Fuer Bulk-Operationen stehen CLI-Werkzeuge bereit: --pii-encrypt (bestehenden Klartext verschluesseln), --pii-decrypt (zurueck in Klartext) und --pii-rekey=<old-key> (mit einem neuen Schluessel neu verschluesseln).

Die Vollverschluesselung der Datenbank at-rest wird an die Hosting-Infrastruktur delegiert, etwa LUKS oder verschluesselte EBS-Volumes, weil das fuer grosse Datenmengen performanter ist als reine Spaltenverschluesselung.

Vue-3-Frontend

Das Frontend ist eine Single-Page-Application auf Basis von Vue 3, Vite, PrimeVue 4 und Tailwind CSS 4:

• Vue 3 — reaktive, komponentenbasierte UI mit starkem TypeScript-Support und reifem Oekosystem
• PrimeVue 4 — Enterprise-Komponentenbibliothek mit zugaenglichen, funktionsreichen Tabellen, Formularen und Dialogen. So muessen komplexe UI-Muster nicht neu erfunden werden.
• Tailwind CSS 4 — Utility-First-Styling mit Design Tokens fuer eine konsistente visuelle Sprache ohne CSS-Ballast
• Vite — schneller Build-Tooling-Stack mit Hot Module Replacement fuer hohe Produktivitaet
• vue-i18n — vollstaendige Internationalisierung mit Englisch und Polnisch, weitere Sprachen sind geplant

Das Frontend kommuniziert ausschliesslich ueber eine typisierte REST-API mit dem Backend. Es wird von Caddy als statisches Asset ausgeliefert und hat keinen direkten Datenbankzugriff.

Gotenberg (PDF-Engine)

Die PDF-Erzeugung nutzt Gotenberg, einen Chromium-basierten HTML-zu-PDF-Dienst:

• rendert modernes CSS mit Flexbox, Grid und Custom Properties sauber,
• laeuft als eigener Docker-Container und isoliert so den Rendering-Prozess,
• unterstuetzt Paginierung, benutzerdefinierte Margins und Header/Footer-Templates,
• benoetigt keine direkte Chromium-Abhaengigkeit im Backend, da die Kommunikation ueber HTTP-API erfolgt.

Der Gotenberg-Container benoetigt ungefaehr 200-400 MB RAM. Er ist nur waehrend der PDF-Erzeugung aktiv und kann per Docker-Ressourcenlimits eingeschraenkt werden.

Caddy (Reverse Proxy)

Caddy 2 dient als Reverse Proxy mit automatischem HTTPS:

• automatische TLS-Zertifikatsausstellung ueber Let’s Encrypt,
• Unterstuetzung fuer HTTP/2 und HTTP/3,
• einfache, deklarative Konfiguration,
• minimaler Ressourcenbedarf von etwa 20 MB RAM.

In Coolify-Deployments uebernimmt der eigene Caddy-Proxy von Coolify die TLS-Schicht, sodass der Anwendungskontainer keinen separaten Reverse Proxy mitbringen muss.

Gesamter Ressourcenbedarf

Komponente	RAM (typisch)	Disk	CPU
Backend (Java 25)	512 MB – 1.5 GB	minimal	1 Kern
PostgreSQL 16	256 MB – 512 MB	1-10 GB Daten	geteilt
Frontend (statisch)	~20 MB	~50 MB	vernachlaessigbar
Gotenberg	200-400 MB	~500 MB	burst only
Caddy	~20 MB	minimal	vernachlaessigbar
Gesamt	~1.5 – 2.5 GB	~2-12 GB	2 Kerne

Ein VPS mit 4 GB RAM, 2 Kernen und 20 GB SSD betreibt den kompletten QuoteNode-Stack bequem fuer ein Team von 10 bis 20 Benutzern. Das entspricht grob einer Cloud-Instanz fuer etwa 10 bis 20 USD pro Monat und liegt deutlich unter den laufenden Kosten vieler SaaS-CRM-Abos.

Ideal fuer kleine und mittlere Unternehmen

QuoteNode ist fuer Organisationen mit 1 bis 50 Benutzern ausgelegt:

• Freelancer und Solo-Berater, die professionelle Angebotsdokumente brauchen, ohne fuer ein Enterprise-CRM zu bezahlen
• Kleine Agenturen mit 5 bis 15 Personen, die Kunden- und Angebotsdaten zentral mit Team-Transparenz verwalten wollen
• Mittelgrosse Unternehmen mit 15 bis 50 Personen und strukturierterem Vertrieb, die Pipeline-Analytik, rollenbasierten Zugriff und Audit-Compliance brauchen

Das self-hosted Modell eliminiert monatliche per-seat Gebuehren und gibt gleichzeitig volle Kontrolle ueber Daten, Branding und Sicherheitskonfiguration. Fuer Organisationen, die bereits grundlegende Serverinfrastruktur betreiben oder eine gemanagte Docker-Plattform wie Coolify nutzen, ist der zusaetzliche operative Aufwand sehr gering.

Mehrsprachigkeits-Roadmap

QuoteNode unterstuetzt derzeit Englisch und Polnisch sowohl in der Application UI als auch auf allen kundenorientierten Oberflaechen wie Angeboten, PDFs, oeffentlichen Links und E-Mails.

Nach der ersten Public Beta planen wir die Erweiterung um:

• Deutsch
• Franzoesisch
• Spanisch
• Portugiesisch

Langfristig ist das Ziel eine vollstaendige Abdeckung aller wichtigen europaeischen Sprachen. Die i18n-Architektur, also vue-i18n mit strukturierten Key-Dateien, ist so ausgelegt, dass fuer diese Erweiterung keine Code-Aenderungen noetig sind. Es muessen lediglich weitere Uebersetzungsdateien hinzugefuegt werden.

Angebots-PDFs und Seiten mit oeffentlichen Links koennen bereits in jeder unterstuetzten Locale gerendert werden, unabhaengig von der Sprache der UI. Dadurch lassen sich Angebote internationalen Kunden in ihrer bevorzugten Sprache praesentieren.