![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/Screenshot-2026-02-26-1634151.png\")
<\/a><\/figure>\n\n\n\nProblem<\/h3>\n\n\n\n
Die Suche nach dem besten D\u00f6nerladen, der den eigenen Anforderungen entspricht ist oft gar nicht so einfach. Besonders in einer Stadt wie Stuttgart existieren hunderte D\u00f6nerl\u00e4den, mit stark unterschiedlicher Qualit\u00e4t, Preisen, \u00d6ffnungszeiten und Angeboten. Klassische Plattformen wie Google Maps liefern zwar viele Ergebnisse, beantworten aber selten die eigentlichen Fragen der Nutzer:innen:<\/p>\n\n\n\n
- \n
- Wo finde ich jetzt einen guten D\u00f6ner in meiner N\u00e4he?<\/li>\n\n\n\n
- Welcher Laden bietet vegetarische oder vegane Optionen?<\/li>\n\n\n\n
- Wo bekomme ich einen g\u00fcnstigen D\u00f6ner unter einem bestimmten Preis?<\/li>\n<\/ul>\n\n\n\n
Bewertungen sind h\u00e4ufig subjektiv, inkonsistent oder beziehen sich auf v\u00f6llig unterschiedliche Kriterien. Gleichzeitig fehlen strukturierte Filterm\u00f6glichkeiten f\u00fcr genau die Eigenschaften, die f\u00fcr D\u00f6ner-Fans wirklich relevant sind, wie etwa Fleischanteil, Wartezeit oder Preis-Leistungs-Verh\u00e4ltnis.
In unserer Projektidee entstand deshalb ein klares Szenario: <\/p>\n\n\n\n\u201eIch m\u00f6chte einen veganen D\u00f6ner f\u00fcr maximal 6 \u20ac, der gerade ge\u00f6ffnet ist und Kartenzahlung akzeptiert.\u201c <\/p>\n\n\n\n
Mit bestehenden Plattformen l\u00e4sst sich eine solche Anfrage kaum effizient beantworten. Genau hier setzt unser D\u00f6nerguide Stuttgart an.<\/p>\n\n\n\n
Die L\u00f6sung<\/h3>\n\n\n\n
Der D\u00f6nerguide Stuttgart ist eine spezialisierte Web-Anwendung, die sich vollst\u00e4ndig auf die Suche und Bewertung von D\u00f6nerl\u00e4den konzentriert. Genau richtig f\u00fcr Menschen, die genaue Vorstellungen von ihrem perfekten D\u00f6ner haben oder einfach nur den n\u00e4chsten D\u00f6nerladen mit der besten Bewertung finden m\u00f6chten.<\/p>\n\n\n\n
Die Anwendung kombiniert dabei mehrere Ans\u00e4tze:<\/p>\n\n\n\n
- \n
- strukturierte Daten aus der Google Maps Places API<\/li>\n\n\n\n
- eine interaktive Kartenansicht<\/li>\n\n\n\n
- umfangreiche Filterm\u00f6glichkeiten<\/li>\n\n\n\n
- sowie eine KI-gest\u00fctzte Analyse von D\u00f6nerbildern<\/li>\n<\/ul>\n\n\n\n
Dadurch entsteht eine Suche, die nicht nur Orte auflistet, sondern echte Entscheidungsunterst\u00fctzung bietet. Nutzer:innen k\u00f6nnen D\u00f6nerl\u00e4den anhand konkreter Kriterien entdecken, statt sich durch unstrukturierte Bewertungen zu arbeiten.<\/p>\n\n\n\n
Features – Was den D\u00f6nerguide besonders macht<\/h3>\n\n\n\n
Filterbare D\u00f6ner-Suche<\/strong>
Im Zentrum der Anwendung steht eine dynamische \u00dcbersicht aller D\u00f6nerl\u00e4den in Stuttgart. Diese kann nach verschiedenen Kriterien gefiltert werden, wie Preis, Bewertung, vegetarische Optionen, Zahlungsmethoden, Wartezeit oder dem Stadtbezirk. So lassen sich sehr spezifische Anforderungen direkt abbilden.<\/p>\n\n\n\nKartenintegration<\/strong>
Alle Ergebnisse werden zus\u00e4tzlich auf einer interaktiven Karte visualisiert, wodurch Nutzer:innen neben der Liste eine \u00dcbersicht der verschiedenen Standorte der D\u00f6nerl\u00e4den haben.<\/p>\n\n\n\nKI-gest\u00fctzte D\u00f6nerbewertung<\/strong>
Ein besonderes Alleinstellungsmerkmal ist die automatisierte Analyse von D\u00f6nerbildern. Eine KI-Pipeline bewertet Bilder anhand mehrerer Kriterien, darunter der Geschmackseindruck, Belag, Verh\u00e4ltnis der Zutaten und die Gesamtqualit\u00e4t. Aus diesen Faktoren entsteht ein strukturierter Score, der eine vergleichbare Bewertung zwischen verschiedenen L\u00e4den erm\u00f6glicht.
Damit erg\u00e4nzt die KI klassische Nutzerbewertungen um eine objektivierbare Perspektive.<\/p>\n\n\n\n![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/Group-41-1024x513.jpg\")
<\/a><\/figure>\n\n\n\nII. Architektur<\/h2>\n\n\n\n
Der D\u00f6nerguide besteht aus zwei klar getrennten Verantwortlichkeiten: einer KI-Datenpipeline, die automatisch D\u00f6nerl\u00e4den findet, Bilder analysiert, Bewertungen und Bilder f\u00fcr die D\u00f6nerl\u00e4den generiert, und einer API, die diese Daten f\u00fcr das Frontend bereitstellt.<\/p>\n\n\n\n
![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/Gruppe-73-1024x512.png\")
<\/a><\/figure>\n\n\n\nAls Alternative haben wir einen Monolithen in Betracht gezogen, z.B. eine Express-Anwendung mit eingebautem Scheduler, die Aggregation und API in einem Docker-Container vereint. Aus zwei Hauptgr\u00fcnden haben wir uns gegen diese Variante entschieden: Die Pipeline h\u00e4tte die API-Performance beeinflussen k\u00f6nnen, und der Container h\u00e4tte durchgehend laufen m\u00fcssen, obwohl die Pipeline nur alle 15 Minuten ausgef\u00fchrt wird.
Stattdessen entschieden wir uns f\u00fcr einen lose gekoppelten Ansatz mit Azure Functions und Azure Service Bus. Jede Function \u00fcbernimmt eine einzige Aufgabe und kommuniziert ausschlie\u00dflich \u00fcber Queues, ohne direkte Abh\u00e4ngigkeiten zwischen den Functions. Das erm\u00f6glicht Zero Scaling (Kosten entstehen nur bei Ausf\u00fchrung), automatisches Circuit-Breaker-Verhalten \u00fcber die Dead-Letter-Queue sowie unabh\u00e4ngige Entwicklung und Deployment pro Function.<\/p>\n\n\n\nDiese Architektur bringt auch Nachteile mit: Die API-Function hat messbare Cold Starts beim ersten Request, das verteilte System ist aufw\u00e4ndiger zu debuggen als ein einzelner Prozess. Dazu mehr im Abschnitt Learnings.<\/p>\n\n\n\n
Frontend<\/h3>\n\n\n\n
Wenn man ein Projekt wie den D\u00f6nerguide Stuttgart startet, stellt man sich am Anfang immer die gleiche Frage: \u201eWelches Werkzeug nehmen wir eigentlich?\u201c Wir wollten eine L\u00f6sung, die modern ist, Spa\u00df macht und vor allem performant l\u00e4uft. Hier ist der Deep Dive in unsere Frontend-Entscheidungen.<\/p>\n\n\n\n
Das NextJS Frontend<\/h4>\n\n\n\n
![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/Screenshot-2026-02-25-at-19.19.53-1024x245.png\")
<\/a>Unser Frontend Techstack: NextJS Typescript, DaisyUI und Mapbox<\/em><\/figcaption><\/figure>\n\n\n\n F\u00fcr das \u201eGesicht\u201c unserer Anwendung haben wir uns auf das bew\u00e4hrte Trio aus NextJS<\/strong>, TypeScript<\/strong> und DaisyUI<\/strong> verlassen.<\/p>\n\n\n\n
- \n
- Warum NextJS?<\/strong> Ganz ehrlich: Wir hatten bereits Experten f\u00fcr dieses Framework im Team. Das hat uns den Start enorm erleichtert. Andere Frameworks wie Angular<\/strong> f\u00fchlten sich f\u00fcr unser Vorhaben einfach zu \u00fcberdimensioniert an. Und bei Svelte<\/strong>? Da hatten wir Bauchschmerzen wegen des (noch) fehlenden direkten Supports f\u00fcr Azure. NextJS passte also am besten.<\/li>\n\n\n\n
- Statisch, aber oho:<\/strong> Unser Frontend ist zwar statisch gebaut, f\u00fcttert sich aber dynamisch mit Daten \u00fcber einen REST-API-Endpoint von unserem D\u00f6ner-Backend. So bleibt die Seite blitzschnell, zeigt aber immer die aktuellsten D\u00f6ner-Rankings an.<\/li>\n<\/ul>\n\n\n\n
Karten-Chaos: Von Google Maps zu Mapbox<\/h4>\n\n\n\n
Ein Highlight unserer App ist die Karte, auf der ihr alle D\u00f6nerl\u00e4den in Stuttgart findet. Urspr\u00fcnglich wollten wir Google Maps<\/strong> nutzen. Aber als wir das Preisschild von 100 Dollar pro Monat f\u00fcr den passenden API-Key sahen, sind wir fast vom Stuhl gefallen.<\/p>\n\n\n\n
Die Rettung? Mapbox<\/strong>! Es basiert auf OpenStreetMaps, ist deutlich budgetfreundlicher und hat einen riesigen Vorteil: Wir konnten unser eigenes Design direkt in die Karte integrieren. Damit sieht die Map genauso schick aus wie der Rest der App.<\/p>\n\n\n\n
Hosting mit Azure Static Web Apps<\/h4>\n\n\n\n
Beim Hosting haben wir keine Experimente gemacht. Da unser komplettes Backend sowieso in der Azure-Cloud lebt, war es nur logisch, auch das Frontend \u00fcber Azure Static Web Apps<\/strong> laufen zu lassen. Alles aus einer Hand macht die Pipeline einfach viel entspannter.<\/p>\n\n\n\n
Die Struktur der App haben wir dabei bewusst schlank gehalten:<\/p>\n\n\n\n
- \n
- Main Page:<\/strong> Filtern, Suchen, Liste anschauen oder direkt auf der Karte den n\u00e4chsten Snack finden.<\/li>\n\n\n\n
- Store Pages:<\/strong> Die Detailansichten f\u00fcr jeden einzelnen D\u00f6nerladen.<\/li>\n\n\n\n
- Der Rest:<\/strong> Kontakt, Datenschutz und Impressum.<\/li>\n<\/ul>\n\n\n\n
![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/Do\u0308nerguide-Sitemap-edited-1.png\")
<\/a>Die Sitemap des D\u00f6nerguides<\/em><\/figcaption><\/figure>\n\n\n\n Backend & Infrastruktur<\/h3>\n\n\n\n
Der D\u00f6nerguide l\u00e4uft vollst\u00e4ndig auf Azure. F\u00fcnf Functions bilden das R\u00fcckgrat der Anwendung: Der Suchdienst l\u00e4uft mit einem Timer (Cron)-Trigger und findet D\u00f6nerl\u00e4den \u00fcber die Google Maps API. Die Bildklassifizierung verarbeitet die Fotos der L\u00e4den mit Azure Computer Vision, klassifiziert diese in Essen und Ambiente und speichert sie in einem Blob Storage Container. Der LLM-Bewertungsgenerator erstellt auf Basis der klassifizierten Bilder KI-Bewertungen \u00fcber Azure OpenAI mit GPT-5 mini. Der Bildgenerator erstellt mit Nano Banana synthetische Bilder zu den L\u00e4den \u00fcber die Google Gemini API. Die API ist die einzige Function mit einem HTTP-Trigger und liefert die aufbereiteten Daten an das Frontend.<\/p>\n\n\n\n
Die Functions kommunizieren ausschlie\u00dflich \u00fcber Azure Service Bus. Drei Queues verbinden die Pipeline: Die erste \u00fcbergibt neue L\u00e4den an die Bildklassifizierung, die zweite klassifizierte Bilder an den Bewertungsgenerator, die dritte Bild-Prompts an den Bildgenerator. Durch diese Entkopplung hat jede Function nur Kenntnis von ihrer eigenen Queue, Daten werden \u00fcber Messages mit minimalen Informationen weitergegeben und k\u00f6nnen nicht bei der \u00fcbertragung verloren gehen<\/p>\n\n\n\n
Als Datenbank haben wir uns f\u00fcr die Azure CosmosDB entschienden, unter anderem wegen des Pay-as-you-go-Modells, der automatischen Skalierung und des flexiblen Dokumentenmodells, das schnelle Iteration ohne striktes Schema-Management erm\u00f6glicht.<\/p>\n\n\n\n
Alle Azure-internen Dienste (CosmosDB, Service Bus, Blob Storage) werden \u00fcber Managed Identity angebunden, ohne Credentials im Code. Externe API-Keys (Google Maps, Google Gemini) werden im Key Vault verwaltet.<\/p>\n\n\n\n
F\u00fcr Monitoring hat jede Function eine eigene Application-Insights-Instanz; ein zentraler Log Analytics Workspace erm\u00f6glicht \u00fcbergreifende Auswertung. Das Next.js-Frontend l\u00e4uft als Azure Static Web App mit Custom Domain \u00fcber Cloudflare DNS.<\/p>\n\n\n\n
Place Search Algorithmus<\/h3>\n\n\n\n
Die Google Places API<\/strong> liefert pro Suchanfrage maximal 60 Ergebnisse<\/strong>. Stuttgart hat aber deutlich mehr als 60 D\u00f6nerl\u00e4den. Eine einzelne Suche \u00fcber das gesamte Stadtgebiet liefert dadurch unvollst\u00e4ndige Ergebnisse. Deswegen wird ein Algorithmus ben\u00f6tigt, der das Stadtgebiet systematisch in kleinere Bereiche zerlegt, um m\u00f6glichst alle L\u00e4den zu finden.<\/p>\n\n\n\n
Die Place Search ist eine Timer-getriggerte Azure Function<\/strong>, die alle 16 Stunden ausgef\u00fchrt wird. Pro Durchlauf wird genau eine Zelle des Grids verarbeitet. Gefundene D\u00f6nerl\u00e4den werden in CosmosDB gespeichert, neue Fotos per Azure Service Bus an die KI-Pipeline (Image Classifier) weitergeleitet. Die Zellen des Grids werden ebenfalls in CosmosDB abgespeichert, sodass der Fortschritt zwischen den Funktionsaufrufen erhalten bleibt. Die Place Search bildet damit den ersten Schritt in unserer Pipeline: Place Search \u2192 Datenbank \u2192 KI-Analyse \u2192 Frontend<\/strong>.<\/p>\n\n\n\n
Unsere L\u00f6sung<\/h4>\n\n\n\n
Google Places API<\/h5>\n\n\n\n
Wir nutzen die Google Places API (New) mit dem Text-Search<\/strong>-Endpoint, um D\u00f6nerl\u00e4den zu finden und alle relevanten Daten abzufragen, darunter Name, Standort, \u00d6ffnungszeiten und Fotos. Als Suchanfrage wird “D\u00f6ner” \u00fcbergeben.<\/p>\n\n\n\n
Die API liefert maximal ~20 Ergebnisse pro Seite, \u00fcber ein
nextPageToken<\/code> k\u00f6nnen bis zu 3 Seiten abgerufen werden. Daraus ergibt sich das harte Limit von ~60 Ergebnissen pro Suchbereich<\/strong>.<\/p>\n\n\n\nGrid-Erstellung<\/h5>\n\n\n\n
Das Stuttgarter Stadtgebiet wird anhand einer GeoJSON-Datei<\/strong> der Stadtgrenze in eine Bounding Box<\/strong> gesetzt und dann in ein kilometerbasiertes Grid<\/strong> aufgeteilt (~7 km Zellseitenl\u00e4nge). Zellen, die au\u00dferhalb der Stuttgarter Stadtgrenze liegen, werden dabei verworfen, um unn\u00f6tige API-Anfragen zu sparen.<\/p>\n\n\n\n
Adaptive Verarbeitung (Splitting)<\/h5>\n\n\n\n
Pro Durchlauf fragt die Place Search Function die Google Places API f\u00fcr genau eine Zelle ab. Enth\u00e4lt eine Zelle 55 oder mehr Ergebnisse<\/strong>, wird sie gesplittet.<\/p>\n\n\n\n
Das Splitting erfolgt als Binary Split<\/strong>. Dabei wird die Zelle entlang ihrer l\u00e4ngeren Seite in zwei H\u00e4lften geteilt. Die neu entstandenen Zellen werden ebenfalls gegen die Stadtgrenze gepr\u00fcft. Eine maximale Splitting-Tiefe von 10 und eine minimale Zellgr\u00f6\u00dfe von 50 m verhindern endloses Splitten.<\/p>\n\n\n\n
![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/Place-Search-Architecture-1024x291.png\")
<\/a><\/figure>\n\n\n\nZellen-Merging (Post-Scan-Optimierung)<\/h5>\n\n\n\n
Nach einem vollst\u00e4ndigen Durchlauf aller Zellen werden diese daraufhin untersucht, welche benachbarten Zellen zusammengef\u00fchrt werden k\u00f6nnen. Zwei Zellen m\u00fcssen daf\u00fcr eine vollst\u00e4ndige gemeinsame Kante teilen und ihre kombinierte Ergebnisanzahl darf 40 nicht \u00fcberschreiten. Das Merge wird nur durchgef\u00fchrt, wenn es tats\u00e4chlich API-Requests einspart.<\/p>\n\n\n\n
Architekturentscheidungen<\/h4>\n\n\n\n
Warum Text Search statt Nearby Search?<\/h5>\n\n\n\n
Die Google Places API bietet zwei Suchendpoints: Text Search<\/strong> und Nearby Search<\/strong>. Text Search erlaubt eine semantische Suchanfrage wie “D\u00f6ner”, wodurch gezielt D\u00f6nerl\u00e4den gefunden werden. Nearby Search kann dagegen nur mit vordefinierten Typen filtern, was f\u00fcr unseren Anwendungsfall zu unflexibel ist.<\/p>\n\n\n\n
Dar\u00fcber hinaus l\u00e4sst sich bei Text Search der Suchbereich als Rechteck definieren, w\u00e4hrend Nearby Search ausschlie\u00dflich kreisf\u00f6rmige Bereiche (Mittelpunkt + Radius) unterst\u00fctzt.<\/p>\n\n\n\n
\n
Text Search erm\u00f6glicht die semantische Suche nach “D\u00f6ner” und erlaubt den Suchbereich als Rechteck zu definieren.<\/p>\n<\/blockquote>\n\n\n\n
Warum ein rechteckiges Grid als Suchstrategie?<\/h5>\n\n\n\n
F\u00fcr die r\u00e4umliche Zerlegung gibt es zwei Optionen: kreisf\u00f6rmige Suchbereiche<\/strong> oder ein rechteckiges Grid<\/strong>. Radiusbasierte Suche klingt intuitiv, aber entweder \u00fcberlappen sich die Kreise oder es entstehen L\u00fccken.<\/p>\n\n\n\n
Ein rechteckiges Grid hat dieses Problem nicht. Jede Koordinate geh\u00f6rt zu genau einer Zelle, wodurch eine l\u00fcckenlose Abdeckung<\/strong> entsteht. Zus\u00e4tzlich l\u00e4sst sich ein rechteckiges Grid entlang der l\u00e4ngeren Achse halbieren, wobei die entstehenden Kinderzellen direkt wieder als Suchbereiche verwendet werden k\u00f6nnen.<\/p>\n\n\n\n
\n
Ein rechteckiges Grid deckt das Stadtgebiet l\u00fcckenlos ab und die Zellen lassen sich einfach teilen.<\/p>\n<\/blockquote>\n\n\n\n
Warum Binary Split statt Quadtree?<\/h5>\n\n\n\n
Ein Quadtree<\/strong> teilt jede Zelle gleichm\u00e4\u00dfig in vier Rechtecke. Bei jedem Split entstehen dadurch vier neue Zellen und vier zus\u00e4tzliche API-Requests. Das Problem dabei: In der Praxis hat h\u00e4ufig nur ein Teil der Zelle eine hohe Ergebnisdichte, die restlichen Rechtecke w\u00e4ren unn\u00f6tig.<\/p>\n\n\n\n
Mit einem Binary Split<\/strong> teilen wir dagegen entlang der l\u00e4ngeren Achse und erzeugen nur zwei neue Zellen. Dadurch passt sich das Grid besser an die Form des Gebiets an, da jede Zelle wiederholt entlang ihrer l\u00e4ngsten Seite geteilt wird.<\/p>\n\n\n\n
\n
Der Binary Split ist sparsamer als ein Quadtree und passt sich durch die Aufteilung besser an die tats\u00e4chliche Ergebnisdichte des Gebiets an.<\/p>\n<\/blockquote>\n\n\n\n
Warum Split-Threshold bei 55 statt 60<\/h5>\n\n\n\n
Das API-Maximum liegt bei 60 Ergebnissen<\/strong>. Die API f\u00fchrt eine relevanzbasierte Suche<\/strong> durch und liefert nicht bei jeder Anfrage exakt dieselben Ergebnisse. Eine Zelle mit 58 Ergebnissen k\u00f6nnte in Wirklichkeit mehr L\u00e4den enthalten, abh\u00e4ngig vom Ranking der API.<\/p>\n\n\n\n
Durch das Splitten bei 55<\/strong> teilen wir solche Zellen auf. Die beiden kleineren Anfragen liegen jeweils weit unter dem Limit und liefern zusammen zuverl\u00e4ssiger alle Ergebnisse.<\/p>\n\n\n\n
\n
Fr\u00fcher splitten f\u00fcr vollst\u00e4ndige Daten.<\/p>\n<\/blockquote>\n\n\n\n
Warum werden Grid-Zellen in der Datenbank persistiert?<\/h5>\n\n\n\n
Die Persistenz der Zellen erm\u00f6glicht, dass sich das Grid \u00fcber mehrere Durchl\u00e4ufe hinweg optimiert: Splitting<\/strong> und Merging<\/strong> passen die Zellen schrittweise an die tats\u00e4chliche Ergebnisdichte an und reduzieren so die Anzahl der API-Aufrufe. Ohne Persistenz w\u00fcrde man jedes Mal von vorne anfangen und dieser Fortschritt ginge verloren.<\/p>\n\n\n\n
\n
Die Datenbank speichert die Optimierungen des Grids.<\/p>\n<\/blockquote>\n\n\n\n
Warum Timer-Trigger mit 16-Stunden-Intervall statt Batch-Verarbeitung?<\/h5>\n\n\n\n
Azure Functions<\/strong> sind f\u00fcr kurzlebige Ausf\u00fchrungen ausgelegt. Ein vollst\u00e4ndiger Batch-Durchlauf \u00fcber alle Zellen w\u00fcrde das Execution-Timeout<\/strong> \u00fcberschreiten und ist damit in einer Serverless-Umgebung nicht praktikabel. Der Timer-Trigger<\/strong> mit einer Zelle pro Ausf\u00fchrung l\u00f6st dieses Problem.<\/p>\n\n\n\n
Zus\u00e4tzlich verteilt der Timer-Trigger<\/strong> die API-Requests gleichm\u00e4\u00dfig \u00fcber die Zeit und vermeidet so Rate Limiting<\/strong>. Schl\u00e4gt ein Durchlauf fehl, wird nur diese eine Zelle beim n\u00e4chsten Mal erneut verarbeitet.<\/p>\n\n\n\n
Das 16-Stunden-Intervall ergibt sich direkt aus unserer Anforderung von 14 Tagen pro vollst\u00e4ndigem Durchlauf, was f\u00fcr einen D\u00f6ner-Guide mit geringer \u00c4nderungsrate ausreicht. Bei ~20 Zellen entspricht das einer Ausf\u00fchrung alle 16 Stunden.<\/p>\n\n\n\n
\n
Der Timer-Trigger macht die Place Search serverless-kompatibel.<\/p>\n<\/blockquote>\n\n\n\n
III. Challenges<\/h2>\n\n\n\n
Challenge: State Management im Frontend<\/h3>\n\n\n\n
Die Explore Seite ist das zentrale Interface unseres D\u00f6nerguides: Benutzer k\u00f6nnen nach Preis, Stadtteil, Score, So\u00dfenmenge, Fleischanteil oder Eigenschaften wie halal bzw. vegetarisch filtern und die Ergebnisse zus\u00e4tzlich sortieren. Was zuerst wie eine einfache Filterliste aussah, stellte sich im Frontend schnell als State Management Challenge heraus.<\/p>\n\n\n\n
Ausgangssituation: UI, URL und Backend m\u00fcssen synchron bleiben<\/strong><\/h4>\n\n\n\n
F\u00fcr eine gute User Experience wollten wir drei Anforderungen gleichzeitig erf\u00fcllen:<\/p>\n\n\n\n
- \n
- Direktes UI Feedback:<\/strong> Filter (z. B. Slider oder Checkboxen) sollen sich sofort aktualisieren.<\/li>\n\n\n\n
- Persistenter Zustand \u00fcber die URL:<\/strong> Filter und Sortierung sollen bei Reload, Navigation oder Bookmark erhalten bleiben.<\/li>\n\n\n\n
- Kontrollierte Backend Requests:<\/strong> Interaktionen wie das Bewegen eines Sliders d\u00fcrfen nicht dazu f\u00fchren, dass st\u00e4ndig neue API Calls an das Backend geschickt werden.<\/li>\n<\/ul>\n\n\n\n
Diese drei Ziele stehen in einem gewissen Spannungsverh\u00e4ltnis: Bindet man die UI direkt an die URL, wirkt sie tr\u00e4ge. H\u00e4lt man alles nur lokal, gehen Navigation und Persistenz verloren.<\/p>\n\n\n\n
L\u00f6sung: Trennung von UI State und URL State<\/strong><\/h4>\n\n\n\n
Unser Ansatz war eine klare Aufgabentrennung zwischen zwei States:<\/p>\n\n\n\n
- \n
- Der URL State<\/strong> (
urlParams<\/code> \u00fcbernuqs<\/code>) wird debounced aktualisiert und repr\u00e4sentiert den persistenten Zustand der Seite.<\/li>\n\n\n\n- Der UI State<\/strong> (
uiFilters<\/code>,uiSort<\/code>) wird direkt durch Nutzerinteraktionen aktualisiert und steuert die sichtbare Oberfl\u00e4che. <\/li>\n<\/ul>\n\n\n\nIm Hook sieht diese Trennung so aus:<\/p>\n\n\n\n
\/\/ URL state\nconst [urlParams, setUrlParams] = useQueryStates(exploreParsers)\n\n\/\/ UI state (instant feedback)\nconst [uiFilters, setUiFilters] = useState(urlFilters)\nconst [uiSort, setUiSort] = useState(urlParams.sort)<\/code><\/pre>\n\n\n\nBeispiel: Interaktion mit dem Preis Slider<\/strong><\/h4>\n\n\n\n
Bewegt ein Nutzer den Preis Slider, wird zun\u00e4chst nur der UI State aktualisiert:<\/p>\n\n\n\n
const handleFiltersChange = () => {\n setUiFilters(filters) \/\/ sofortiges UI Update\n updateFiltersDebounced(filters, uiSort) \/\/ verz\u00f6gertes URL Update\n}<\/code><\/pre>\n\n\n\nDer Slider reagiert dadurch direkt. Die URL hingegen wird erst nach kurzer Inaktivit\u00e4t synchronisiert:<\/p>\n\n\n\n
const DEBOUNCE_MS = 300\n\nconst updateFiltersDebounced = async (newFilters, sort) => {\n window.setTimeout(async () => {\n await setUrlParams(newFilters, sort)\n }, DEBOUNCE_MS )\n}<\/code><\/pre>\n\n\n\nZieht man den Slider beispielsweise von 6 \u20ac auf 10 \u20ac, passieren mehrere UI Updates, aber nur ein<\/strong> URL Update nach Ende der Interaktion. Dadurch bleibt die Oberfl\u00e4che fl\u00fcssig, w\u00e4hrend der persistente Zustand konsistent gespeichert wird.<\/p>\n\n\n\n
Fetch-Trigger \u00fcber den URL-State<\/strong><\/h4>\n\n\n\n
Der eigentliche Daten Fetch h\u00e4ngt bewusst am URL State, nicht an der UI Interaktion. Sobald die URL aktualisiert wird, synchronisieren wir UI und Daten:<\/p>\n\n\n\n
useEffect(() => {\n setUiFilters(urlFilters)\n setUiSort(urlParams.sort)\n void fetchData(urlFilters, urlParams.sort)\n}, [urlParams, urlFilters, fetchData])<\/code><\/pre>\n\n\n\nDie Update Kette lautet somit:<\/p>\n\n\n\n
![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/Gruppe-72-1-1024x100.png\")
<\/a><\/figure>\n\n\n\nSortierung behandeln wir bewusst anders<\/strong><\/h4>\n\n\n\n
Im Gegensatz zu Slidern wird die Sortierung nicht schrittweise ver\u00e4ndert, sondern einmalig ausgew\u00e4hlt (Dropdown). Deshalb wird die URL hier ohne Verz\u00f6gerung<\/strong> aktualisiert.<\/p>\n\n\n\n
const handleSortChange = async (newSort) => {\n setUiSort(newSort)\n setUiFilters(filters)\n updateFiltersImmediate(filters, newSort)\n}<\/code><\/pre>\n\n\n\nStale Requests verhindern (Race Conditions)<\/strong><\/h4>\n\n\n\n
Wenn Filter schnell wechseln oder das Backend langsam antwortet, k\u00f6nnen Responses in falscher Reihenfolge zur\u00fcckkommen. Damit die alten Daten nicht die neuen \u00fcberschreiben, vergeben wir f\u00fcr jeden Request eine ID und stellen sicher, dass nur die letzte Anfrage<\/strong> \u00fcbernommen wird.<\/p>\n\n\n\n
const requestIdRef = useRef(0)\n\nconst fetchData = async (filters, sort) => {\n const currentRequestId = ++requestIdRef.current\n const payload = await fetchPlaces(filters, sort)\n\n if (currentRequestId !== requestIdRef.current) return \/\/ veraltete requests ignorieren\n\n setStores(payload.items)\n}<\/code><\/pre>\n\n\n\nChallenge: Page Indexing von Slug-URLs f\u00fcr Azure<\/h3>\n\n\n\n
Ein Fehler ist bei uns furchtbar lange unter dem Radar geblieben: Wir hatten das Problem, dass einige unserer Stores nicht korrekt angezeigt wurden. Stattdessen bekamen die Nutzer einen unsch\u00f6nen Azure 404 Error zu sehen.
Das sah dann etwa so aus:https:\/\/doenerguide-stuttgart.de\/ChIJryPzk07bmUcRsC6cdRmB7Jk<\/code><\/em> -> Azure 404<\/strong>
Wir konnten es erst gar nicht glauben. Die API funktionierte einwandfrei und wir hatten sogar eine eigene D\u00f6nerguide-Errorpage entworfen, auf die bei fehlenden Daten verlinkt werden sollte. Lokal trat dieser Fehler nat\u00fcrlich nicht auf.
Nach viel Recherche fiel uns auf: Im Deployment-Log tauchten nur die Links auf, die auch tats\u00e4chlich funktionierten. Dort wurden lediglich 20 Routen geloggt, obwohl wir eigentlich hunderte Stores in unserer Datenbank haben und anzeigen wollen.
<\/p>\n\n\n\n![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/Screenshot-2026-02-24-at-23.14.41.png\")
<\/a>Bild der Deployment-Pipeline mit 20 definierten Store-Routen<\/em>.<\/figcaption><\/figure>\n\n\n\n
Es stellte sich heraus: Eine Azure Static Web App muss beim Deployment quasi “wissen”, welche statischen Links sie bereitstellen soll. Ansonsten zeigt Azure seinen eigenen 404-Fehler an.<\/p>\n\n\n\nDie L\u00f6sung: generateStaticParams<\/h4>\n\n\n\n
In NextJS gibt es eine feine Funktion f\u00fcr statische Webseiten, die genau dieses Problem l\u00f6st. Wir mussten NextJS dazu bringen, bereits beim Build-Prozess alle IDs unserer Stores abzufragen und als Parameter zu definieren.
Im Code nennen wir diese IDs slug und die L\u00e4den places.
Die L\u00f6sung sah dann so aus:<\/p>\n\n\n\nexport async function generateStaticParams() {\n \/\/ Alle verf\u00fcgbaren Pl\u00e4tze von der API abrufen\n const data = await fetchPlaces('limit=2000') \n const places = data.items || []\n \n \/\/ Jede Slug-ID an NextJS (und damit an Azure) \u00fcbergeben\n return places.map((place: StoreBase) => ({\n slug: place.slug,\n }))\n}<\/code><\/pre>\n\n\n\nDiese Definition sorgt daf\u00fcr, dass Azure beim Deployment die kompletten Metadaten vom NextJS-Frontend erh\u00e4lt.<\/p>\n\n\n\n
Challenge: Deployment<\/h3>\n\n\n\n
Beim Deployment der Infrastrukturkomponenten hatten wir zwei unerwartete Probleme.<\/p>\n\n\n\n
Das erste betraf das Zusammenspiel von Terraform und dem Deployment-Prozess, der Functions. Bei jeder Infrastruktur\u00e4nderung hat Terraform das Function-Deployment \u00fcberschrieben, da deployment-relevante Felder nicht als ignore_changes<\/em> markiert waren. Betroffen waren die Felder WEBSITE_RUN_FROM_PACKAGE<\/em>, WEBSITE_ENABLE_SYNC_UPDATE_SITE<\/em> und site_config[0].application_stack<\/em>. Als Workaround haben wir zun\u00e4chst ein automatisches Redeployment aller Functions in die Infrastruktur-Pipeline eingebaut. Die saubere L\u00f6sung war, diese Felder in Terraform als `ignore_changes` zu markieren, sodass Infrastruktur und Deployment klar getrennt sind.<\/p>\n\n\n\n
Das zweite Problem betrifft das Azure-Tooling generell. Die Azure\/functions-action<\/em> f\u00fcr GitHub Actions erf\u00fcllt ihren Zweck, bietet aber weniger Flexibilit\u00e4t als das Deployment anderer Anbieter, bei denen sich Functions direkt \u00fcber Terraform deployen lassen. Beim Frontend zeigte sich dasselbe Muster: Die Azure\/static-web-apps-deploy<\/em>-Action lie\u00df sich nicht ausreichend an unsere Build-Anforderungen anpassen. Wir bauen das Frontend deshalb separat mit npm und nutzen die Action nur noch f\u00fcr das reine Deployment.<\/p>\n\n\n\n
Challenge: Docker Setup unter ARM<\/h3>\n\n\n\n
F\u00fcr die lokale Entwicklung emulieren wir die Azure-Infrastruktur vollst\u00e4ndig per Docker. Auf Apple Silicon M-Chips sind wir dabei auf zwei Kompatibilit\u00e4tsprobleme gesto\u00dfen.<\/p>\n\n\n\n
Das erste war schnell gel\u00f6st: Der Service Bus Emulator ben\u00f6tigt Microsoft SQL Edge als Datenbank, welche keinen ARM-Support hat. Als Ersatz konnten wir mssql\/server:2022-latest<\/em> verwenden.<\/p>\n\n\n\n
Das zweite Problem war aufw\u00e4ndiger in der Fehlersuche. Die Azure Functions liefen in Node.js-Containern, die nat\u00fcrlich auch f\u00fcr ARM verf\u00fcgbar sind. Was wir nicht wussten: Die Azure Functions Dependency enth\u00e4lt ein Installationsskript, das bei der Installation die Functions Runtime aus dem Internet nachl\u00e4dt. Auf ARM schl\u00e4gt dieses Skript fehl, weil keine ARM-Runtime verf\u00fcgbar ist. Der entscheidende Punkt dabei: kein Fehler, kein Log. Die Functions starteten einfach nicht.<\/p>\n\n\n\n
Um die Ursache zu finden, haben wir den node_modules<\/em>-Ordner zwischen einer Linux-x86-Installation und der M-Mac-Installation verglichen. Die Functions Runtime hat auf ARM gefehlt. Beim genaueren Untersuchen der Dependency, fanden wir das Installationsskript und sahen, wie es den Download-Link f\u00fcr die Runtime dynamisch zusammengebaut hat. Der Link existierte f\u00fcr ARM schlicht nicht.<\/p>\n\n\n\n
Die L\u00f6sung: platform: linux\/amd64<\/em> in compose.yaml<\/em> erzwingt x86-Emulation, Docker l\u00e4dt die korrekte Runtime und alles l\u00e4uft. Tradeoff ist eine sp\u00fcrbar schlechtere Performance durch die Emulation.<\/p>\n\n\n\n
Challenge: Place Search Algorithmus Optimierung<\/h3>\n\n\n\n
Der Place Search Algorithmus wurde \u00fcber mehrere Iterationen hinweg optimiert. Jede \u00c4nderung war durch eine beobachtete Ineffizienz motiviert. Das Ziel war immer dasselbe: die Anzahl der API-Requests reduzieren, ohne die Abdeckung des Stadtgebiets zu verlieren. Die folgenden Abschnitte beschreiben die drei zentralen Herausforderungen und wie wir sie gel\u00f6st haben.<\/p>\n\n\n\n
Ausgangslage: Das erste Grid<\/h4>\n\n\n\n
Die erste Version nutzte vier fest kodierte Koordinaten als Bounding Box um Stuttgart und teilte diese in ein fixes 4\u00d74-Grid mit 16 gleichm\u00e4\u00dfigen Zellen auf. Die Zellgr\u00f6\u00dfe war dadurch eine Konsequenz der 4\u00d74-Aufteilung. Au\u00dferdem waren die Zellen in Ost-West-Richtung geometrisch verzerrt, weil ein Grad L\u00e4ngengrad bei 48\u00b0N nur rund 73 km entspricht, aber ein Grad Breitengrad immer ~111 km. Gab es in einer Zelle mehr als 55 Ergebnisse, wurde sie in zwei Kinderzellen gesplittet. F\u00fcr alle Zellen innerhalb der Bounding Box wurde die API angefragt.<\/p>\n\n\n\n
![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/Originale-Implementierung-Place-Search-Algorithm-1.png\")
<\/a><\/figure>\n\n\n\nHerausforderung 1: Unn\u00f6tige Anfragen au\u00dferhalb der Stadtgrenze<\/h4>\n\n\n\n
Problem:<\/strong> Die Eckzellen der Bounding Box lagen teilweise vollst\u00e4ndig au\u00dferhalb des Stuttgarter Stadtgebiets. Diese Zellen lieferten keine Ergebnisse, kosteten aber trotzdem jeweils einen API-Request.<\/p>\n\n\n\n
Ursache:<\/strong> Die Bounding Box ist ein Rechteck, Stuttgart ist ein unregelm\u00e4\u00dfiges Polygon. Die Ecken eines Rechtecks um ein unregelm\u00e4\u00dfiges Gebiet enthalten Fl\u00e4chen ohne Relevanz.<\/p>\n\n\n\n
L\u00f6sung<\/strong>: Wir haben die GeoJSON-Stadtgrenze Stuttgarts als Multipolygon hinterlegt. Bei der Grid-Erstellung wird jede Zelle mit
booleanIntersects<\/code> aus Turf.js gegen dieses Polygon gepr\u00fcft. Nur Zellen, die tats\u00e4chlich mit dem Stadtgebiet \u00fcberlappen, werden ins Grid aufgenommen. Derselbe Filter wird auch beim Splitting angewendet: Wenn eine Kindzelle nach dem Split au\u00dferhalb der Stadtgrenze liegt, wird sie verworfen.<\/p>\n\n\n\n - Der UI State<\/strong> (
- Persistenter Zustand \u00fcber die URL:<\/strong> Filter und Sortierung sollen bei Reload, Navigation oder Bookmark erhalten bleiben.<\/li>\n\n\n\n
- Store Pages:<\/strong> Die Detailansichten f\u00fcr jeden einzelnen D\u00f6nerladen.<\/li>\n\n\n\n
- Statisch, aber oho:<\/strong> Unser Frontend ist zwar statisch gebaut, f\u00fcttert sich aber dynamisch mit Daten \u00fcber einen REST-API-Endpoint von unserem D\u00f6ner-Backend. So bleibt die Seite blitzschnell, zeigt aber immer die aktuellsten D\u00f6ner-Rankings an.<\/li>\n<\/ul>\n\n\n\n
- Warum NextJS?<\/strong> Ganz ehrlich: Wir hatten bereits Experten f\u00fcr dieses Framework im Team. Das hat uns den Start enorm erleichtert. Andere Frameworks wie Angular<\/strong> f\u00fchlten sich f\u00fcr unser Vorhaben einfach zu \u00fcberdimensioniert an. Und bei Svelte<\/strong>? Da hatten wir Bauchschmerzen wegen des (noch) fehlenden direkten Supports f\u00fcr Azure. NextJS passte also am besten.<\/li>\n\n\n\n