PROMARIS

Technologie

In Rust gebaut.

Kein WordPress. Kein PHP. Kein JavaScript-Framework. Diese Website ist — vom HTTP-Server bis zur Animation im Browser — vollständig in Rust geschrieben, typsicher kompiliert und als WebAssembly ausgeliefert.

Sprachanteile

Beim Build aus dem eigenen Quellbaum gemessen — inklusive dieser Seite.

Rust75.6 %
SCSS18.5 %
TOML3.8 %
Dockerfile2.0 %
JSON0.2 %

Was nicht drin ist

0Zeilen handgeschriebenes HTML
0Zeilen JavaScript
0Zeilen PHP

Das HTML entsteht zur Laufzeit aus Rust-Code. Das einzige JavaScript ist die von der Rust→WebAssembly-Toolchain generierte Ladebrücke — davon schreiben wir keine Zeile selbst.

Eingesetzte Crates

Auf ein Crate zeigen blendet die ausführliche Erklärung ein. Ein Klick öffnet es auf crates.io — der offiziellen Paketregistrierung von Rust, inklusive Quellcode und Dokumentation. Nachlesen ausdrücklich erwünscht.

  • leptosReaktives Fullstack-UI (SSR + WASM)Leptos ist das Fullstack-Framework, auf dem diese Website aufbaut. Die Oberfläche wird als reaktive Komponenten in Rust beschrieben und sowohl auf dem Server gerendert (für eine schnelle erste Auslieferung und für Suchmaschinen) als auch im Browser als WebAssembly ausgeführt. Dieselbe Rust-Codebasis läuft damit auf beiden Seiten — ganz ohne separates JavaScript-Frontend.
  • leptos_routerRouting zwischen den SeitenDer Router von Leptos bestimmt, welche Seite zu welcher Adresse gehört. Seitenwechsel geschehen im Browser ohne vollständiges Neuladen, sodass die Navigation flüssig bleibt — während der Server jede Adresse zusätzlich direkt ausliefern kann.
  • leptos_metaTitel und Meta-Tags im <head>Verwaltet die Angaben im <head> des Dokuments: Seitentitel, Meta-Beschreibung und weitere Kopfdaten. So erhält jede Seite die richtigen Informationen für Browser-Tab, Suchmaschinen und Link-Vorschauen.
  • serdeSerialisierung der Inhalteserde ist das Standardwerkzeug in Rust, um Datenstrukturen zwischen Rust-Typen und Formaten wie TOML zu übersetzen. Hier verwandelt es die als Text hinterlegten Inhalte in typsichere Rust-Objekte — und bei Bedarf wieder zurück.
  • serde_jsonJSON-Serialisierungserde_json ist die JSON-Umsetzung von serde. Die Nachrichten der verschlüsselten API werden als JSON transportiert; dieses Crate wandelt sie zwischen Rust-Strukturen und JSON hin und zurück.
  • pqc_kyberPost-Quantum-Schlüsselkapselung (Kyber-1024)pqc_kyber implementiert Kyber-1024 (ML-KEM) — das von der US-Normungsbehörde NIST standardisierte Post-Quantum-Verfahren zur Schlüsselkapselung. Damit einigen sich Browser und Server auf ein gemeinsames Geheimnis, das auch gegen künftige Quantencomputer sicher sein soll. Es ist die Basis unserer zusätzlich verschlüsselten API.
  • chacha20poly1305Authentisierte Verschlüsselung (AEAD)ChaCha20-Poly1305 ist ein modernes AEAD-Verfahren (authentisierte Verschlüsselung). Es verschlüsselt jede API-Nachricht und stellt zugleich sicher, dass sie unterwegs nicht unbemerkt verändert werden kann.
  • hkdfSchlüsselableitung (HKDF)HKDF leitet aus dem rohen Kyber-Geheimnis einen sauberen, zweckgebundenen Sitzungsschlüssel ab (RFC 5869) — statt das Geheimnis direkt zu verwenden. Das schafft Domain-Separation und eine klare Prüf-Spur.
  • sha2SHA-256-Hashsha2 stellt die SHA-256-Hashfunktion bereit, auf der die Schlüsselableitung der verschlüsselten API (HKDF-SHA256) aufsetzt.
  • rand_coreKryptografischer Zufall (OsRng)rand_core liefert die kryptografisch sichere Zufallsquelle (OsRng). Im Browser stammt der Zufall aus der Web-Crypto-API — die Grundlage für Schlüssel und Nonces.
  • base64Base64-Kodierungbase64 kodiert die binären Krypto-Bausteine (Schlüssel, Ciphertext, Nonce) als Text, damit sie sich bequem als JSON übertragen lassen.
  • axumHTTP-Serveraxum ist der HTTP-Server, der die Website ausliefert. Er nimmt jede Anfrage entgegen, reicht sie an die Render-Funktionen von Leptos weiter und schickt fertiges HTML sowie die statischen Dateien (WebAssembly, CSS) zurück.
  • leptos_axumServer-Integration von LeptosDie Brücke zwischen Leptos und axum. Sie verbindet die Server-Funktionen und das serverseitige Rendern von Leptos mit dem axum-Server, sodass Frontend und Backend als ein einziges Rust-Programm zusammenspielen.
  • tokioAsynchrone Laufzeittokio ist die asynchrone Laufzeitumgebung von Rust. Sie erlaubt dem Server, viele Anfragen gleichzeitig und effizient zu bearbeiten, ohne für jede einen eigenen Betriebssystem-Thread zu blockieren.
  • surrealdbIn-Memory-DatenbankSurrealDB dient hier als reine In-Memory-Datenbank: Beim Start werden die Inhalte hineingeladen und zur Laufzeit blitzschnell aus dem Arbeitsspeicher gelesen. Da es sich um eine Inhaltsseite handelt, ist keine dauerhafte Speicherung nötig — ein Neustart lädt die Daten einfach neu.
  • tomlInhalte als Code einlesenTOML ist ein schlankes, gut lesbares Textformat. Die Inhalte dieser Website liegen als TOML-Dateien vor; dieses Crate liest sie ein. Texte lassen sich so ändern, ohne Programmcode anzufassen — Inhalt als Code.
  • anyhowFehlerbehandlunganyhow vereinfacht die Fehlerbehandlung in Rust. Unterschiedliche Fehlerquellen werden zu einem einheitlichen Typ zusammengefasst, was den Servercode übersichtlich und robust hält.
  • reqwestHTTP-Client für externe Systemereqwest ist der HTTP-Client des Servers — er spricht mit den Systemen, die außerhalb dieser Website liegen. Eine Anfrage aus dem Kontaktformular legt er als Ticket in unserem Ticketsystem an; beim Login tauscht er die Tokens mit dem Anmeldedienst aus. Die Verschlüsselung übernimmt dabei rustls, eine TLS-Implementierung in Rust — ganz ohne OpenSSL im Container.
  • jsonwebtokenLogin-Token prüfen (JWKS/RS256)jsonwebtoken prüft beim Anmelden das Token, das der Anmeldedienst ausstellt. Signatur, Aussteller, Zielgruppe und Ablaufzeit werden gegen dessen öffentliche Schlüssel verifiziert (RS256 über JWKS) — erst wenn alles davon stimmt, gilt eine Anmeldung als gültig. Vertrauen entsteht so aus Mathematik, nicht aus Zuruf.
  • tower-httpStatische Dateien auslieferntower-http bringt fertige Bausteine für HTTP-Server mit. Genutzt wird hier das Ausliefern statischer Dateien direkt vom Dateisystem — für die wenigen Teile, die nicht zur Laufzeit aus Rust-Code entstehen, sondern fertig im Container liegen.
  • gloo-netHTTP-Anfragen im Browsergloo-net stellt HTTP-Anfragen direkt aus dem WebAssembly-Code. Damit holt der Browser den Server-Pubkey und sendet die verschlüsselten API-Requests.
  • console_error_panic_hookPanics in der Browser-KonsoleEin kleines Hilfsmittel für die WebAssembly-Seite: Tritt im Browser-Code ein unerwarteter Fehler (Panic) auf, wird er verständlich in der Entwicklerkonsole ausgegeben, statt stumm zu verschwinden — das erleichtert die Fehlersuche erheblich.
  • wasm-bindgenBrücke Rust ↔ Browserwasm-bindgen schlägt die Brücke zwischen dem in Rust geschriebenen WebAssembly und den Funktionen des Browsers. Es sorgt dafür, dass Rust-Code Browser-Schnittstellen aufrufen kann und umgekehrt — die Grundlage dafür, dass das Programm überhaupt im Browser läuft.
  • web-sysBrowser-APIs (Canvas u. a.)web-sys stellt die Programmierschnittstellen des Browsers als Rust-Funktionen bereit — etwa Fenster, Dokument oder Canvas. Damit zeichnet Rust unter anderem das animierte Splitterfeld direkt im Browser.

