Heurig.at

Heurig.at ist ein Hobbyprojekt zu dritt – ein Verzeichnis und eine Suchmaschine für österreichische Heurigen, von Niederösterreich über Wien bis in die Steiermark. Mit Andreas Babic und Malek Morad arbeiten wir seit 2023 daran, das Projekt hat mehrere Phasen und Stack-Entscheidungen überlebt.

Das Problem

Heurigen sind saisonal, regional verstreut und ihre Daten leben in unterschiedlichsten Quellen – Vereinslisten, lokale Tourismusverbände, eigene Websites, manchmal nur Aushänge. Wer einen Heurigen in der Umgebung sucht, scrollt durch PDFs aus drei Landwirtschaftskammern oder fragt die Großeltern. Wir wollten eine einzige Oberfläche bauen, in der man nach Ort, Name oder Auflistung eingrenzen kann – und in der die Öffnungszeiten stimmen.

Rahmenbedingungen

Drei Entwickler, kein Budget, kein Druck zur Skalierung. Das hat die Architekturentscheidungen geprägt: einfacher Stack, billiges Hosting, Daten zu großem Teil händisch oder halbautomatisch zusammengetragen. Kein Investor heißt auch: Wir konnten Stack-Wechsel machen, die in einem kommerziellen Kontext schwer zu rechtfertigen wären.

Architektur

Die Anwendung läuft als klassisches Frontend-Backend-Setup. Das Backend ist ein NestJS-Dienst in TypeScript, der gegen MySQL via TypeORM persistiert. Das Frontend ist seit dem letzten Umbau ein Standalone-Angular mit Server-Side Rendering – das ist wichtig für die Suchmaschinen-Indexierung und für die Time-to-First-Paint auf Mobilgeräten in ländlichen Gebieten mit schlechter Verbindung.

Die Suche ist eine Eigenentwicklung. Statt einer fertigen Engine läuft im Hintergrund eine baumbasierte Autovervollständigung in PHP, die auf vorgelagerten Indizes über Heurigennamen, Orte und Schlagwörter arbeitet. Karten zeichnet Leaflet, die Heurigen werden als Cluster dargestellt, damit dichte Regionen lesbar bleiben. Deployment läuft über GitHub Actions und Docker/Portainer auf eigene Infrastruktur.

Entscheidungen – und was verworfen wurde

Frontend: Ionic + Angular → Standalone Angular mit SSR. Wir starteten mit Ionic, weil eine Mobile-App ursprünglich Teil der Vision war. Als das Web zur Hauptzielplattform wurde, wurde Ionic zu Ballast – größerer Bundle, einschränkende Komponentenphilosophie, kein echter SSR-Pfad. Der Wechsel auf Standalone-Angular mit SSR brachte schnellere First-Paint-Werte und besseres SEO, ohne dass wir die mobile Variante schließen mussten – die kommt später als PWA über denselben Stack zurück.

Suche: fertige Engine → eigene Baum-Autovervollständigung in PHP. Wir haben mit ElasticSearch geliebäugelt, es aber wieder verworfen. Begründung: Unser Datensatz ist überschaubar, unsere Abfragen sind eng (Name, Ort, Region), und Elastic-Hosting kostet jeden Monat Geld. Ein in PHP gehaltener Trie-basierter Index läuft auf demselben Server wie die Website, ist deterministisch und in fünfzig Codezeilen erklärt. Wenn wir Volltextsuche über lange Beschreibungen brauchen, denken wir darüber wieder nach.

Daten-Layer: NoSQL → MySQL/TypeORM. Ein Dokumentenmodell wäre für die unregelmäßigen Heurigen-Profile (manche haben Öffnungszeiten, manche Speisekarten, manche nur eine Adresse) bequemer gewesen. Wir haben uns trotzdem für MySQL entschieden, weil das die Sprache ist, in der wir am besten debuggen können – und in einem ehrenamtlichen Projekt zählt jedes verlorene Wochenende.

Hosting: Cloud → Plesk. Wir hosten auf einem von Andreas verwalteten Plesk-Server statt bei einem Hyperscaler. Das spart Geld und macht das Deployment vorhersehbar, kostet uns aber Auto-Scaling. Akzeptiert: Wir sind nicht groß genug, dass das irgendetwas auslöst.

Was wir gelernt haben

Der größte Lerneffekt war das Tempo, das ein winziges Team mit einem bewussten Stack erreicht: Wir haben mehr produktive Arbeitsstunden mit Boring Tech gehabt als in jedem Projekt, in dem wir zuerst die Werkzeuge gefeiert haben. Außerdem: Deployment-Automatisierung amortisiert sich auch bei kleinem Traffic – nicht wegen Skalierung, sondern weil Reibung beim Releasen zu längeren Release-Pausen führt, und lange Pausen erodieren die Codebasis.

Was ich anders machen würde

Datenmodell früher festziehen. Wir haben die Schemata mehrfach umgebaut, weil neue Quellen neue Felder brachten (Bewertungen, Speisen, Öffnungszeiten in Sonderformaten). Eine erste Iteration über das Datenmodell mit einem klaren Erweiterbarkeitspfad hätte zwei Migrationen erspart.

Öffnungszeiten als eigenes Sub-Modell. Heurigen haben Öffnungszeiten, die keine Software-Annahmen erfüllen: zwei Wochen offen, drei Wochen geschlossen, manchmal nur am Wochenende, manchmal nur auf Anmeldung. Wir haben das anfangs in Freitextfeldern erschlagen – im Nachhinein zu schmerzhaft. Ein strukturiertes Zeitfenster-Modell von Anfang an wäre die richtige Investition gewesen.

SSR früher. Wir haben SSR erst spät eingeführt, weil wir den Aufwand überschätzt haben. In Wahrheit war der Umbau in einem Wochenende erledigt – und die SEO-Effekte waren in der nächsten Indexierungswelle messbar. Hätten wir das im ersten Quartal gemacht, hätten wir Monate früher organisch gefunden werden können.