Verschlüsselte API (Post-Quantum)

Klassische Web-Verschlüsselung (RSA, elliptische Kurven) gilt heute als sicher — bis leistungsfähige Quantencomputer sie brechen. Wer heute schon mitgeschnittenen Datenverkehr aufbewahrt, könnte ihn dann rückwirkend entschlüsseln („harvest now, decrypt later“). Deshalb sichern wir die Verbindung zwischen Ihrem Browser und unserem Server zusätzlich mit einem Verfahren, das auch Quantencomputern standhalten soll.

Zum Einsatz kommt Kyber-1024 (ML-KEM) — das von der US-Normungsbehörde NIST standardisierte Post-Quantum-Verfahren für den Schlüsselaustausch. Diese Schicht liegt zusätzlich über der ohnehin aktiven TLS-Verschlüsselung: ein doppelter Boden, kein Ersatz.

  1. Schlüsselkapselung. Browser und Server einigen sich über Kyber-1024 auf ein gemeinsames Geheimnis — nach heutigem Stand auch gegen Quantencomputer sicher.
  2. Schlüsselableitung. Aus diesem Geheimnis wird per HKDF-SHA256 ein frischer Sitzungsschlüssel abgeleitet.
  3. Verschlüsselung. Jede Nachricht wird mit ChaCha20-Poly1305 authentisiert verschlüsselt. Der Client-Schlüssel ist fest an den Inhalt gebunden — so lässt sich die Antwort nicht heimlich umlenken.

Der folgende Handshake läuft gerade live in Ihrem Browser:

Kanal wird aufgebaut…

Wie es zusammenspielt

  1. Server. Ein in Rust kompiliertes axum-Backend rendert jede Seite vorab (SSR).
  2. Inhalte. Texte liegen als Code vor und werden beim Start in eine In-Memory-Datenbank geladen.
  3. Browser. Dasselbe Rust-Programm läuft als WebAssembly weiter und übernimmt die Seite (Hydration).
  4. Grafik. Das Splitterfeld zeichnet Rust direkt auf ein Canvas — kein Bild, kein Video.
  5. Deploy. Jeder Push baut den Rust-Container neu und rollt ihn automatisch aus.

Was der Build kostet

Gemessen beim Bauen genau dieses Containers — nicht geschätzt und nicht aus einem Testlauf übernommen.

…

Wie schnell es bei Ihnen lud

Kein Labor, kein Durchschnittswert: Diese drei Zahlen hat Ihr eigener Browser gemessen.

…

Das HTML kommt fertig gerendert vom Server — lesbar, noch bevor das WebAssembly überhaupt geladen ist. Deshalb steht die Seite auch dann, wenn das WASM nie ankommt.

Eine Website in Rust zu bauen ist ungewöhnlich — und genau das ist der Punkt. Wer eine Homepage so umsetzt, baut auch Ihre Systeme mit derselben Sorgfalt.